AWS Security Hub · WAF
WAF.11: WAFv2 web ACL logging should be enabled
Written and reviewed by Emnode · Last reviewed
What does AWS Security Hub WAF.11 check?
WAF.11 is a periodic check that a WAFv2 web ACL (`AWS::WAFv2::WebACL`) has a logging configuration attached. It reports FAILED when no `LoggingConfiguration` exists; there is no separate enable flag, so the mere presence of the configuration is what makes the control pass.
Why does WAF.11 matter?
By default a web ACL evaluates millions of requests silently, with no record of which came in, which rule matched, or what action was taken. The firewall still functions, which is why it's rated Low, but without logs you're flying blind during an incident and have no data to tune false positives. It's a visibility gap, not a protection gap, and it maps to the usual audit-logging expectations.
How do I fix WAF.11?
- Find the web ACLs with no logging configuration.
- Prepare a correctly-named destination: a Data Firehose stream (`aws-waf-logs-` prefix), a CloudWatch Logs group, or an S3 bucket.
- Attach the logging configuration with `PutLoggingConfiguration`, adding sensible `RedactedFields` and an optional `LoggingFilter`.
- Make logging part of the deployment baseline so new web ACLs ship with it.
Remediation script · bash
# Load balancer: enable access logs to a dedicated, log-delivery-permissioned bucket.
aws elbv2 modify-load-balancer-attributes \
--load-balancer-arn "$LB_ARN" \
--attributes \
Key=access_logs.s3.enabled,Value=true \
Key=access_logs.s3.bucket,Value=acme-elb-logs-eu-west-1 \
Key=access_logs.s3.prefix,Value=prod-api
# WAF web ACL: attach logging (Firehose/log-group name must start with aws-waf-logs-),
# redact credentials, and keep only blocked requests to cap volume.
aws wafv2 put-logging-configuration --logging-configuration \
ResourceArn="$WEBACL_ARN",LogDestinationConfigs="arn:aws:firehose:us-east-1:111122223333:deliverystream/aws-waf-logs-prod",RedactedFields=[{SingleHeader={Name=authorization}}]
# Network Firewall: enable ALERT logs to CloudWatch and FLOW logs to S3.
aws network-firewall update-logging-configuration --firewall-name prod-egress-fw \
--logging-configuration 'LogDestinationConfigs=[{LogType=ALERT,LogDestinationType=CloudWatchLogs,LogDestination={logGroup=/netfw/prod-egress-fw/alert}}]'
# Route 53: log group MUST be in us-east-1, then attach the query logging config.
aws logs create-log-group --log-group-name /aws/route53/customer-portal --region us-east-1
aws route53 create-query-logging-config --hosted-zone-id Z0J1K4M2X8N9A1 \
--cloud-watch-logs-log-group-arn arn:aws:logs:us-east-1:123456789012:log-group:/aws/route53/customer-portalFull walkthrough (console steps, edge cases and verification) in the lesson Enable network and edge logging (LB, WAF, firewall, DNS).
Is WAF.11 a false positive?
The most common false positive is a web ACL whose traffic is centralised through Amazon Security Lake rather than a per-web-ACL `LoggingConfiguration`. AWS explicitly notes that WAF.11 does not check for Security Lake logging (Security Lake pulls WAF logs through an independent, duplicate stream that needs no `PutLoggingConfiguration` call), so a web ACL fully captured in Security Lake still reports FAILED. If Security Lake is your system of record for WAF logs, this is the intended state: suppress the finding (or set a Security Hub automation rule to NOT_AFFECTED) with a note pointing to the Security Lake WAF subscription, rather than attaching a redundant second logging destination.
More WAF controls
- WAF.1 WAF Classic global web ACL logging
- WAF.2 WAF Classic regional rules should have a condition
- WAF.3 WAF Classic regional rule groups should have a rule
- WAF.4 WAF Classic regional web ACLs should have a rule
- WAF.6 WAF Classic global rules should have a condition
- WAF.7 WAF Classic global rule groups should have a rule
- WAF.8 WAF Classic global web ACLs should have a rule
- WAF.10 WAFv2 web ACLs should have a rule or rule group