Sequence of scans
FortiWeb applies protection rules and performs protection profile scans in the order of execution according to the below table. To understand the scan sequence, read from the top of the table (the first scan/action) toward the bottom (the last scan/action). Disabled scans are skipped.
You may find the actual scan sequence sometimes is different from what we list below in the scan sequence table. There might be various reasons, for example, for the scans involving the whole request or response package, its sequence may vary depending on when the package is fully transferred to FortiWeb. File Security is one of the scan items that involve scanning the whole package. FortiWeb scans Content-Type:
and the body of the file for File Security. While the Content-Type:
is scanned instantly, the body of the file may be postponed after the subsequent scans until the whole body of the file is done uploading to FortiWeb.
Please also note that when we talk about scan sequence, it refers to the sequence within the same package. For example, HTTP Request Limit precedes the TCP Connection Number Limit in the scan sequence table. However, if there are two pakages containing HTTP traffic and TCP traffic respectively, and the TCP package arrives first, FortiWeb thus checks the TCP Connection Number Limit first.
To improve performance, block attackers using the earliest possible technique in the execution sequence and/or the least memory-consuming technique. The blocking style varies by feature and configuration. For example, when detecting cookie poisoning, instead of resetting the TCP connection or blocking the HTTP request, you could log and remove the offending cookie. For details, see each specific feature. |
Scan/action | Involves |
---|---|
Request from client to server
|
|
Add X-Forwarded-For: |
|
IP List * (individual client IP black list or white list) |
|
IP Reputation |
Source IP address of the client depending on your configuration of X-header rules. This could be derived from either the |
Quarantined source IP addresses |
Source IP address of the client in the IP layer. |
Allow Known Search Engines |
|
Geo IP |
|
WebSocket protocol |
|
Add HSTS Header |
|
Protected Server Check |
|
Allow Method |
|
Session Management |
|
Token header |
|
HTTP Request Limit/sec (HTTP Flood Prevention) |
|
TCP Connection Number Limit (Malicious IP) |
|
HTTP Request Limit/sec (Shared IP) (HTTP Access Limit) |
|
TCP Connection Number Limit (TCP Flood Prevention) |
|
Brute Force Login |
|
HTTP Authentication |
|
Configuring the global object white list |
|
ADFS Proxy |
|
Site Publish |
|
URL Access |
|
WebSocket protocol |
|
Padding Oracle Protection |
|
HTTP Protocol Constraints |
|
Start Pages |
|
Page Access (page order) |
|
File Security |
|
Parameter Validation |
|
File Uncompress |
Content-Type:
|
Web Cache |
|
Machine Learning - Bot Detection |
|
Defeating cross-site request forgery (CSRF) attacks |
|
Protection for Man-in-the-Browser (MiTB) attacks |
|
|
|
|
|
|
|
Signatures |
|
Device Reputation |
|
Hidden Fields Protection |
|
Custom Policy |
|
User Tracking |
|
|
|
OpenAPI Validation |
|
XML Validation |
|
CORS Protection |
|
URL Rewriting (rewriting & redirects) |
|
Machine Learning - Anomaly Detection |
|
File Compress |
Accept-Encoding:
|
Cookie Security Policy |
|
Reply from server to client
|
|
Configuring a protection profile for inline topologies |
Content-Encoding:
|
Hidden Fields Protection |
|
Custom Policy |
|
URL Rewriting (rewriting) |
|
Web Socket Protocol |
|
Chunk Decoding |
|
Protection for Man-in-the-Browser (MiTB) attacks |
|
Signatures |
|
Device Reputation |
|
|
|
User Tracking |
|
HTTP Header Security |
|
* If a source IP is white listed, subsequent checks will be skipped. |