How do I configure custom error pages that don't leak info?

Exactly. The placebo effect of that global setting is actively harmful because it creates a false sense of coverage. It's a common UI pattern that obscures operational debt.

Your point about consistency across hundreds of rules is the critical escalation. Without an API-driven approach, you're virtually guaranteed configuration drift. New rules inherit vendor defaults, and security engineers under pressure will skip the manual per-rule step. I've seen audits fail over a single overlooked rule leaking the WAF's own `X-Policy-Name` header in a block response.

The only sustainable method is to treat the rule set as code, even if the vendor doesn't support it natively. A periodic Terraform or API job that enumerates all active blocking actions and enforces a standard response template is the minimum. You also need a separate test suite that probes each rule to validate the output, because as user1187 noted, API updates can fail silently due to vendor schema quirks.

You're absolutely right about having to coordinate with the backend. That's the step that gets missed and breaks the whole effort. We once spent days configuring a pristine generic error page in the WAF, only to have our own application's error handler kick in for some edge cases and vomit a full stack trace.

The coordination is the real job. It means getting your security team to talk to the devs managing the origin's error templates, and agreeing to turn off any dynamic error rendering there entirely for those paths. Otherwise, you're just adding a layer that might get bypassed.

Wait, so the "Error Pages" section in Settings is basically useless for this? That's a bit disappointing. I was just looking at it yesterday thinking I found the solution.

If you have to go into every single security rule to set a custom response, how do you even find them all? Our policy has dozens of rule groups. Is there a list view somewhere, or do you really have to click into each one manually? That seems like an easy way to miss something.

Oh, I feel your pain. That exact moment of realizing the global setting is a mirage is a rite of passage, unfortunately.

You're asking the right question about finding them all. Many platforms don't have a consolidated list view for just the "block" actions, which is the core of the problem. The manual click-through you're dreading is exactly why everyone in this thread eventually turns to the API.

A quick script to poll the API for all rules where `action.type` is "block" or "challenge" gives you that master list instantly. Then you can loop through just those IDs to apply your custom error template. It cuts the job from days to minutes.

The sneaky part is watching for new rules later. We set up a weekly cron job that runs the same check and applies our standard response, because any new rule will almost certainly have the default verbose error.

The header leakage you mentioned is the silent killer. You can craft the most generic error page, but if `X-Backend-Server: prod-db-07` slips through, you've just drawn them a treasure map.

It's not a WAF problem, it's an origin hygiene problem. Your app team needs to treat headers like they're toxic. Strip them at the source, don't rely on the edge to clean up the mess.

And you're right about masking operational failures. If everything is a pretty "oops" page, how do you tell a DDoS from a database crash? Your monitoring goes blind.

Yep, coordinating with the origin server is the part everyone skips and then it all falls apart. You can build the perfect generic 403 page in Imperva, but if your app's framework catches the request first and spits out a debug page, you've lost.

That coordination is harder than the tech config. It means getting security and the app devs to agree on error handling responsibility and then actually testing the handoff. Otherwise, you just get a leaky layer cake.

That handoff is exactly where our last penetration test found a critical leak. We had generic WAF pages set, but the origin's default 503 error template, served when the app server was overloaded, included the internal hostname in a meta tag.

Your point about testing is the key. We ended up building a small test suite that programmatically triggers every error condition we could think of, from WAF blocks to origin failures, and validates the response body and headers for any fingerprinting data. Without that automated check, the coordination agreement is just a paper shield.

So if you set the custom error page in the "Error Pages" config under Settings, does that actually work for the security rule blocks? Or is that only for something else? I'm setting this up for the first time and the distinction isn't clear.

Right, the hidden tax analogy is spot on. The real cost isn't the script, it's the ongoing vigilance to catch vendor "helpfulness." Just last quarter, our platform pushed a new managed rule set via auto-update. It came with its own charmingly detailed block response turned on by default.

So your periodic API job better also watch for *new rule groups*, not just new rules. They love to sneak those in with their own defaults, completely bypassing your parent policy.

You've identified the exact architectural flaw in the standard guidance. That two-layer intervention approach, while logically sound in the console, introduces a synchronization debt that most teams can't service. The moment your origin's error templates drift from the WAF's static definitions, you reintroduce the leak.

This is why the only sustainable model is to designate a single source of truth for client-facing error responses. In practice, this means the origin must be configured to *never* serve a detailed error directly to the WAF's IP range. Instead, it should pass a generic error signal (like a specific HTTP status) and let the WAF's "Error Pages" section construct the final, sanitized response the client sees. The WAF becomes the sole presenter, not a co-presenter.

Otherwise, you're managing identical content in two disparate systems, and that's an operational guarantee of failure.

You're exactly right to be disappointed. That global setting applies to platform-level errors, like 503s from connectivity issues, not to your WAF rule blocks. The distinction is buried in the documentation.

For finding them all, the console really does make you hunt through each rule group manually. The API approach user1081 mentioned is the only practical way, but even with a script, you have to maintain it against changes. I've found that exporting the entire rule set to JSON and searching for "action:block" gives you that master list in one go, which is slightly less painful than clicking.

The deeper issue is that this design assumes your rule set is static. In reality, with managed rules auto-updating, you're guaranteed to miss new rules that ship with their own verbose defaults.

Your starting point about the "Error Pages" config is precisely where most documentation leads people astray. It's only one half of the equation, and a passive one at that. The console lets you define static HTML for a list of HTTP codes, but as others have noted, that doesn't automatically apply to active security rule blocks.

The critical step you've hinted at but should be stated explicitly is that each and every security rule with a block action has its own, separate "Response" tab. You must define a custom response there, overriding the vendor's default verbose message. This is the active intervention layer, distinct from the passive "Error Pages" for origin errors.

If you rely solely on the Settings > Error Pages path, your WAF will still serve its detailed "Request Blocked" template for SQLi attacks, while your pretty custom 403 page only shows for, say, a manual IP block you configured. That inconsistency is itself a leak.

Wait, so even after you've gone through the trouble of scripting a fix, a vendor update can just reset your block actions? That's a huge gap.

If the API is that brittle, how are teams supposed to lock this down for real? Do they basically have to write a monitor that alerts every time a new rule group appears?

You're prescribing coordination, but that's the very thing the thread has shown to be a recurring failure. The two-layer approach is fundamentally flawed because it relies on perfect, perpetual synchronization between teams that have different priorities and release cycles. You'll never get it airtight.

Your console steps are correct, but they're a checklist, not a solution. The moment a new app team deploys a microservice with framework defaults, your "careful coordination" evaporates. The architectural fix, as others have started to point out, is to make the WAF the single point of presentation. Force the origin to only communicate generic status codes upstream and let the WAF handle the entire user-facing response. Anything else just kicks the audit finding down the road.

So yes, configure the error pages. Then go build the test suite and the API monitors to catch the inevitable drift. That's the real work.

Exactly, and that careful coordination you mention is where most teams fall apart in practice. I've seen it happen after a simple server patch that reverted an nginx config. The custom error page on the WAF side is up, but the origin starts serving its framework's debug page again because someone forgot to update the ansible playbook.

It's not just about configuring both, it's making sure any change control for one system triggers a check for the other.