File uploads are being blocked by the WAF; how do I fix it?

Short answer

The inspection that causes the block is read from the Attack name and Attack area values on the Attacks tab of the upload request's Event Logs record. The most common causes: the type detected from the file's content not being in the Allowed Upload Mime Types list (Attack area Form@type), a signature match in the file content or in the whole body (Attack area Raw), a signature match in the file name or in another form field (Form@field), the Raw Body Size limit being exceeded, and a multipart body that cannot be parsed (Block Invalid Form Contents). In the page types produced with Analysis & Learning, the file type list covers only the types seen during learning, and Raw Body Size covers the largest body seen; for this reason, a new file type or a larger file is blocked. A false positive is taught from the record with Allow, or the Form and Raw common rule in the page type of the upload path is edited; the change affects only that page type. For a 418 that has no record in Event Logs, the scan timeout (the 2-second time limit) is investigated first; a 408, on the other hand, shows that the body did not arrive within the HTTP Request Timeout period.

Problem: File Uploads Are Blocked

The upload form returns the blocking page (default status code 418); some file types or large files are rejected. Since a file upload request carries a multipart (multipart/form-data) body, the same request goes through several inspections of the WAF, and each inspection appears in Event Logs with a different rule name.

Possible Causes

Shown on the Attacks tab	Cause	Solution
Attack Name = Allowed Upload Mime Types; Attack area = Form@type; Description = the detected type	The type detected from the file's content is not in the allow list of the matched rule	Method 2
Signature name; Attack Area = Raw (without a parameter)	A signature match in the whole multipart body; this scan is done with OWASP Check on the Raw tab (In multipart requests, is the whole body scanned separately as well?)	Method 3
Signature name; Attack Area = Raw@file-field	A signature match in the file content (OWASP Check in Upload)	Method 3
Signature name; Attack Area = Form@field	A signature match in the file name or in the value of another form field; the value of the file field is the file name	Method 1 or Can I turn off OWASP scanning for a specific parameter?
Raw Body Size; Attack area = Raw	The declared size of the body (Content-Length) is outside the range of the rule	Method 3
Block Invalid Form Contents; Attack area = Form	The multipart body could not be parsed: a part has a file name (filename) but no Content-Type or the reverse, the file name is unquoted or empty (a file field sent without a file being selected carries filename=""), the part boundaries are inconsistent	The client is fixed or the box is unchecked in Method 2
Block All Form Contents; Attack Area = Form	The matched rule does not accept a form body at all (Block All Form Contents)	The box is unchecked in Method 2
Allowed Methods; Attack Area = Path	The upload method (POST or PUT) is not in the Allowed Methods list of the page type	Method 1
Block Unparsed Contents; Attack area = Raw	The body did not fit in the inspection buffer or was not completed within the wait time	Large POST requests are blocked or cut off; why?
No record in Event Logs, response 418	In Blocking mode, the scan could not be completed within the 2-second time limit; with large files, the likelihood increases because the whole body is scanned	Why does a request that received 418 not appear in Event Logs?
No record in Event Logs, response 408 or the upload is cut off	While WAF is on, the body is waited for by being buffered; the buffered portion did not arrive within HTTP Request Timeout (default 30 s)	Large file uploads fail; why?

Definitive rules:

• After the path, query and header inspections, the body of a multipart upload request is inspected in this order: Raw Body Size → buffer (Block Unparsed Contents) → Block All Form Contents → parsing of the body (Block Invalid Form Contents) → Raw signature scan of the whole body → Allowed Upload Mime Types → signature scan of the file contents → Form signature scan of the file name and field values → Form length and field list restrictions. The inspection stops as soon as the total score reaches the blocking threshold; the record shows the attacks up to that moment. After one violation is resolved, the next inspection may come to light.
• The file type is detected not from the Content-Type declared by the client but from the file's content; in plain text whose content yields no type, the type is completed from the file name extension. Unrecognized binary content counts as application/octet-stream, and text that has no specific format as text/plain. The entries in the list match the detected type as a substring (image covers all image types) and are written in lowercase (Does the file type check look at the client's Content-Type or at the file's content?).
• The ready-made list of the Any Paths rule has 14 types: application/octet-stream, application/pdf, text/plain, text/csv, application/json, application/zip, image/jpeg, image/png, image/gif, image/webp, image/svg+xml and three Office Open XML types (DOCX, XLSX, PPTX). Types that are recognized from their content but are not in the list (e.g. video/mp4, video/quicktime, application/x-rar-compressed, application/x-7z-compressed, the old Word and Excel formats application/msword, application/vnd.ms-excel, text/html, application/xml) are blocked.
• In Any paths, the Raw Body Size range is 1 – 268,435,456 bytes (256 MiB), and Allow Unparsed Body is selected for a body that does not fit in the buffer. In the page types created by Analysis & Learning, on the other hand, Allowed Upload Mime Types contains only the types seen during learning, Raw Body Size is widened according to the largest body seen, with a minimum of 16,384 bytes, and Block Unparsed Body and Block Invalid Form Contents come selected.
• The request is inspected with the Form and Raw common rule of the page type it matches. If the page type has no common rule of its own, the values are inherited from the glob rule that fits the path or from Any paths and appear in the Rule Source row of the detail panel (inheritance).
• All these inspections block in Blocking Mode and only produce a record in Monitor Mode; they are not scored in Learning Mode. The scan timeout blocks only in Blocking mode while Fail-open in the Request Body Limits window is off (default); in Learning and Monitor mode, a request whose scan cannot be completed is let through (the only exception is the scan being cut off while the WAF rules are loading and before the host group is determined: if the vService has a group in Blocking mode, this request is blocked (WAF Mode · Blocking Mode)).

Where Is It Monitored?

Screen	Path	What it shows
Event Logs	Left Monitor Panel → WAF-Protected vServices → vService → Event Logs	On the Attacks tab, Attack name, Attack area, Description, Corresponding rule, Learning suggestion; on the Request & Location tab, Matching path rules and HTTP headers
Page Types	WAF Management → mode card of the host group → N page types	The values on the Form and Raw tabs of the rule; for inherited values, Rule source
Debug Mode Logs	Left Monitor Panel → Load Balancer vServices → vService → Logs & Tracking (while the vService is in Debug mode)	Security action and Termination state for the requests that have no record in Event Logs; the screen requires monitoring permission in the Load Balancer area

How to Diagnose?

1. The Request ID on the blocking page and the time of the event are obtained from the user; if the response is 408 or a dropped connection, the diagnosis continues on the Large file uploads fail; why? page.
2. On the server filter tab of Event Logs, the Request ID is written in the Request Unique ID field and Save & Get Logs is clicked. If there is no record, the steps on the Why does a request that received 418 not appear in Event Logs? page are followed.
3. The row is clicked; on the Attacks tab, the Attack Name and Attack Area values of each attack are read and matched with the table above. In an Allowed Upload Mime Types record, Description writes the detected type.
4. Corresponding Rule shows the rule the request matched (a page type or Any paths); the change is made to this rule. Learning Suggestion writes what the teaching operation will change (e.g. Allowed upload mime types: video/mp4 will be added).
5. If the structural violation (type, size, structure) is not a false positive but a file that really should be rejected, no change is made; the WAF has worked as expected.

Solution: Four Methods

The methods are alternatives to each other. Individual false positives are taught from the record; a permanent setting for the same upload page is made in the Form or Raw common rule.

Your situation	Suitable method
There is a record in Event Logs; the block is a false positive	Method 1: Allow from Event Logs
The file type is rejected or the form structure inspection blocks	Method 2: The Form common rule of the upload page
A signature match in the body or the file content; Raw Body Size was exceeded	Method 3: The Raw common rule of the upload page
The file type will be added to the allow list from the command line	Method 4: WEB-CLI
The record is Block Unparsed Contents, or a 418 without a record	Large POST requests are blocked or cut off; why?
The upload is made only from a trusted source and it should not be inspected at all	Can I exempt certain IPs or requests from WAF inspection entirely (Whitelist Condition)?

Method 1: Allow from Event Logs Recommended

• How it works The attack in the record is taught: the file type is added to the allow list, the signature is taken into the OWASP Exclusions list of the related field, the Raw Body Size range is widened or the structure inspection (Block Invalid Form Contents, Block All Form Contents) is turned off. The change to be made is written beforehand in the Learning Suggestion row.
• Where it is opened Left Monitor Panel → WAF-Protected vServices → vService → Event Logs → record → Attacks
• Requirement Modify permission in the WAF area; the record being present in Event Logs (host group in Monitor or Blocking mode)
• vService type HTTP

Step-by-Step Configuration

1

Adım 1 Open the Event Logs screen

In the Left Monitor Panel, the WAF-Protected vServices category is selected, the vService is clicked and the Event Logs tab is opened.

2

Adım 2 Enter the scope of the record

On the server filter tab, the Request ID on the blocking page is written in the Request Unique ID field, or Date Range is selected so as to cover the time the upload was made (server filter).

3

Adım 3 Fetch the record

Save & Get Logs is clicked.

4

Adım 4 Open the record

The row of the upload request is clicked and the Attacks tab is selected in the preview; Attack Name, Attack Area, Description and Learning Suggestion are read.

5

Adım 5 Select the false positive attack

In the attack table, the box is checked only for the attack that is a false positive. If a real attack is also checked, it is taught as well.

6

Adım 6 Click Allow

The button above the table is clicked. The button carries the name Allow in a blocked record and Teach in a record written in Monitor mode (Allow / Teach).

7

Adım 7 Confirm

Yes is clicked in the Are you sure? question. The change is applied without a separate save or deployment step. In a cluster setup, the change is also sent to the peer device with the default auto-sync; if Manual Sync Mode is on, it is sent with Synchronize. Details: How do I allow a request that was blocked by mistake?

Verification

1Attacks columnTR7 side

The Attacks column of the taught record in Event Logs is examined.

ExpectedFirst number 0; row green

The first number of the column shows how many attacks the same request would trigger with the current rule set (Attacks column).

2UploadClient side

The same file is uploaded again.

ExpectedThe upload completes; no new record

If a new record is created, the next inspection has come to light; the record is examined with the same steps.

Method 2: The Form Common Rule of the Upload Page

• How it works The common rule of the Form tab in the page type of the upload path is edited: a type is added to the Allowed Upload Mime Types list, or Block Invalid Form Contents / Block All Form Contents is unchecked. The change is applied only to this page type; Any paths and the other pages do not change.
• Where it is opened Left Monitor Panel → WAF-Protected vServices → vService → WAF Management → N page types → rule → Form tab
• Requirement Modify permission in the WAF area
• vService type HTTP

Step-by-Step Configuration

1

Adım 1 Open the Page Types screen

In the Left Monitor Panel, WAF-Protected vServices is selected, the vService is clicked and the WAF Management tab is opened. The N page types link on the mode card of the host group the request falls into is clicked; the Page Types tab opens (accessing the screen).

2

Adım 2 Open the page type add form (if needed)

If the upload path has no row of its own in the list (if the Corresponding Rule in the record is Any paths or a broad glob rule), Add in the toolbar is clicked. If the upload path has a page type, the process continues with step 5.

3

Adım 3 Enter the path

The path of the upload request is written in the Path field without wildcard characters (e.g. /upload); the value is case-sensitive and must not end with /. Allowed Methods is Any Methods by default (Exact path add screen).

4

Adım 4 Save the page type

Add is clicked; the page type is added to the list. Until its own common rule is defined, the new page type inherits the Form and Raw inspections from the glob rule that fits the path or from Any paths.

5

Adım 5 Select the rule

The row of the upload path is clicked in the list; the detail panel of the rule opens on the right.

6

Adım 6 Switch to the Form tab

Form is clicked in the tab strip of the panel. If the Rule source row appears, the values are being inherited from another rule.

7

Adım 7 Open the common rule form

If the rule has no Form common rule of its own, Add Common Rule for Form is clicked; if it has one, Edit Common Rule for Form is clicked. The add form does not open empty; it comes filled with the Form values of the Any paths rule (Add common rule for Form screen).

8

Adım 8 Correct the field

According to the violation in the record:

Record	What is done in the form
Allowed Upload Mime Types	The Description value in the record (e.g. video/mp4) is added in lowercase to the Allowed Upload Mime Types list; for all images, image is enough
Block Invalid Form Contents	The Block Invalid Form Contents check is removed; a body that cannot be parsed is not blocked and goes through the Raw signature scan as raw content
Block All Form Contents	The Block All Form Contents check is removed

OWASP Check in Upload manages the scanning of the file contents and is checked by default; turning it off does not turn off the Raw scan of the whole body (I turned off upload scanning but files are still blocked; why?).

9

Adım 9 Save

Add (new common rule) or Edit (existing common rule) in the form is clicked; the WAF configuration is regenerated and applied without a separate deployment step. In a cluster setup, the change is also sent to the peer device with the default auto-sync; if Manual Sync Mode is on, it is sent with Synchronize.

Verification

1Detail panelTR7 side

The Allowed Upload Mime Types row on the Form tab of the rule is examined.

ExpectedThe added type is in the list; no Rule source row

2Attacks columnTR7 side

The Attacks column of the blocked upload record in Event Logs is examined.

ExpectedThe first number falls

Method 3: The Raw Common Rule of the Upload Page

• How it works The signature scan of the whole body and of the file contents uses the OWASP Check setting and the OWASP Exclusions list of the Raw tab; the false positive signature is added to this list. In the same form, the Raw Body Size range is widened.
• Where it is opened Left Monitor Panel → WAF-Protected vServices → vService → WAF Management → N page types → rule → Raw tab
• Requirement Modify permission in the WAF area
• vService type HTTP

Step-by-Step Configuration

1

Adım 1 Open the Page Types screen

On the WAF Management tab, the N page types link on the mode card of the host group is clicked. If the upload path has no page type, it is first created with steps 2–4 of Method 2.

2

Adım 2 Select the rule

The row of the upload path is clicked in the list; the detail panel opens.

3

Adım 3 Switch to the Raw tab

Raw is clicked in the tab strip of the panel.

4

Adım 4 Open the common rule form

Add Common Rule for Raw (if the rule has no Raw common rule of its own) or Edit Common Rule for Raw is clicked (Add common rule for Raw screen). The add form opens filled with the Raw values of Any paths.

5

Adım 5 Correct the field

Record	What is done in the form
Signature name, Attack area Raw or Raw@file-field	OWASP Check stays checked; the signature in the record (Attack name) is selected in the OWASP Exclusions list
Raw Body Size	The upper limit of the Raw Body Size range is increased, in bytes, according to the largest body the upload page will accept

If OWASP Check is unchecked, the whole body on this page and the contents of the uploaded files do not go through the signature scan at all; this is done only on upload endpoints where the risk is accepted. If the OWASP exclusions list is longer than the Max. OWASP Exclusions value (default 25), the signature scan in this field turns off completely.

6

Adım 6 Save

Add or Edit in the form is clicked; the change is applied without a separate deployment step. In a cluster setup, the change is also sent to the peer device with the default auto-sync; if Manual Sync Mode is on, it is sent with Synchronize.

Verification

1Detail panelTR7 side

The OWASP check and Raw Body Size rows on the Raw tab of the rule are examined.

ExpectedThe number of exclusions in the OWASP check row increases; Raw body size shows the new range

Method 4: WEB-CLI

• How it works A type is added to the Allowed Upload Mime Types list in the existing Form common part of the rule with the WEB-CLI waf rule-parts update command.
• Where it is opened WEB-CLI → waf host-groups · waf fw-rules · waf rule-parts
• Requirement WEB-CLI access and modify permission in the WAF area; the rule having a Form common part of its own
• vService type HTTP

Step-by-Step Configuration

1

Adım 1 Get the host group ID

waf host-groups list poolId <vService>

The ID of the default host group is defaultHost.

2

Adım 2 Get the rule ID

waf fw-rules list poolId <vService> hostGroupId <group>

The ID of the Any paths rule is wr-default.

3

Adım 3 Get the ID of the common part

waf rule-parts list poolId <vService> hostGroupId <group> ruleId <rule>

The part whose region is form and that carries no argument name is the common part. If it is not in the list, the rule is inheriting this region; the common part is created in the interface with Add Common Rule for Form in Method 2. The waf rule-parts add … loc form command in WEB-CLI writes the Block All Form Contents and Block Invalid Form Contents fields as on when they are not specified (loc form fields).

4

Adım 4 See the existing list

waf rule-parts show poolId <vService> hostGroupId <group> ruleId <rule> <part>

The formAllowedMimeTypes.0, formAllowedMimeTypes.1 … lines in the output are the types in the list.

5

Adım 5 Add the type to the first empty position

--formAllowedMimeTypes.N replaces the existing type at that position; for this reason, the new type is written to the first empty position. If the ready-made list of Any paths has not been changed, there are 14 types (positions 0–13) and the first empty position is 14:

waf rule-parts update poolId <vService> hostGroupId <group> ruleId <rule> id <part> --formAllowedMimeTypes.14 video/mp4

A signature exclusion (OWASP exclusions) is added from the interface, with Method 1 or Method 3.

Verification

1PartTR7 side

The part is displayed again.

Command: waf rule-parts show poolId <vService> hostGroupId <group> ruleId <rule> <part>

ExpectedformAllowedMimeTypes.14 video/mp4; the previous types in place

Common Mistakes

• Loosening Any paths. A change made to Any paths spreads to all the requests that fit no page type; the upload path is given its own page type and common rule.
• Adding the Content-Type declared by the client to the list. The type is detected from the file's content; the Description value in the record is added to the list.
• Making the change in a rule the request does not match. The setting is made to the rule written in Corresponding Rule in the record; a request that falls into an exact page type or a glob rule is not affected by a change in Any paths.
• Thinking that turning off OWASP check in upload stops all scanning. The whole body is scanned separately with the OWASP setting of the Raw tab (I turned off upload scanning but files are still blocked; why?).
• Writing to an occupied position in WEB-CLI. --formAllowedMimeTypes.0 replaces the first type in the list; the first empty position is first found with waf rule-parts show.
• Ruling out the WAF if there is no record. A request blocked by the scan timeout is not written to Event Logs; the trace remains in Debug Mode Logs (Why does a request that received 418 not appear in Event Logs?).

How it is done in the documentation

• Form · Allowed Upload Mime Types
• Form · OWASP Check in Upload
• RAW · Runtime: The RAW Inspection Order
• Event Logs · Attacks Tab
• WEB-CLI · loc form — the form body

Related questions

• Can I allow only certain MIME types in file uploads?
• I turned off upload scanning but files are still blocked; why?
• Large POST requests are blocked or cut off; why?
• Large file uploads fail; why?