Requests Blocked by a Web Application Firewall
Find out whether a web application firewall is refusing requests to your application, whose firewall it is, and what to send to get a rule changed.
If requests to your application are refused with 403 Forbidden or a block page — often on one Environment while the same request works on another — a web application firewall (WAF) may be blocking them. This article explains how to find out which firewall it is and how to get a rule changed.
Symptoms
- A request returns
403 Forbidden, or a branded block page, before it reaches your application — your application's logs show no trace of it. - The same request works from another network, on another Environment, or for another user.
Which firewall is it?
Your traffic can pass through more than one layer that can refuse a request. Work out which one it is before asking for a change:
| Layer | Who manages it | How to recognise it |
|---|---|---|
| Cloudflare, if your hostname is proxied (the orange cloud) | You, in your Cloudflare account | The response carries a cf-ray header or shows a Cloudflare block page. The event appears under Security → Events in Cloudflare |
| A web application firewall in front of the platform load balancer — set up for some environments | CTO2B | A plain 403 Forbidden with no Cloudflare markers, and nothing in your application's logs |
| An IP allowlist on the Component's ingress | You, in the Component's Helm values | 403 Forbidden for any address not on the list — see IP Allowlisting for Applications and Databases |
| Your application | You | The request appears in your application's logs with a 403 response |
Check it yourself
- Note the full response: status code, response headers and body. A
cf-rayheader or a Cloudflare page means Cloudflare — look it up in your Cloudflare account's security events, which you manage. - Check your application's logs for the request — see Find Your Application Logs. If it is there, the 403 came from your application.
- Check for an IP allowlist on the Component. If the hostname is proxied through Cloudflare, an office IP on the allowlist never matches, because the platform sees Cloudflare's addresses — see Ingress Troubleshooting.
- Compare with a working case: the same request on another Environment, or from another network. A difference between Environments is a strong sign of a firewall rule that exists on one and not the other.
Ask for a rule change
If the block is not in Cloudflare, your allowlist or your application, raise a request with:
- the full URL and the HTTP method;
- the Environment;
- the exact time of one or more blocked requests, in UTC;
- the source IP address the request came from;
- the status code, response headers and body you received;
- whether the hostname is proxied through Cloudflare;
- what you want changed — allow an address or range, stop blocking a specific path, or only log instead of blocking — and whether it applies to production or non-production only.
Uptime checks can also be caught by bot filtering. If you filter bot or unrecognised traffic, see External Uptime Monitoring for how to let the checks through.
Related articles
- IP Allowlisting for Applications and Databases — allowlists on your own ingress
- Ingress Troubleshooting — 403, 503 and certificate problems on a hostname
- Ingress, Custom Domains and TLS — including Cloudflare traffic shielding
- Egress IP Addresses for Third-Party Allowlisting — the other direction: your application's outbound addresses
Updated 24 days ago