WAF Rule Baseline: The Protection Checklist to Enable in Your First Week
Once a WAF sits in front of your site, security no longer comes from "having a firewall" but from which rules you enable and how you enable them. Look through recent breach reports and you will see that most compromised sites fell to well-known OWASP Top 10 techniques — SQL injection, cross-site scripting, command injection, path traversal — rather than exotic zero-days. These attacks have mature detection signatures and can be blocked before they ever reach your application. The baseline below gives small and mid-sized sites a rule set that is effective without being overly aggressive.
Core Rule Set to Enable
| Rule | What It Blocks | Suggested Action | Notes |
|---|---|---|---|
| SQL injection | Malicious parameters spliced into SQL (' OR 1=1--) |
Observe for 3 days, then block | Pair with parameterized queries for defense in depth |
| XSS filtering | <script>, onerror=, javascript: payloads |
Block | Combine with CSP headers |
| Command injection detection | ;, ` |
, $(...)`, backticks |
Block |
| Path traversal | ../, %2e%2e%2f |
Block | Prevents reading sensitive files like /etc/passwd |
| Malicious crawler / UA restrictions | Scanners, scrapers, vulnerability probes | Observe, then block | Maintain a list of known bad user agents |
| High-frequency IP rate limiting | Credential stuffing, API abuse, CC attacks | Rate-limit above threshold | Start at about 60 req/min, return 429 beyond that |
This list maps closely to the managed rule sets shipped by major WAF providers — the Cloudflare OWASP Core Ruleset, AWS WAF managed rule groups, and the open-source ModSecurity CRS. You rarely need to write rules from scratch; enable the managed set and tune it to your site.
Roll Out in Phases: Observe → Block → Whitelist
Enabling everything in blocking mode from day one has one predictable outcome: you get woken up by false-positive alerts at 3 a.m., and by morning you have switched the whole thing off. A safer path has three phases.
Phase one: observation mode (24–72 hours). Set rules to log-only and collect real hits. Pay attention to two kinds of traffic: requests with obvious attack signatures (e.g. SQL keywords), and borderline cases that could break normal features. During this period, review the logs at least once a day and note the source IP, path, and user agent of suspicious requests.
Phase two: switch to blocking. Once the observation window closes, move the high-confidence rules (command injection, path traversal, SQL injection) to blocking. Give the XSS and malicious-UA rules another day or two. Keep watching the logs — if a page suddenly shows many "blocked" events from legitimate users, that rule needs adjustment.
Phase three: build a whitelist workflow. False positives are unavoidable; what matters is having a process for them: a user reports a broken page or a failed login → pull the blocked request from the logs → decide whether it was a false positive or an attack → if a false positive, add a scoped exception for that rule. Record the reason for each exception so the whitelist does not quietly grow until it means nothing. Exceptions should target a specific rule ID, URI, and IP — never a blanket bypass for the whole domain.
A Real-World Example
A small cross-border e-commerce team turned on a WAF, and on day three the logs filled with requests shaped like id=1' AND SLEEP(5)-- — someone pointing a public SQL-injection scanner at the site. Because the rules were already in blocking mode, every request was stopped before reaching the origin: zero impact on business, just a few extra lines in the security log. Two weeks later, a credential-stuffing attempt hit the admin login and was stopped by the IP rate limit; after the IP was banned the attacker moved on. Both cases show that the baseline handles the "known attacks" majority, leaving only ongoing observation and manual review.
Launch Checklist
- High-confidence rules are in blocking mode
- Someone reviews the observation logs every day
- A request-and-approval flow exists for whitelist exceptions
- Rule changes go through a pilot before being applied to peak traffic
- Alert channels (email/IM) are configured so false positives get handled quickly
Frequently Asked Questions
Why is my WAF enabled but nothing shows up in the logs? First confirm traffic actually flows through the WAF — check whether your origin IP is exposed and whether DNS points at the WAF nodes. Another common cause is a rule scope that misses the attacked path, e.g. a rule covering only /wp-admin while attackers go through /api.
My WAF in blocking mode is breaking my own admin panel — what now? This is exactly the problem the whitelist workflow should solve first. Confirm the blocked request's signature in the logs, add a precise exception (rule ID + URI) to the whitelist, and also check whether the panel faces real risks such as brute force — do not confuse "false positive" with "attack."
If I use a vendor's managed rule set, do I still need to write my own rules? In most cases, no. Managed sets cover the main OWASP Top 10 attack surface. Hand-written rules are usually for two situations: business-specific protection needs, and fine-tuning when a managed rule produces too many false positives. Start with the managed set, observe for a week, then decide whether custom rules are needed.
Reference: Cloudflare WAF docs https://developers.cloudflare.com/waf/
Reference: OWASP ModSecurity Core Rule Set https://coreruleset.org/
Reference: AWS WAF managed rule groups https://docs.aws.amazon.com/waf/latest/developerguide/aws-managed-rule-groups.html