Skip to main content
emnode / learn
Compliance Medium severity

AWS Security Hub · ELB

ELB.12: ALB desync mitigation mode

Written and reviewed by Emnode · Last reviewed

What does AWS Security Hub ELB.12 check?

ELB.12 fails when an Application Load Balancer is configured with desync mitigation mode set to monitor. The control wants the mode to be defensive or strictest so the ALB actively handles ambiguous requests.

Why does ELB.12 matter?

HTTP desync (request smuggling) happens when the load balancer and back-end target interpret a malformed request differently, letting an attacker hide a second request inside the first to poison caches, bypass front-end auth or hijack sessions. Monitor mode only logs these requests; defensive mode neutralises them while remaining broadly compatible, which is why AWS makes it the default and the right answer for almost everyone.

How do I fix ELB.12?

  1. Check routing.http.desync_mitigation_mode on each ALB with describe-load-balancer-attributes.
  2. Set it to defensive with modify-load-balancer-attributes for safe, broadly compatible protection.
  3. Use strictest only where you can tolerate dropping technically non-compliant legacy clients.
  4. Pair with ELB.4 (drop invalid headers) and default defensive in your IaC.

Remediation script · bash

# Harden every Application Load Balancer in the region: reject invalid headers and
# require defensive (or strictest) desync mode. Both are instant, non-disruptive flips.
for arn in $(aws elbv2 describe-load-balancers \
    --query 'LoadBalancers[?Type==`application`].LoadBalancerArn' --output text); do
  aws elbv2 modify-load-balancer-attributes --load-balancer-arn "$arn" \
    --attributes \
      Key=routing.http.drop_invalid_header_fields.enabled,Value=true \
      Key=routing.http.desync_mitigation_mode,Value=defensive
  echo "$arn: hardened"
done

# Switch load-balanced Auto Scaling groups to ELB health checks with a safe grace period
# (confirm the target-group probe reflects real app health first).
for g in $(aws autoscaling describe-auto-scaling-groups \
    --query 'AutoScalingGroups[?(LoadBalancerNames!=`[]` || TargetGroupARNs!=`[]`) && HealthCheckType==`EC2`].AutoScalingGroupName' \
    --output text); do
  aws autoscaling update-auto-scaling-group --auto-scaling-group-name "$g" \
    --health-check-type ELB --health-check-grace-period 300
  echo "$g: now using ELB health checks"
done

Full walkthrough (console steps, edge cases and verification) in the lesson Harden load balancers (ALB/NLB/CLB).

Full lesson Harden load balancers (ALB/NLB/CLB) Step-by-step remediation with CLI, code and persona-specific context.
AWS documentation for ELB controls ↗ Check your own account for ELB.12 →
Part of the learning path Build in resilience

More ELB controls

  • ELB.1 ALB serves HTTP without redirecting to HTTPS
  • ELB.2 CLB SSL/HTTPS listeners should use ACM certs
  • ELB.3 CLB listeners should use HTTPS/TLS termination
  • ELB.4 ALB accepts malformed HTTP headers
  • ELB.5 Load balancers are not writing access logs
  • ELB.6 Load balancers can be deleted by accident
  • ELB.7 CLBs should have connection draining
  • ELB.8 CLB SSL listeners should use strong policy
  • ELB.9 CLBs should have cross-zone balancing
  • ELB.10 CLBs should span multiple AZs
  • ELB.13 A single-AZ load balancer is a data-plane single point of failure
  • ELB.14 CLB desync mitigation mode