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 packet, its sequence may vary depending on when the packet is fully transferred to FortiWeb. File Security is one of the scan items that involve scanning the whole packet. 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 packet. For example, TCP Connection Number Limit precedes HTTP Request Limit in the scan sequence table. However, if there are two packets containing HTTP traffic and TCP traffic respectively, and the HTTP packet arrives first, FortiWeb thus checks the HTTP 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 Syntax-based SQL/XSS injection, instead of blocking the SQL/XSS injection by its syntax, you could log and block the injection by the block list defined in IP List. For details, see each specific feature. |
Scan/action | Involves |
---|---|
Request from client to server
|
|
TCP Connection Number Limit (TCP Flood Prevention) |
|
Add X-Forwarded-For: |
|
Client Management |
|
IP List |
Note: If a source IP is allow listed, subsequent checks will be skipped. |
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. |
Known Bots |
|
Geo IP |
|
WebSocket protocol |
|
Add HSTS Header |
|
Protected Server Check |
|
Allow Method |
|
Token header |
|
HTTP Request Limit/sec (HTTP Flood Prevention) |
|
TCP Connection Number Limit (Malicious IP) |
|
HTTP Request Limit/sec (Shared IP) (HTTP Access Limit) |
|
HTTP Authentication |
|
Global Object Allow List |
|
ADFS Proxy |
|
URL Access |
|
Mobile API Protection |
|
Padding Oracle Protection |
|
HTTP Protocol Constraints |
|
File Parse |
Note: File parse is a back-end module which serves to parse the uploaded files that will be further scanned by File Security and Web Shell Detection. |
File Security |
|
|
|
Parameter Validation |
|
|
|
ML based Bot Detection |
|
Cross-site request forgery (CSRF) attacks |
|
Protection for Man-in-the-Browser (MiTB) attacks |
|
|
|
|
|
|
|
Signatures |
|
|
|
Site Publish |
|
Hidden Fields Protection |
|
Custom Policy |
|
|
|
User Tracking |
|
|
|
OpenAPI Validation |
|
CORS Protection |
|
URL Rewriting (rewriting & redirection) |
|
|
|
File Compress | Accept-Encoding:
|
Cookie Security Policy |
|
ML based Anomaly Detection |
|
Reply from server to client
|
|
Web Socket Protocol |
|
Chunk Decoding |
|
Web Cache |
|
|
|
Protection for Man-in-the-Browser (MiTB) attacks |
|
|
|
|
|
Signatures |
|
Hidden Fields Protection |
|
Custom Policy |
|
User Tracking |
|
URL Rewriting (rewriting) |
|
|
|
HTTP Header Security |
|