Troubleshoot blocked web traffic
Platform-generated public routes include an origin web application firewall (WAF). It inspects incoming HTTPS requests before they reach your Component and blocks requests whose combined signals resemble an application attack. You do not need to install anything in your image.
The WAF is a safety net, not application security. It can reduce exposure to common, recognizable attacks, but it cannot determine what is safe or authorized for your application. A request passing the WAF is not necessarily safe, and a route covered by the WAF is not necessarily secure.
You remain responsible for securing the application itself. This includes authentication, authorization, tenant isolation, input validation, output encoding, safe database access, secret handling, dependency and image patching, rate limiting, abuse prevention, file validation, and application-specific monitoring. Design and test those controls as though the WAF were not present.
Requests the WAF blocks
Section titled “Requests the WAF blocks”The gateway runs Coraza with the OWASP Core Rule Set at paranoia level 1. The rules cover common web attacks and protocol anomalies, including:
- SQL injection and cross-site scripting patterns;
- command injection and path traversal;
- server-side request forgery patterns;
- malformed or evasive HTTP requests; and
- common scanner and automated attack signatures.
Rules contribute to an anomaly score. deliberate. uses an inbound blocking threshold of 15 rather than the stricter CRS default. This keeps the baseline protection active while reducing false positives from ordinary JSON, quoted values, file uploads, and framework-generated requests. Two broad protocol rules that reject modern content types and proxy headers are disabled globally.
Check whether your route is covered
Section titled “Check whether your route is covered”| Traffic path | Current behavior |
|---|---|
| Platform-generated public HTTPS route | Request passes through the WAF |
| Plain HTTP | Redirected to HTTPS before reaching the application |
| Private Net route | WAF bypassed after device authentication and route authorization |
| Customer-owned custom domain | Not currently covered by the tenant WAF filter |
| TCP or UDP exposure | Not HTTP and therefore not inspected by the WAF |
The Private Net bypass is intentional. A private route is already restricted to authenticated devices belonging to explicitly allowed Team members, and admin tools commonly send SQL or other technical input that resembles an attack to a generic HTTP rule set. Private Net controls who can reach the route; it does not replace authentication or authorization inside the application.
Custom-domain coverage is a current platform limitation. Do not assume that attaching a custom hostname adds WAF inspection until this page states that the custom-domain listener is covered.
Identify a gateway response
Section titled “Identify a gateway response”A request that reaches the anomaly threshold is stopped at the gateway and normally receives HTTP 403. Your component never receives that request, so its application logs may contain no corresponding entry.
The WAF inspects request headers, paths, query strings, and request bodies. A request that exceeds the WAF’s body-processing limit can receive HTTP 413. This matters for applications accepting large uploads: test the real upload path before relying on the platform-generated public route for large objects.
Response-body inspection is disabled. Responses are still carried over TLS, but the WAF does not scan or rewrite content produced by your application.
Report a false positive
Section titled “Report a false positive”First confirm whether the response came from the gateway rather than the application:
- Record the hostname, path, HTTP method, response status, and UTC timestamp.
- Capture the response’s request ID or correlation header when present.
- Check whether the request is absent from the component’s application logs.
- Reduce any sensitive request body to the smallest reproducible shape before sharing it with support.
There is currently no customer-authored WAF exclusion field. Contact deliberate. with the details above when legitimate traffic is blocked. A broad bypass is not applied silently: an exclusion must be narrow enough to preserve protection for unrelated routes and customers.
Coverage limits
Section titled “Coverage limits”The origin WAF is a best-effort additional filter for common HTTP attack patterns. It does not provide or replace:
- application authentication, authorization, or tenant isolation;
- application-aware validation and output encoding;
- API quotas, rate limiting, or abuse prevention;
- malware scanning of uploaded files;
- dependency patching or image vulnerability remediation;
- protection against every novel or application-specific attack; or
- a global content-delivery or volumetric DDoS service.
Use Private Net for administrative interfaces that should not be public. For public applications, treat the WAF only as an additional safety net in front of the security controls implemented by the application itself. Never use WAF coverage as the reason to omit or weaken an application security control.