Application Load Balancer mitigates desync attacks

Check ID: elbv2_desync_mitigation_mode
Provider: AWS
Service: elbv2
Severity: MEDIUM
Resource type: AwsElbv2LoadBalancer

What this check verifies

Application Load Balancer settings are reviewed for HTTP desync protections. It evaluates routing.http.desync_mitigation_mode for strictest or defensive; when neither is configured, it checks routing.http.drop_invalid_header_fields.enabled is true as a compensating control.

Risk

Lacking robust desync mitigation enables inconsistent HTTP parsing and request smuggling:

Confidentiality: token theft, data exfiltration
Integrity: cache/queue poisoning, unauthorized actions
Availability: backend exhaustion and outages

Only dropping invalid headers reduces but does not eliminate this exposure.

Recommendation

Set ALBs to desync_mitigation_mode=strictest (or defensive if compatibility is required) and keep routing.http.drop_invalid_header_fields.enabled=true. Apply defense in depth: validate RFC-compliant requests, roll out changes gradually with monitoring, and enforce least privilege on downstream services.

Remediation

CLI
Terraform
Native IaC
Dashboard steps

aws elbv2 modify-load-balancer-attributes --load-balancer-arn <ALB_ARN> --attributes Key=routing.http.desync_mitigation_mode,Value=strictest

# Terraform: Set ALB desync mitigation mode
resource "aws_lb" "<example_resource_name>" {
  name    = "<example_resource_name>"
  subnets = ["<example_subnet_id1>", "<example_subnet_id2>"]

  desync_mitigation_mode = "strictest" # Critical: enforce strictest/defensive desync mitigation to pass the check
}

# CloudFormation: Set ALB desync mitigation mode
Resources:
  <example_resource_name>:
    Type: AWS::ElasticLoadBalancingV2::LoadBalancer
    Properties:
      Type: application
      Subnets:
        - <example_subnet_id1>
        - <example_subnet_id2>
      LoadBalancerAttributes:
        - Key: routing.http.desync_mitigation_mode  # Critical: enforce strictest/defensive desync mitigation to pass the check
          Value: strictest

References

Where this check fires

This check runs on every scheduled scan against your AWS account. Findings appear at Cloud Security → Findings filterable by Check ID = elbv2_desync_mitigation_mode. To re-evaluate after a fix, hit Run now on the account’s schedule under Cloud Security → Schedules — the next scan re-checks this control and marks the finding fixed or keeps it persistent.

← Back to AWS checks

ELBv2 load balancer has deletion protection enabled ELBv2 HTTPS listeners use a secure SSL policy

​What this check verifies

​Risk

​Recommendation

​Remediation

​References

​Where this check fires

What this check verifies

Risk

Recommendation

Remediation

References

Where this check fires