How AWS WAF Inspects Requests

AWS WAF (Web Application Firewall) inspects HTTP and HTTPS requests at the application layer (Layer 7), unlike security groups and NACLs that work at Layers 3 and 4. It can read URLs, headers, query strings, and bodies to block attacks that look like normal network traffic but carry malicious payloads.

WAF targets common web threats such as SQL injection, cross-site scripting (XSS), bad bots, and application-layer floods. These attacks ride on legitimate ports 80 and 443, so lower-layer firewalls cannot distinguish them. WAF examines request content to tell good from bad.

WAF can inspect many parts of a request: the URI path, query string, HTTP headers, cookies, HTTP method, and body. You choose which component each rule examines. For example, a rule might scan the query string for SQL keywords or check a header for a known attack signature.

Rules use match statements like string match, regex match, size constraint, IP set, and geo match. You can also apply text transformations such as URL-decoding or lowercasing before matching, which defeats attackers who obfuscate payloads with encoding tricks.

When a rule matches, WAF takes an action: allow, block, count, CAPTCHA, or challenge. Count mode logs matches without blocking, letting you test a rule safely before enforcing it. CAPTCHA and challenge actions verify the client is a real browser, deterring bots.

WAF evaluates requests inline and synchronously before they reach your application, adding minimal latency. Blocked requests never touch your backend, which both protects the app and reduces load. This positions WAF as a gatekeeper at the edge of your stack.

WAF inspects the request body up to a default size limit (8 KB for many integrations, larger for newer ones). Content beyond the limit can be allowed through or blocked depending on your configuration. Attackers may try to hide payloads past the inspection limit, so this is worth tuning.

WAF can send detailed logs of inspected requests to CloudWatch Logs, an S3 bucket, or Kinesis Data Firehose. Logs show which rule matched and the action taken, which is essential for tuning rules, investigating attacks, and proving compliance during an audit.

Every WAF policy has a default action applied to requests that match no rule: allow or block. Most public web apps use a default of allow and block specific bad patterns. Locked-down APIs may default to block and allow only known-good requests.

WAF filters application-layer content, while AWS Shield defends against volumetric DDoS floods at Layers 3 and 4. They are complementary: Shield absorbs the flood, WAF inspects the requests that get through. The exam often asks which tool addresses which kind of attack.

WAF does not sit inline by itself; it attaches to a supported resource such as CloudFront, an Application Load Balancer, API Gateway, or AppSync. The resource forwards requests to WAF for inspection. Choosing the right attachment point is covered later in this course.

Test your understanding of WAF inspection.

AWS WAF inspects HTTP/HTTPS requests at Layer 7, reading URIs, headers, query strings, and bodies to stop SQL injection, XSS, and bad bots. Rules use match statements with text transformations and take actions of allow, block, count, CAPTCHA, or challenge. Inspection is inline with logging to CloudWatch, S3, or Firehose. WAF complements Shield and attaches to CloudFront, ALB, API Gateway, or AppSync.