Skip to main content

WAF controls (8)

CTL.WAF.EVASION.OBSERVE.001​

WAF Must Have Full Body Inspection and Request Sampling Enabled

  • Severity: high
  • Type: unsafe_state
  • Domain: exposure
  • Compliance: fedramp_moderate: SI-4; hipaa: 164.312(b); nist_800_53_r5: SI-4; pci_dss_v4.0: 10.2.1; soc2: CC7.1;

WAF Web ACLs must have full request body inspection enabled and sampled allowed-request logging active. Signature-based WAF rules can be evaded through encoding techniques such as CRLF injection, Unicode surrogate pairs, and HTML parser confusion. HackerOne report #2921905 documents a WAF bypass using CRLF and HTML attribute confusion that evaded Cloudflare rule matching entirely. Prevention of encoding evasion is a vendor responsibility, but the organization must ensure that when evasion occurs it is observable. Without full body inspection, payloads in POST bodies, JSON fields, and multipart uploads are invisible to all WAF rules. Without sampled allowed-request logging, successful bypass attempts leave no forensic trace — the organization cannot distinguish between no attacks and undetected attacks. This control differs from CTL.WAF.LOGGING.001 (which checks logging is enabled) by verifying the logging and inspection configuration captures enough detail to detect evasion patterns. This control is the evasion observability check in the seven-control WAF safety envelope: presence (CTL.WAF.RULES.001), enforcement (CTL.WAF.RULES.BLOCKMODE.001), coverage (CTL.WAF.RULES.OWASP.001), visibility (CTL.WAF.LOGGING.001), architectural prerequisite (CTL.WAF.ORIGIN.LOCKDOWN.001), parser overflow protection (CTL.WAF.PARSERLIMIT.PROTECT.001), and evasion observability (CTL.WAF.EVASION.OBSERVE.001). All seven may fire on the same Web ACL simultaneously; each addresses a distinct failure mode.

Remediation: Enable full request body inspection on the Web ACL and increase the body size inspection limit beyond the default 8KB to cover modern API payloads. Enable sampled request logging for allowed requests — not only blocked requests. For AWS WAF, configure the Web ACL body inspection to inspect the full body and enable request sampling via the AWS WAF console or UpdateWebACL API. Reference: HackerOne report #2921905 documents a WAF bypass via CRLF injection that would be detectable with full body inspection and request sampling.

CTL.WAF.INCOMPLETE.001​

Complete Data Required for WAF Assessment

  • Severity: low
  • Type: unsafe_state
  • Domain: exposure

WAF assessment data is incomplete. The extractor must populate waf.rules.has_managed_rules to evaluate protection controls.

Remediation: Re-run the extractor with WAF permissions: wafv2:GetWebACL, wafv2:ListWebACLs, wafv2:GetLoggingConfiguration.

CTL.WAF.LOGGING.001​

WAF Logging Must Be Enabled

  • Severity: medium
  • Type: unsafe_state
  • Domain: exposure
  • Compliance: fedramp_moderate: AU-2; nist_800_53_r5: AU-2; soc2: CC7.1;

WAF web ACLs must have logging enabled to record blocked and allowed requests. Without logging, attacks cannot be detected, investigated, or correlated with other security events. This control is the visibility check in the seven-control WAF safety envelope: presence (CTL.WAF.RULES.001), enforcement (CTL.WAF.RULES.BLOCKMODE.001), coverage (CTL.WAF.RULES.OWASP.001), visibility (CTL.WAF.LOGGING.001), architectural prerequisite (CTL.WAF.ORIGIN.LOCKDOWN.001), parser overflow protection (CTL.WAF.PARSERLIMIT.PROTECT.001), and evasion observability (CTL.WAF.EVASION.OBSERVE.001). All seven may fire on the same Web ACL simultaneously; each addresses a distinct failure mode.

Remediation: Enable WAF logging to S3, CloudWatch Logs, or Kinesis Data Firehose via aws wafv2 put-logging-configuration.

CTL.WAF.ORIGIN.LOCKDOWN.001​

WAF Origin Must Not Accept Direct Internet Traffic

  • Severity: critical
  • Type: unsafe_state
  • Domain: exposure
  • Compliance: fedramp_moderate: SC-7; hipaa: 164.312(e)(1); nist_800_53_r5: SC-7; pci_dss_v4.0: 1.3.1; soc2: CC6.6;

When a WAF Web ACL is associated with an origin server (ALB, API Gateway, EC2 instance), the origin's network ingress controls must not permit inbound connections on application ports from the public internet. A WAF that sits in front of an origin provides zero protection if the origin also accepts direct connections from 0.0.0.0/0 or ::/0 — an attacker who discovers the origin IP address through Censys, Shodan, certificate transparency logs, historical DNS records, or timing analysis can send traffic directly to the origin, bypassing every WAF rule, DDoS protection, and rate limit. This is the architectural prerequisite for all other WAF controls — without origin lockdown, the entire WAF safety envelope is irrelevant regardless of how well the WAF rules are configured. HackerOne report (Linode) documents this exact pattern: an origin behind Cloudflare was discoverable via Censys, allowing direct unfiltered payload delivery and denial-of-service against the unprotected origin. This control is the architectural prerequisite in the seven-control WAF safety envelope: presence (CTL.WAF.RULES.001), enforcement (CTL.WAF.RULES.BLOCKMODE.001), coverage (CTL.WAF.RULES.OWASP.001), visibility (CTL.WAF.LOGGING.001), architectural prerequisite (CTL.WAF.ORIGIN.LOCKDOWN.001), parser overflow protection (CTL.WAF.PARSERLIMIT.PROTECT.001), and evasion observability (CTL.WAF.EVASION.OBSERVE.001). All seven may fire on the same Web ACL simultaneously; each addresses a distinct failure mode.

Remediation: Restrict the origin's security group inbound rules on application ports (80, 443, custom) to allow traffic only from WAF or CDN provider IP ranges. For CloudFront, use the AWS-managed prefix list com.amazonaws.global.cloudfront.origin-facing in the security group rule. For regional ALBs behind AWS WAF, restrict to the WAF endpoint subnet CIDRs. Remove all 0.0.0.0/0 and ::/0 ingress rules on application ports.

CTL.WAF.PARSERLIMIT.PROTECT.001​

WAF Must Block Requests That Exceed Parser Limits

  • Severity: critical
  • Type: unsafe_state
  • Domain: exposure
  • Compliance: fedramp_moderate: SI-10; hipaa: 164.312(e)(1); nist_800_53_r5: SI-10; pci_dss_v4.0: 6.4.1; soc2: CC6.6;

WAF Web ACLs must contain a highest-priority rule that detects when the WAF's internal parser limits have been exceeded and blocks the request. Every WAF has parser limits — maximum header count, maximum header size, maximum body size, maximum cookie count. When a request exceeds these limits, rule evaluation silently stops at the truncation point. Rules configured to inspect content beyond the limit never fire. The request passes through as if clean. A Cloudflare HackerOne report (High severity, $1,250 bounty, 2025-11-18) documented this: 94+ HTTP headers caused all WAF rules, cache key evaluation, and cache rules to bypass simultaneously. Cloudflare's mitigation: a rule checking http.request.headers.truncated at highest priority in BLOCK mode. This vulnerability class applies to every WAF vendor — the invariant is vendor-neutral. The parser limit protection rule must execute before all other rules. A rule at lower priority allows other rules to evaluate truncated content before the overflow is detected, creating a race condition attackers can exploit. This control is the prerequisite for all other WAF rule controls — if the parser can be overflowed, managed rules, OWASP coverage, and custom rules are irrelevant for any request designed to exceed the limit. This control is the parser overflow protection check in the seven-control WAF safety envelope: presence (CTL.WAF.RULES.001), enforcement (CTL.WAF.RULES.BLOCKMODE.001), coverage (CTL.WAF.RULES.OWASP.001), visibility (CTL.WAF.LOGGING.001), architectural prerequisite (CTL.WAF.ORIGIN.LOCKDOWN.001), parser overflow protection (CTL.WAF.PARSERLIMIT.PROTECT.001), and evasion observability (CTL.WAF.EVASION.OBSERVE.001). All seven may fire on the same Web ACL simultaneously; each addresses a distinct failure mode.

Remediation: Add a rule at the highest priority position (priority 0 or the lowest numeric value) that detects parser overflow and blocks the request. For Cloudflare, check http.request.headers.truncated == true. For AWS WAF, use a size constraint rule checking header count or total header size against the documented parser limit. The rule must be in BLOCK mode — COUNT mode detects but does not prevent the bypass. Verify the rule has higher priority than all managed rule groups and custom rules in the Web ACL.

CTL.WAF.RULES.001​

WAF Must Have Managed Rule Groups Enabled

  • Severity: high
  • Type: unsafe_state
  • Domain: exposure
  • Compliance: fedramp_moderate: SI-3; nist_800_53_r5: SI-3; pci_dss_v4.0: 6.4.1; soc2: CC6.6;

WAF web ACLs must include AWS managed rule groups for common attack patterns (SQLi, XSS, known bad inputs). Without managed rules, the WAF provides no baseline protection against OWASP Top 10 attacks. This control is the presence check in the seven-control WAF safety envelope: presence (CTL.WAF.RULES.001), enforcement (CTL.WAF.RULES.BLOCKMODE.001), coverage (CTL.WAF.RULES.OWASP.001), visibility (CTL.WAF.LOGGING.001), architectural prerequisite (CTL.WAF.ORIGIN.LOCKDOWN.001), parser overflow protection (CTL.WAF.PARSERLIMIT.PROTECT.001), and evasion observability (CTL.WAF.EVASION.OBSERVE.001). All seven may fire on the same Web ACL simultaneously; each addresses a distinct failure mode.

Remediation: Add AWS managed rule groups to the web ACL: AWSManagedRulesCommonRuleSet, AWSManagedRulesSQLiRuleSet, AWSManagedRulesKnownBadInputsRuleSet.

CTL.WAF.RULES.BLOCKMODE.001​

WAF Rules Must Be in BLOCK Mode, Not COUNT Mode

  • Severity: critical
  • Type: unsafe_state
  • Domain: exposure
  • Compliance: fedramp_moderate: SI-3; nist_800_53_r5: SI-3; pci_dss_v4.0: 6.4.1; soc2: CC6.6;

All WAF rules and rule groups must have their effective action set to BLOCK. A rule in COUNT mode observes and logs attacks but does not block them. AWS WAF defaults newly added rules to COUNT mode during tuning. This becomes a permanent misconfiguration when teams never transition to BLOCK. The WAF appears active in every compliance report while blocking nothing. COUNT mode may be intentional during tuning — the stave/waf-count-mode-justified tag documents this exception. This control is the enforcement check in the seven-control WAF safety envelope: presence (CTL.WAF.RULES.001), enforcement (CTL.WAF.RULES.BLOCKMODE.001), coverage (CTL.WAF.RULES.OWASP.001), visibility (CTL.WAF.LOGGING.001), architectural prerequisite (CTL.WAF.ORIGIN.LOCKDOWN.001), parser overflow protection (CTL.WAF.PARSERLIMIT.PROTECT.001), and evasion observability (CTL.WAF.EVASION.OBSERVE.001). All seven may fire on the same Web ACL simultaneously; each addresses a distinct failure mode.

Remediation: Transition COUNT-mode rules to BLOCK mode. If COUNT mode is intentional during tuning, add a stave/waf-count-mode-justified tag to the WebACL with the justification (e.g., ticket number).

CTL.WAF.RULES.OWASP.001​

WAF Must Have OWASP Core Rule Coverage

  • Severity: high
  • Type: unsafe_state
  • Domain: exposure
  • Compliance: fedramp_moderate: SI-3; nist_800_53_r5: SI-3; owasp_top10_2021: A03; pci_dss_v4.0: 6.4.1; soc2: CC6.6;

WAF web ACLs must include the three core AWS managed rule groups that cover OWASP Top 10 attack categories: AWSManagedRulesCommonRuleSet (XSS, path traversal, HTTP violations), AWSManagedRulesSQLiRuleSet (SQL injection), and AWSManagedRulesKnownBadInputsRuleSet (Log4Shell, deserialization, known CVE payloads). All three groups must be attached and enforcing in BLOCK mode. A WAF with custom rules only, or with managed rule groups that cover IP reputation or bot management but not OWASP attack categories, provides incomplete coverage. This control differs from CTL.WAF.RULES.001 (which checks for any managed rules) by requiring the specific groups needed for baseline OWASP coverage. HackerOne report #382625 documents a stored XSS bypass against a production WAF that was active and blocking with custom rules but lacked AWSManagedRulesCommonRuleSet — the payload used a marquee element with an inline event handler, a known vector covered by the CrossSiteScripting_BODY rule in the common rule set. This control is the coverage check in the seven-control WAF safety envelope: presence (CTL.WAF.RULES.001), enforcement (CTL.WAF.RULES.BLOCKMODE.001), coverage (CTL.WAF.RULES.OWASP.001), visibility (CTL.WAF.LOGGING.001), architectural prerequisite (CTL.WAF.ORIGIN.LOCKDOWN.001), parser overflow protection (CTL.WAF.PARSERLIMIT.PROTECT.001), and evasion observability (CTL.WAF.EVASION.OBSERVE.001). All seven may fire on the same Web ACL simultaneously; each addresses a distinct failure mode.

Remediation: Add the following AWS managed rule groups to the web ACL and ensure each is in BLOCK mode with no COUNT override at the group level or rule action override level: (1) AWSManagedRulesCommonRuleSet — covers XSS, path traversal, common exploits, (2) AWSManagedRulesSQLiRuleSet — covers SQL injection attack patterns, (3) AWSManagedRulesKnownBad InputsRuleSet — covers known CVE exploits including Log4j and Spring4Shell.