A WAF policy is the container that holds every setting a web application firewall applies to your traffic: the managed rule sets the vendor maintains, the custom rules you write, the exclusions that stop false positives, and the mode (detection or prevention) that decides whether a match is logged or blocked. Getting value from a WAF is mostly about understanding that stack, because a policy in the wrong mode either protects nothing or blocks your own customers.
Teams turn a WAF on, get a flood of false positives, and turn it back off. The fix is almost never “a better WAF” - it is understanding the policy structure.
Table of contents
- What a policy actually contains
- Detection mode first, always
- Writing custom rules without self-inflicted outages
- Global, per-site, per-URL scope
- Where RunxBuild fits
- FAQ
What a policy actually contains
A WAF policy bundles four things. Managed rules are the vendor-maintained set that catches the common exploit classes - SQL injection, cross-site scripting, path traversal, remote file inclusion. Custom rules are yours, evaluated with higher priority, matching on IP, header, path, method, or body. Exclusions carve out specific rules or parameters that produce false positives. And the mode decides what happens on a match.
Everything else - which site the policy covers, which URLs, which listeners - is about where the policy is associated, not what it does. Understanding the four contents is enough to configure one sensibly.
Detection mode first, always
The single most useful habit: deploy a new policy in detection mode, where a triggered rule is logged but nothing is blocked. Let it run against real traffic for a week.
The logs tell you which rules fire, and critically, which fire on legitimate requests. A managed rule that flags your own API’s JSON payloads as an attack is a false positive you want to find in a log, not in a support ticket from a customer who got a 403.
Only after you have tuned exclusions for the false positives do you flip the policy to prevention mode. Skipping this step is why WAFs get a reputation for breaking sites.
Writing custom rules without self-inflicted outages
Custom rules evaluate before managed rules and can allow, block, or log. They support compound logic: conditions within one rule are combined with AND, and you express OR by writing separate rules.
The common mistake is a block rule that is broader than intended - blocking a whole IP range, a user agent, or a path that your own monitoring or a legitimate integration uses. Write the narrowest rule that does the job, give it a clear name and priority, and test it in detection mode first.
A rule to block a specific abusive IP range during an incident is fine. A rule to block everything from a country because one request looked bad will cost you real customers.
Global, per-site, per-URL scope
Policies associate at different levels, and the specific wins. A global policy applies baseline protection everywhere. A per-site policy overrides it for one application - useful when one app has stricter needs. A per-path policy narrows further, say stricter rules on an admin route than on the marketing pages.
The practical pattern is a conservative global baseline plus tighter overrides where the risk is concentrated: the login, the admin panel, the payment flow. You do not need a different policy per page - you need one where the risk genuinely differs.
Where RunxBuild fits
A WAF is one control in front of your application. The application itself still needs to validate input, parameterize its database queries, and keep secrets out of the code - a firewall rule is a safety net, not a substitute for a service that is not injectable in the first place.
On RunxBuild you deploy that service from a repo with environment variables for secrets, runtime logs to see what requests actually hit the app, and managed MySQL or Postgres with parameterized access patterns in the docs. The WAF catches the generic attacks at the edge; the application is where you make sure the specific ones have nothing to hit.
How this fits the rest of the stack
The cost of a project is the sum of its line items, not the headline number, and the RunxBuild hosting calculator is the right place to add them up: the service, the database, the storage, the bandwidth, each a separate figure. Model it before committing, not after the first invoice. The RunxBuild dashboard is where the running project shows its real usage in one place.
Useful related references:
- WAF functionality
- Best cloud WAF
- Cloudflare DDoS mitigation
- Database introduction
- Services introduction
FAQ
What is the difference between a WAF policy and a WAF rule?
A rule is a single condition-and-action, like block requests matching a SQL-injection pattern. A policy is the whole configuration that holds many rules - the managed set, your custom rules, exclusions, and the detection-or-prevention mode - and that gets associated with a site or path to take effect.
Should a WAF run in detection or prevention mode?
Start in detection mode so matches are logged but nothing is blocked, run it against real traffic, tune exclusions for the false positives you find, then switch to prevention. Going straight to prevention is the usual cause of a WAF blocking legitimate users.
What are WAF exclusions for?
Exclusions tell the WAF to skip a specific rule or a specific request parameter that is producing false positives. For example, if a managed rule flags your API’s legitimate JSON body as an attack, an exclusion lets that parameter through while keeping the rule active for everything else.
Do custom rules override managed rules?
Custom rules evaluate first, at higher priority. If a custom rule takes an allow or block action, the WAF usually stops there and does not continue to the managed rules for that request, so an overly broad custom allow rule can unintentionally bypass your managed protection.
Does a WAF replace secure coding?
No. A WAF catches generic, known attack patterns at the edge and buys time against new ones, but it is a safety net. Input validation, parameterized queries, and proper secret handling in the application are what make the specific attacks have nothing to exploit.