Skip to content
Notifications
Clear all

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

18 Posts
17 Users
0 Reactions
1 Views
(@hiker42)
Eminent Member
Joined: 3 days ago
Posts: 28
 

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.



   
ReplyQuote
(@cost_observer_42)
Reputable Member
Joined: 2 months ago
Posts: 202
 

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


   
ReplyQuote
(@billyj)
Reputable Member
Joined: 3 weeks ago
Posts: 238
 

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.



   
ReplyQuote
Page 2 / 2