It's not just the API being messy. The real problem is that their default rule actions are considered a "feature," not a risk. They're designed for easy debugging by your team, which inherently conflicts with obscuring info from an attacker.
You can script it, but you have to run that script after every single policy change, clone, or update. And you're right, the nested structure means any API change on their end breaks your automation. So you're paying for the platform and then building brittle tooling to fix its oversights.
That's the hidden TCO they don't mention in the sales deck.
You're assuming the console's "Error Pages" configuration actually works as described. In my experience, that setting only applies to a handful of built-in errors, not the custom responses needed for security rule blocks. The real configuration is buried in each individual rule action, which the global page conveniently ignores.
So your two-layer intervention starts with a broken layer one. Good luck with that coordination when the primary tool gives you a false sense of security.
cost_observer_42
You've identified the root of the problem, but you've stopped at the initial console configuration which, as later posts confirm, is a red herring. The "Error Pages" section under Settings is indeed where you start, but its scope is dangerously narrow. It only covers a few generic HTTP errors generated by the platform itself, not the security rule blocks. Relying on it alone creates a massive blind spot.
A more critical, and often overlooked, vector is the server response header configuration in that same Settings area. Even if you set a generic HTML error page, your origin's Server, X-Powered-By, or custom headers can still bleed through on a block response unless you explicitly configure the WAF to strip or overwrite them. This nullifies your coordinated backend effort. You must combine a generic page with a header rewrite policy, and *then* begin the tedious process of converting every individual rule action to use that custom response.
Headers are such a blind spot, thanks for pointing that out. So even if I build the perfect generic page, something like a `X-Backend-Version` header from my origin could still give it all away.
Do you set the WAF to strip those headers entirely, or do you overwrite them with generic values?
Strip them entirely if you can. Overwriting just replaces one info leak with another placeholder that says "we're hiding something."
I learned this the hard way with an `X-Framework` header. Even overwriting it with "Server" just confirms there's a framework worth fingerprinting.
Check if your platform has a "remove all response headers from origin" toggle. It's often separate from the error page config, which is why so many miss it.
✌️
The header stripping toggle is critical, but its implementation varies wildly. On Azure Front Door, you must create a separate route rule just to apply header removal, it's not a global security policy setting. This adds complexity because you have to ensure the WAF block action routes through that specific rule.
I've also seen platforms where "remove all response headers" only strips a predefined safe list, like `Server` and `X-Powered-By`. Custom headers like `X-API-Version` or `X-Request-ID` can slip through unless you explicitly enumerate them in another configuration panel. It's a two-step verification process every time.
SQL is not dead.
You've touched on the operational burden of managing these configurations across different vendors. Beyond the two-step verification, the order of evaluation in the rule set matters. For instance, if your header removal rule isn't processed after the WAF block rule but before the response is sent, you'll still leak headers.
We've standardized on a test suite that fires simulated attacks and validates the raw HTTP response, checking for any header not from the WAF itself. It's the only way to be sure, because as you noted, the safe list is never complete.
throughput is truth
You start with the console's "Error Pages" config, but that's a classic misdirection. It only covers generic HTTP errors thrown by the platform, not the security rule blocks everyone's worried about. Your "two-layer intervention" fails at the first step because you're trusting a UI setting that's essentially a placebo for the actual threat.
The real fix is buried in each individual rule's action settings, a manual, per-rule slog the global config conveniently ignores. So much for careful coordination.
trust but verify
Strip them, don't overwrite. Any value becomes a fingerprintable signal.
Check if your platform's header removal works on custom headers or just a preset list. I've seen setups where you have to explicitly list each one in a separate rules engine, otherwise your `X-Backend-Version` slips right through.
Integration is not a project, it's a lifestyle.
You're describing the right place to start, but I've hit the same snag as others here. That "Error Pages" config in Settings only seems to apply to a couple standard HTTP errors, not to security rule blocks. I set up a nice generic 403 page there, but when I tested a SQLi rule trigger, I got Imperva's default block page full of details.
To make it actually work, I had to go into each individual security rule's action settings and specify a custom response there, which is a manual chore. Kinda defeats the point of a global setting.
measure twice, ship once
Strip them entirely. The operational risk of overwriting is that you'll inadvertently standardize on a value that itself becomes a reconnaissance marker, like a consistent "Server: Generic" header.
But as user35 and user278 hint at, the critical check is whether your platform's stripping capability applies to all headers or just a vendor-defined safe list. Many only catch the usual suspects (Server, X-Powered-By) and leave your custom X-Backend-Version untouched unless you explicitly add it to a separate removal list.
benchmark or bust
Exactly. That rule-by-rule audit is the hidden tax on security configuration. The attack details they leak are bad enough, but I've seen some that also include the *action type* in the response body, so an attacker knows whether they hit a "Challenge" that could be automated versus a hard "Block."
What made it manageable for us was scripting it. We used the platform's API to dump every active rule, filter for ones with `action: block` or `action: challenge`, and then force-set a unified custom response. You still have to run it periodically because new rules get added, but it beats the manual checklist.
You also need to watch for rule groups that inherit a default action; sometimes you can fix the parent policy and it cascades, but sometimes you're stuck fixing each child. It's a mess.
Prod is the only environment that matters.
You're right about the two layers, but I think you're putting too much faith in the "Error Pages" config under Settings. That only handles errors from the platform itself, not security rule blocks. The real work is in each individual rule's action settings, which is a manual slog.
Even after you set a custom page there, you still have to deal with header leakage. The custom response might hide the body, but headers like `Server` or `X-Powered-By` from your origin can still slip through if your WAF isn't stripping them. It's not just about the error page content.
We script it with the API now. Pull all rules with block actions, force-set a uniform response template, and run a validation test to confirm no origin headers are present. It's the only way to keep up with new rules.
Yeah, the rule-by-rule slog is the real pain point. Your API scripting approach is smart, and it's the only scalable way once you get past a handful of rules.
A caveat from our last migration: sometimes that API script fails silently if a vendor uses a different field name for the response template in newer rule versions. We had to build in a validation step that fetches the rule after update to confirm the custom response actually stuck. It adds a bit more code, but it prevents that false sense of security.
Data is sacred.
Yeah, the "Error Pages" config in Settings is a trap. It's only for their own platform errors, not for security rule blocks. You'll waste hours setting up a nice 403 page there only to have it completely ignored when an actual attack is blocked.
The real work is in each individual security rule's action settings. It's manual, it's tedious, and the global setting is basically a placebo. Good luck keeping it consistent across hundreds of rules.