What Is a WAF and Do You Actually Need One
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
A WAF is one of the most oversold and most misunderstood security controls. Vendors claim WAFs prevent breaches; critics say WAFs are easily bypassed and give false confidence. Both are partially true.
A WAF does not make insecure code secure. It does significantly raise the cost of common automated attacks, provides a detection layer that alerts on attack attempts against your application, and can apply virtual patches for known CVEs before your development team can deploy a code fix.
What a WAF Actually Blocks (and What It Does Not)
What WAFs reliably block:
-
Known attack signatures: SQL injection patterns (
' OR '1'='1), XSS payloads (<script>alert(1)</script>), path traversal (../../../etc/passwd), command injection, and other attack patterns with well-established signatures. WAF vendors maintain rule sets (OWASP Core Rule Set, vendor-specific threat intelligence) that are updated as new attack patterns emerge. -
Automated scanners: Tools like sqlmap, nikto, and nuclei use recognizable request patterns, headers, and user-agent strings. A WAF configured to detect scanner signatures blocks most automated vulnerability scanning before it can identify exploitable weaknesses.
-
Common bot traffic: Credential stuffing bots, scraping bots, and vulnerability scanning bots exhibit behavioral patterns (request rate, request structure, JavaScript challenge failure) that WAFs can detect and block.
-
Virtual patching: When a new vulnerability (like Log4Shell, CVE-2021-44228) is disclosed, the WAF vendor publishes a rule that blocks the attack pattern within hours: before your development team can update the vulnerable library and deploy a patch. This window protection is one of the highest-value WAF use cases.
What WAFs do not reliably block:
-
Business logic flaws: A WAF cannot understand that an attacker who sets
quantity=-1in a checkout request is attempting a price manipulation attack. The request is valid HTTP; only application context reveals the abuse. -
Authenticated attacks: Once an attacker is authenticated (via stolen credentials or a valid session), their requests look identical to legitimate user requests. A WAF cannot distinguish them without application-layer integration.
-
Novel or custom payloads: A skilled attacker who specifically targets your WAF can encode attacks to bypass signature detection. WAF bypass techniques are well-documented and effective against WAFs that rely exclusively on signature matching.
-
Application vulnerabilities that produce no malicious traffic: IDOR/BOLA (accessing another user's data via a valid ID), insecure direct object references, and authorization bypasses produce traffic that looks completely legitimate from the WAF's perspective.
WAF Deployment Modes
WAFs come in three deployment models:
1. Cloud WAF (most common for new deployments): Your DNS points to the WAF provider's infrastructure rather than directly to your server. All traffic passes through the WAF before reaching your application. Examples: Cloudflare WAF, AWS WAF with CloudFront, Akamai Kona Site Defender, Fastly Next-Gen WAF.
Advantages: No on-premises infrastructure, scales with traffic, includes DDoS protection from the provider's global network, rapid rule updates.
Disadvantages: The WAF provider sees all your application traffic (including authenticated session data): evaluate the privacy implications. Some cloud WAFs add latency for users far from WAF PoPs.
2. On-premises WAF appliance: A hardware or virtual appliance positioned in front of your web servers. Examples: F5 BIG-IP ASM, Fortinet FortiWeb, Imperva SecureSphere.
Advantages: Traffic stays on your network: no third-party sees application data. Deep integration with on-premises infrastructure.
Disadvantages: Requires on-premises infrastructure, specialized staff to manage, does not provide DDoS protection at scale. Largely displaced by cloud WAFs for new deployments.
3. Embedded (agent-based): A module embedded in the web server or application framework itself. Examples: ModSecurity (Apache/Nginx module), AWS WAF SDK for application-level inspection.
Advantages: Closest to the application: can use application context for decision-making. No separate appliance or DNS change required.
Disadvantages: Agent must be updated per application deployment. Adds CPU overhead to application servers.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Do You Actually Need a WAF? The Decision Framework
A WAF is appropriate when:
Your application is internet-facing and processes sensitive data. If your application handles PII, payment data, health records, or authentication credentials and is accessible from the internet, a WAF provides meaningful risk reduction. The automated attack surface for internet-facing applications is large: scanners probe everything.
You cannot patch immediately when CVEs are disclosed. If your deployment process takes days or weeks, a WAF provides critical coverage during the window between vulnerability disclosure and patch deployment. Log4Shell, Apache Struts, and similar critical CVEs with active exploitation within hours of disclosure are exactly the scenario where virtual patching via WAF prevents breaches.
You have a compliance requirement. PCI DSS Requirement 6.4 explicitly requires a WAF for internet-facing web applications that handle cardholder data. If you are PCI-scoped, a WAF is not optional.
You need DDoS protection alongside application security. Cloud WAF providers (Cloudflare, AWS CloudFront + WAF, Akamai) bundle volumetric DDoS protection with application-layer WAF in a single deployment: more cost-effective than separate controls.
A WAF is NOT sufficient when:
- Your application has custom business logic vulnerabilities (BOLA, mass assignment, authentication flaws): fix these in code
- Your development team cannot allocate time to tune the WAF: an untuned WAF in detection-only mode provides no security value
- You are treating the WAF as a substitute for code reviews, SAST/DAST testing, or dependency management
The realistic expectation: A properly configured WAF reduces your exposure to automated attacks by 70-90%. It does not eliminate risk from sophisticated, targeted attackers or application-layer logic flaws. Use it as one layer in a defense-in-depth stack: not as the stack.
Getting Started: Cloud WAF Configuration
For most organizations deploying a WAF for the first time, a cloud WAF is the fastest path to value.
Cloudflare WAF (free tier covers many small applications):
- Change your domain's nameservers to Cloudflare
- Enable the OWASP Core Rule Set under Security > WAF > Managed Rules
- Set the WAF mode to 'Log' initially: review logs for 7-14 days before enabling blocking
- Identify legitimate traffic being flagged; create page rules or exceptions to allow it
- Switch to 'Block' mode once false positives are under control
AWS WAF with CloudFront:
- Create an AWS WAF Web ACL
- Add the AWS Managed Rule Groups: AWSManagedRulesCommonRuleSet, AWSManagedRulesSQLiRuleSet, AWSManagedRulesKnownBadInputsRuleSet
- Set all rules to Count (log-only) initially
- Associate the Web ACL with your CloudFront distribution
- Monitor WAF sampled requests for 7-14 days; add exceptions for legitimate traffic patterns
- Transition rules from Count to Block once tuned
The tuning step is mandatory. A WAF deployed in blocking mode without tuning will block legitimate traffic within the first few hours: users will report errors, and you will either disable the WAF or spend emergency time fixing false positives. Always deploy in log/detection mode first.
The bottom line
A WAF operates at the HTTP application layer, blocking SQL injection, XSS, path traversal, automated scanners, and known exploit patterns that network firewalls cannot see. It does not fix insecure code and does not block business logic vulnerabilities. Deploy a cloud WAF in log mode first, tune for 2 weeks, then enable blocking. The highest-value WAF use cases are: virtual patching during the CVE-to-patch window, reducing automated attack noise, and meeting PCI DSS Requirement 6.4 for cardholder data applications.
Frequently asked questions
What does a web application firewall (WAF) protect against?
A WAF protects against common web application attacks including SQL injection, cross-site scripting (XSS), path traversal, and known exploit patterns: by inspecting HTTP/HTTPS traffic at Layer 7 and blocking requests that match attack signatures. It also blocks automated vulnerability scanners and provides virtual patching for known CVEs before code-level fixes can be deployed.
Is a WAF enough to secure a web application?
No. A WAF reduces exposure to automated attacks and known exploits but does not fix application-layer vulnerabilities like broken object-level authorization, business logic flaws, or authentication weaknesses: these require code fixes. A WAF is one layer in defense-in-depth, most effective when combined with secure coding practices, dependency management, and regular security testing.
What is the difference between a WAF and a next-generation firewall (NGFW)?
A NGFW operates at Layers 3-4 (network and transport) and inspects IP addresses, ports, protocols, and application types. It can block traffic by port, protocol, and application signature but cannot inspect the content of HTTP requests. A WAF operates at Layer 7 (application) and inspects the full content of HTTP/HTTPS requests: URL patterns, headers, cookies, and request bodies. A NGFW cannot block SQL injection or XSS because those attacks use legitimate HTTP traffic. Both operate at different layers and complement each other: NGFW for network-layer threats, WAF for application-layer threats.
How do I deploy a WAF without breaking my web application?
Deploy in detection mode first (never blocking mode on day one). Route traffic through the WAF but configure it to only log, not block, rule matches. Monitor false positives for 2-4 weeks: look for rules that trigger on legitimate traffic and tune them. Common false positive sources: security scanners run by your own team, legitimate OWASP rule triggers from form fields that contain SQL-like strings (search boxes, address fields), and API clients sending non-standard content types. Build an exception list for confirmed false positives before enabling blocking. For third-party WAFs (Cloudflare, AWS WAF), use managed rule groups in 'Count' mode first.
Does Cloudflare WAF protect against DDoS attacks?
Cloudflare WAF is bundled with Cloudflare's DDoS protection as part of the same proxy service: all traffic enters through Cloudflare's network before reaching your origin server. Cloudflare automatically mitigates volumetric DDoS attacks (Layers 3/4) on all paid plans. The WAF component specifically handles Layer 7 (application-layer) attacks: HTTP floods, credential stuffing, and web application exploits. For DDoS mitigation, the relevant Cloudflare features are DDoS Managed Rulesets and Rate Limiting, which are separate from the WAF custom rules but operate on the same traffic.
How do WAF managed rules differ from custom rules and when should you write custom rules?
Managed rules are curated rulesets maintained by the WAF vendor or a standards body (OWASP Core Rule Set, AWS Managed Rules, Cloudflare Managed Ruleset) that cover broad attack categories: SQL injection, XSS, known CVE patterns, and scanner signatures. They are updated regularly as new attack patterns emerge and require minimal ongoing maintenance. Custom rules are written by your team to address application-specific behavior that generic signatures cannot handle: blocking requests that match your application's known-bad patterns, rate limiting specific endpoints that generic rules miss, or allowing specific traffic that managed rules incorrectly block. The practical workflow: start with managed rules in log mode to establish a baseline, resolve false positives by writing targeted exception rules, and add custom rules only for attack patterns specific to your application (blocking abuse of a specific API endpoint, restricting access to an admin path by IP range, or enforcing a business rule like requiring a specific header). Custom rules require ongoing maintenance as your application changes: document each custom rule's purpose and review them quarterly to remove rules that no longer apply.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.