This skill covers deploying and tuning Web Application Firewall rules on AWS WAF, Azure WAF, and Cloudflare to protect cloud-hosted applications against OWASP Top 10 attacks. It details configuring managed rule sets, creating custom rules for business logic protection, implementing rate limiting, deploying bot management, and reducing false positives through rule tuning and logging analysis.
This skill covers deploying and tuning Web Application Firewall rules on AWS WAF, Azure WAF, and Cloudflare to protect cloud-hosted applications against OWASP Top 10 attacks. It details configuring managed rule sets, creating custom rules for business logic protection, implementing rate limiting, deploying bot management, and reducing false positives through rule tuning and logging analysis.
When deploying new web applications or APIs behind cloud load balancers requiring OWASP protection
When application penetration testing reveals SQL injection, XSS, or other injection vulnerabilities
When experiencing brute force, credential stuffing, or bot attacks against authentication endpoints
When compliance requirements mandate a WAF for PCI-DSS or similar standards
When tuning WAF rules to reduce false positives blocking legitimate application traffic
Do not use for network-level DDoS protection (use AWS Shield or Azure DDoS Protection), for API authentication design (see managing-cloud-identity-with-okta), or for application code-level security fixes (WAF is a compensating control, not a replacement for secure code).
Common Misconfigurations & Verification
Managed rules stuck in Count: an OverrideAction of {"Count": {}} evaluates but never blocks — the WAF is purely observational. After validation, switch each managed group to {"None": {}} (uses the group's Block action) and confirm with get-web-acl.
Web ACL never associated with the resource: the ACL can exist and look configured while no traffic flows through it. Verify aws wafv2 list-resources-for-web-acl --web-acl-arn <arn> --resource-type APPLICATION_LOAD_BALANCER returns the ALB/CloudFront/API Gateway ARN.
Default action Allow with no terminating block rule: requests fall through and are allowed. Confirm at least the managed groups run in Block.
Rate-based limit too high or wrong scope-down: a limit of 2000/5min or a scope-down matching the wrong URI lets credential stuffing through; AWS rate rules also have a 5-minute minimum window.
Logging disabled: without put-logging-configuration to S3/Firehose you cannot identify false positives or confirm blocks. Redact authorization/cookie fields.
AWS ALB/CloudFront, Azure Application Gateway, or Cloudflare configured as the application entry point
Application traffic logs for baseline analysis before WAF deployment
Test environment for validating WAF rules before production enforcement
Understanding of application request patterns to minimize false positives
Workflow
Step 1: Deploy Managed Rule Sets
Enable cloud provider managed rule sets that cover OWASP Top 10 vulnerabilities. Start in Count (detection) mode before switching to Block (prevention) mode.
After 7-14 days of Count mode with acceptable false positive rates, switch managed rules to Block mode for active protection.
# Change OverrideAction from Count to None (use rule group's default Block action)# Update each managed rule group from {"Count": {}} to {"None": {}}# Monitor CloudWatch metrics for sudden changes in blocked request volume
Key Concepts
Term
Definition
Web ACL
Web Access Control List defining the set of rules evaluated against every HTTP request to a protected resource
Managed Rule Group
Pre-configured rule set maintained by the cloud provider or third-party vendor covering common attack patterns
Rate-Based Rule
WAF rule that tracks request rates per IP address and blocks IPs exceeding the threshold within a time window
Count Mode
WAF action that logs matching requests without blocking them, used for rule validation before enforcement
Rule Priority
Numerical ordering determining which rules are evaluated first; lower numbers have higher priority
Custom Response
WAF capability to return specific HTTP status codes and headers when blocking requests
Scope-Down Statement
Condition that narrows a rate-based rule to specific URI paths, methods, or headers
False Positive
Legitimate request incorrectly blocked by a WAF rule, requiring rule tuning or exclusion
Tools & Systems
AWS WAF: Cloud-native WAF integrated with ALB, CloudFront, API Gateway, and AppSync
Azure WAF: Web application firewall on Application Gateway or Front Door with OWASP CRS rule sets
AWS Firewall Manager: Centralized WAF policy management across multiple AWS accounts in an Organization
WAF Security Automations: AWS solution that deploys Lambda-based automated WAF rule updates based on log analysis
CloudWatch Metrics: Monitoring dashboard for tracking WAF rule match rates, block counts, and allowed requests
Common Scenarios
Scenario: Credential Stuffing Attack Against Authentication API
Context: An e-commerce application experiences 50,000 login attempts per hour from a botnet using stolen credential lists. The attacker rotates source IPs every few minutes to evade simple IP-based blocking.
Approach:
Deploy rate-based rules limiting login endpoint requests to 10 per 5 minutes per IP
Enable AWS WAF Bot Control managed rule group to detect automated request patterns beyond IP rotation
Add a custom rule requiring valid CAPTCHA tokens for login requests exceeding 5 failures
Implement IP reputation blocking using AWSManagedRulesAmazonIpReputationList
Create a custom rule matching on User-Agent patterns common to credential stuffing tools
Monitor blocked request metrics and adjust thresholds based on legitimate traffic patterns
Pitfalls: Setting rate limits too aggressively blocks legitimate users behind shared NAT IPs. Blocking by User-Agent alone is easily bypassed by rotating agent strings.
