A cheat-sheet table mapping OWASP Top 10 to WAF protections
Contents
Mapping OWASP Top 10 Risks to WAF Capabilities
| OWASP Top 10 Risk | What the Attack Is | Can a WAF Mitigate It? | How a WAF Helps | Limitations |
|---|---|---|---|---|
| A01: Broken Access Control | Users access data or functions they should not | ❌ Limited | Blocks obvious parameter tampering and forced browsing patterns | Cannot understand business logic or authorisation flaws |
| A02: Cryptographic Failures | Weak encryption or sensitive data exposure | ❌ No | May enforce TLS and block insecure protocols | Encryption must be fixed in the application or infrastructure |
| A03: Injection (SQL, OS, LDAP, XPath) | Malicious input executed by backend systems | ✅ Yes | Detects SQL keywords, shell metacharacters, injection patterns | Can be bypassed with obfuscation if not tuned |
| A04: Insecure Design | Architectural flaws in application design | ❌ No | None | Requires secure SDLC and threat modelling |
| A05: Security Misconfiguration | Default settings, debug pages, open directories | ✅ Partial | Blocks access to admin paths and sensitive files | Misconfiguration must still be fixed at source |
| A06: Vulnerable and Outdated Components | Known vulnerable libraries and frameworks | ❌ Limited | Virtual patching for known exploit signatures | Cannot patch the underlying vulnerability |
| A07: Identification and Authentication Failures | Weak login, session handling issues | ✅ Partial | Rate limits brute force, blocks credential stuffing | Does not fix weak authentication logic |
| A08: Software and Data Integrity Failures | Supply chain attacks, unsafe deserialisation | ❌ No | None | Requires code signing and integrity controls |
| A09: Security Logging and Monitoring Failures | Lack of detection and alerting | ✅ Indirect | Provides telemetry and logs to SIEM | Does not replace SOC monitoring |
| A10: Server-Side Request Forgery (SSRF) | Server makes malicious internal requests | ✅ Partial | Detects suspicious outbound request patterns in some WAFs | Hard to detect without deep application context |
Key Takeaways for Cyber Security Engineers
What WAFs Are Very Good At
WAFs are highly effective against:
- SQL Injection
- Cross-Site Scripting (XSS)
- Command Injection
- Directory Traversal
- Remote File Inclusion
- Automated bots and credential stuffing
- Layer 7 DDoS
These align strongly with OWASP A03 Injection and A07 Authentication Failures.
What WAFs Are Weak At
WAFs provide little or no protection for:
- Broken Access Control
- Insecure Design
- Cryptographic Failures
- Software Supply Chain Risks
- Business Logic Abuse
These require:
- Secure coding
- Architecture reviews
- DevSecOps pipelines
- Identity and access controls
Real Interview Talking Point (High Value)
“A WAF mitigates exploit techniques, not design flaws. It is a compensating control, not a substitute for secure development.”
This sentence scores very highly in senior security engineer interviews.
Practical SOC / Detection Engineering Notes
Security engineers often use WAF logs to detect:
- OWASP Top 10 scanning activity (Burp, sqlmap, Nikto)
- Automated exploitation attempts
- Botnet credential stuffing campaigns
- Reconnaissance of admin endpoints
Typical detection rules include:
- High rate of 403 or 406 responses
- Repeated injection signatures
- Requests to
/wp-admin,/phpmyadmin,/cgi-bin - Excessive login failures