WAF Rules for OWASP Top 10 Protection: ModSecurity, AWS WAF, and Custom Rules
A Web Application Firewall is your first line of defense against the attacks that compromise applications every day — SQL injection, cross-site scripting, and request smuggling. The OWASP Top 10 catalogs the most critical web application security risks, and a properly configured WAF blocks the majority of automated attacks targeting these vulnerabilities. Therefore, this guide covers practical WAF configuration for ModSecurity and AWS WAF, including custom rules for threats that generic rulesets miss.
Understanding OWASP Top 10 in 2026
The OWASP Top 10 evolves as attack patterns change. Broken Access Control remains the number-one risk — it’s the most common vulnerability found in real-world applications. Moreover, injection attacks (SQL, NoSQL, command injection) still cause devastating breaches despite being well-understood for decades. The reason is simple: developers make mistakes, and a single unvalidated input can compromise an entire database.
Server-Side Request Forgery (SSRF) has risen in prominence because cloud environments are particularly vulnerable — an SSRF exploit against an AWS application can reach the instance metadata endpoint and steal IAM credentials. Additionally, software supply chain attacks now feature in the Top 10, reflecting the growing threat of compromised dependencies.
# ModSecurity Core Rule Set (CRS) — industry standard WAF rules
# Install CRS on Nginx with ModSecurity
git clone https://github.com/coreruleset/coreruleset.git /etc/modsecurity/crs
cp /etc/modsecurity/crs/crs-setup.conf.example /etc/modsecurity/crs/crs-setup.conf
# Enable in modsecurity.conf
cat >> /etc/nginx/modsecurity.conf << 'WAFCONF'
SecRuleEngine On
SecRequestBodyAccess On
SecResponseBodyAccess Off
SecAuditEngine RelevantOnly
SecAuditLog /var/log/modsecurity/audit.log
Include /etc/modsecurity/crs/crs-setup.conf
Include /etc/modsecurity/crs/rules/*.conf
WAFCONF
SQL Injection and XSS Protection Rules
SQL injection rules detect common patterns like single quotes followed by SQL keywords, UNION SELECT statements, and comment sequences (–). ModSecurity’s CRS includes hundreds of SQL injection signatures covering MySQL, PostgreSQL, MSSQL, and Oracle-specific syntax. However, false positives are common — legitimate content containing words like “SELECT” or apostrophes triggers rules.
Cross-site scripting (XSS) rules block script injection patterns: <script> tags, event handlers like onerror and onload, and JavaScript protocol URLs. Specifically, CRS rule 941100 detects XSS via libinjection — a library that understands HTML context and produces fewer false positives than regex-based detection. In contrast, simple regex rules flag legitimate HTML content like blog posts discussing JavaScript.
# Custom ModSecurity rules for common attack patterns
# Block SQL injection in query parameters
SecRule ARGS "@detectSQLi" \
"id:1001,\
phase:2,\
deny,\
status:403,\
log,\
msg:'SQL Injection detected in parameter',\
tag:'OWASP_CRS/WEB_ATTACK/SQL_INJECTION',\
severity:'CRITICAL'"
# Block XSS in request body
SecRule REQUEST_BODY "@detectXSS" \
"id:1002,\
phase:2,\
deny,\
status:403,\
log,\
msg:'XSS attack detected in request body',\
tag:'OWASP_CRS/WEB_ATTACK/XSS',\
severity:'HIGH'"
# Block path traversal attempts
SecRule REQUEST_URI "(?:\.\./){2,}" \
"id:1003,\
phase:1,\
deny,\
status:403,\
log,\
msg:'Path traversal attempt',\
severity:'CRITICAL'"
# Rate limit login attempts (brute force protection)
SecRule REQUEST_URI "@streq /api/auth/login" \
"id:1004,\
phase:1,\
pass,\
nolog,\
setvar:'ip.login_count=+1',\
expirevar:'ip.login_count=60'"
SecRule IP:LOGIN_COUNT "@gt 10" \
"id:1005,\
phase:1,\
deny,\
status:429,\
log,\
msg:'Login brute force: %{IP.login_count} attempts in 60s'"AWS WAF Configuration and Managed Rules
AWS WAF integrates with CloudFront, ALB, and API Gateway, providing a managed WAF without server infrastructure. AWS Managed Rules include rulesets for the OWASP Top 10, known bad inputs, SQL injection, and bot control. Furthermore, AWS updates these rules automatically as new attack patterns emerge.
Combine managed rules with custom rules for your application’s specific needs. For example, if your API accepts JSON payloads, add a rule that validates Content-Type headers and rejects requests with mismatched content types — a common technique for bypassing WAF rules that only inspect form-encoded data.
{
"Name": "CustomAPIProtection",
"Priority": 1,
"Statement": {
"RateBasedStatement": {
"Limit": 2000,
"AggregateKeyType": "IP",
"ScopeDownStatement": {
"ByteMatchStatement": {
"FieldToMatch": { "UriPath": {} },
"PositionalConstraint": "STARTS_WITH",
"SearchString": "/api/",
"TextTransformations": [
{ "Priority": 0, "Type": "LOWERCASE" }
]
}
}
}
},
"Action": { "Block": {} },
"VisibilityConfig": {
"SampledRequestsEnabled": true,
"CloudWatchMetricsEnabled": true,
"MetricName": "APIRateLimit"
}
}
Tuning Rules: Reducing False Positives
A WAF that blocks legitimate traffic is worse than no WAF at all. Deploy in detection mode first (ModSecurity’s SecRuleEngine DetectionOnly) and analyze logs for 1-2 weeks before enabling blocking. Identify which rules trigger on legitimate requests and create targeted exclusions for those specific URLs and parameters.
Common false positives include: form fields containing HTML (rich text editors), API endpoints receiving base64-encoded data that resembles SQL patterns, and search queries containing technical terms. Additionally, CMS platforms like WordPress trigger many rules because admin requests contain HTML, SQL-like queries, and file paths. Create per-URL rule exclusions rather than disabling rules globally.
# ModSecurity: targeted rule exclusions to reduce false positives
# Allow HTML in blog post editor (specific URL only)
SecRule REQUEST_URI "@beginsWith /wp-admin/post.php" \
"id:2001,\
phase:1,\
pass,\
nolog,\
ctl:ruleRemoveTargetById=941100-941999;ARGS:post_content"
# Allow base64 in API upload endpoint
SecRule REQUEST_URI "@beginsWith /api/v1/upload" \
"id:2002,\
phase:1,\
pass,\
nolog,\
ctl:ruleRemoveById=942100-942999"Monitoring and Incident Response
WAF logs are an intelligence goldmine. Analyze blocked requests to identify attack campaigns, compromised IPs, and the specific vulnerabilities attackers are targeting. Feed WAF data into your SIEM (Splunk, Elastic Security) for correlation with other security signals. As a result, you can detect sophisticated multi-stage attacks that combine WAF probing with other techniques.
Set up alerts for unusual patterns: a sudden spike in blocked SQL injection attempts from a single IP range, repeated requests to admin URLs from unexpected geographies, or a high rate of 403 responses. Consequently, your security team investigates proactively instead of discovering breaches months later.
Related Reading:
- API Security with OAuth and Zero Trust
- Container Security: Hardening Docker Images
- Supply Chain Security for CI/CD Pipelines
Resources:
In conclusion, a well-configured WAF blocks the majority of automated OWASP Top 10 attacks before they reach your application code. Start with ModSecurity CRS or AWS Managed Rules in detection mode, tune for false positives over 1-2 weeks, then enable blocking. Add custom rules for your application’s specific attack surface, and monitor WAF logs for intelligence on emerging threats. The WAF is one layer in defense-in-depth — combine it with input validation, parameterized queries, and Content Security Policy for comprehensive protection.