Description:
When using the protocol for file uploads, requests are being blocked by Azure’s Web Application Firewall (WAF) due to an issue with Content-Types.
The issue is that the WAF uses an allow-list which is based on the official IANA “media types” list. However, TUS uses a non-standard Content-Type: application/offset+octet-stream, which is not recognized by the WAF’s allow-list. This results in the blocking of TUS upload requests.
Extract from the Microsoft Azure WAF rule’s documentation :
Rule ID : 920420
Anomaly score severity : Critical - 5
Description : Request content type isn’t allowed by policy
This rule is part of the OWASP CRS Protocol Enforcement Ruleset which is used by Microsoft in version 3.2 for their WAF.
Expected Behavior:
It would be preferable if TUS could use a standard Content-Type that is recognized by the WAF (such as application/octet-stream), instead of relying on a non-standard type like application/offset+octet-stream. This would prevent upload failures due to WAF restrictions without requiring manual configuration changes to the WAF allow-list.
Observed Behavior:
Upload requests fail consistently with an error from the WAF, indicating that application/offset+octet-stream is not recognized and is blocked.
Solutions:
While modifying the WAF to allow this specific Content-Type is a quick workaround, some users may be reluctant to bypass WAF rules due to security concerns.
A more sustainable long-term solution would be to consider updating TUS to use a widely recognized Content-Type (e.g., application/octet-stream) for uploads. This would enhance compatibility with WAFs and other security systems that enforce strict Content-Type allow-lists.
Question:
Is it something that could be considered for a future update? Could TUS explore the use of a standard Content-Type or provide an option to replace application/offset+octet-stream with an IANA-approved type in the future?