AWS WAF for API Gateway

AWS WAF is a managed web application firewall service that monitors and controls HTTP(S) requests forwarded to your protected web application resources. When integrated with API Gateway, it sits between the client and your API, inspecting each request before it reaches your backend. The primary purposes are: (1) filtering out malicious requests such as SQL injection (SQLi) and cross-site scripting (XSS), (2) blocking requests from specific IP addresses or geographic regions, (3) rate limiting to prevent abuse and DDoS attacks, and (4) allowing or blocking requests based on custom conditions like header values or query string parameters.

On the DVA-C02 exam, you must understand that AWS WAF is a regional service (not global like CloudFront) and that it can be associated with API Gateway REST APIs, HTTP APIs, and WebSocket APIs (though WebSocket support is limited). The exam focuses on REST APIs and HTTP APIs. Remember: WAF cannot be directly associated with a private API Gateway endpoint (VPCE) – you must use a Network Load Balancer (NLB) in front of the VPC endpoint or use CloudFront.

When a client sends an HTTP request to an API Gateway endpoint that has an associated Web ACL (Access Control List), the request passes through the WAF before reaching API Gateway. The WAF evaluates the request against all rules in the Web ACL in the order they are defined. Each rule contains a statement that defines the inspection criteria and an action (Allow, Block, Count, or Challenge). The evaluation process is:

- Origin country (based on IP address) - IP address (in a set or range) - Presence of a label (from prior WAF rules) - Regex pattern in headers, query strings, body, URI path - Size constraints on request components - SQL injection or XSS patterns (via managed rule groups) - Rate of requests from a source IP (rate-based rule) 4. Action execution: If a rule matches, the configured action is taken. If no rule matches, the default action (allow or block) is applied. 5. Request forwarding or blocking: If allowed, the request proceeds to API Gateway, which then invokes the backend integration. If blocked, WAF returns a 403 Forbidden response immediately.

- Managed Rule Groups: Pre-configured rule sets maintained by AWS or AWS Marketplace sellers. Key groups for API Gateway include: - AWSManagedRulesCommonRuleSet: Protects against common threats like SQLi, XSS, LFI, RFI, etc. - AWSManagedRulesSQLiRuleSet: Specifically SQL injection. - AWSManagedRulesKnownBadInputsRuleSet: Blocks known bad patterns. - AWSManagedRulesAmazonIpReputationList: Blocks IPs with poor reputation. - AWSManagedRulesAnonymousIpList: Blocks requests from proxies, Tor nodes, etc. - AWSManagedRulesBotControlRuleSet: Blocks or rate-limits bots (additional cost).

Rate-based rules are essential for DDoS protection. Instead of inspecting individual request attributes, they track the number of requests from a source IP over a rolling 5-minute window. If the request count exceeds a threshold (e.g., 2000 requests per 5 minutes), the rule triggers an action (Block or Count) for that IP. The action lasts until the rate drops below the threshold. Rate-based rules have a default evaluation window of 5 minutes, and the maximum supported rate is 10,000 requests per 5 minutes for each IP (but can be higher with AWS support).

To associate WAF with API Gateway, you create a Web ACL and then associate it with an API Gateway stage using the AWS Console, CLI, or SDK. The API Gateway must be a REST API or HTTP API (not WebSocket for WAF association). The association is at the stage level, meaning you can have different WAF configurations for dev, test, and prod stages. For edge-optimized APIs, WAF operates at the CloudFront edge location, which provides global DDoS protection. For regional APIs, WAF operates at the regional endpoint.

# Create an IP set for allowed IPs
aws wafv2 create-ip-set --name AllowedIPs --scope REGIONAL --ip-address-version IPV4 --addresses '["203.0.113.0/24"]'

# Create a Web ACL with a rule to block requests not from allowed IPs
aws wafv2 create-web-acl --name MyWebACL --scope REGIONAL --default-action Allow={} --rules '
[
  {
    "Name": "BlockNonAllowedIPs",
    "Priority": 0,
    "Statement": {
      "NotStatement": {
        "Statement": {
          "IPSetReferenceStatement": {
            "ARN": "arn:aws:wafv2:us-east-1:123456789012:regional/ipset/AllowedIPs/abc123"
          }
        }
      }
    },
    "Action": {
      "Block": {}
    },
    "VisibilityConfig": {
      "SampledRequestsEnabled": true,
      "CloudWatchMetricsEnabled": true,
      "MetricName": "BlockNonAllowedIPs"
    }
  }
]' --visibility-config SampledRequestsEnabled=true,CloudWatchMetricsEnabled=true,MetricName=MyWebACL

# Associate Web ACL with API Gateway stage
aws wafv2 associate-web-acl --web-acl-arn arn:aws:wafv2:us-east-1:123456789012:regional/webacl/MyWebACL/abc123 --resource-arn arn:aws:apigateway:us-east-1::/restapis/abc123/stages/prod

WAF provides sampled requests (up to 100 requests per rule per 5 minutes), CloudWatch metrics (e.g., AllowedRequests, BlockedRequests, CountedRequests), and detailed logs (if enabled). Logs can be sent to S3, CloudWatch Logs, or Kinesis Firehose. Logs include request metadata, rule actions, and labels. This is critical for debugging false positives.

For DVA-C02, you must know:

Enterprise Scenario 1: E-commerce API Protection

A large e-commerce company exposes a REST API for product search and checkout. They face constant SQL injection and XSS attempts, as well as bots scraping product data. They deploy AWS WAF with API Gateway by creating a Web ACL with the AWSManagedRulesCommonRuleSet (covers SQLi, XSS, LFI, RFI) and the AWSManagedRulesAmazonIpReputationList. They also add a custom rate-based rule limiting each IP to 500 requests per 5 minutes to prevent scraping. The Web ACL is associated with the prod stage of the API. They enable logging to S3 for compliance and analysis. Initially, they set managed rules to Count to identify false positives. After a week, they switch to Block. They also use IP sets to allow their internal monitoring tools. The result: attack attempts drop by 95%, and false positives are minimal.

Enterprise Scenario 2: Financial Services Geo-Blocking

A fintech company provides a REST API for account management. Regulatory requirements mandate that only users from certain countries can access the API. They use AWS WAF with a geographic match rule to allow traffic only from the US and Canada. They create an IP set for their corporate VPN ranges and allow those. They also use the AWSManagedRulesKnownBadInputsRuleSet to block common attack patterns. The Web ACL is associated with the API Gateway stage. They use CloudWatch metrics to monitor blocked requests from other countries. When a legitimate user from a blocked country contacts support, they can add their IP to an allow list via an IP set update. This geo-blocking is lightweight and avoids code changes.

Scenario 3: Startup with DDoS Mitigation

A startup launches a new mobile app backed by an HTTP API on API Gateway. During launch, they experience a layer 7 DDoS attack. They quickly create a rate-based rule limiting each IP to 100 requests per 5 minutes and block traffic from known bad IPs using the AmazonIpReputationList managed rule group. They also enable AWS Shield Advanced for additional DDoS protection (costly but necessary). The Web ACL is associated with the API Gateway stage. They monitor the attack in real-time via CloudWatch and adjust the rate limit as needed. Post-attack, they add custom rules to block specific user agents and headers used by the attackers.

Common misconfiguration: Not setting a default action correctly. If the default action is Allow, a rule with Block action must be explicitly created to block traffic. If no rule matches, the request is allowed. Many beginners forget to set a default action of Block for deny-by-default security. Also, forgetting to enable logging makes troubleshooting false positives difficult.