Skip to main content

ELBv2 Desync Mitigation Mode

Overview​

This check verifies that your Application Load Balancers (ALBs) have HTTP desync protection enabled. Desync mitigation prevents a class of attacks called "HTTP request smuggling" where attackers exploit differences in how the load balancer and your backend servers interpret HTTP requests.

The check passes if either:

  • routing.http.desync_mitigation_mode is set to strictest or defensive, OR
  • routing.http.drop_invalid_header_fields.enabled is set to true (as a compensating control)

Risk​

Without proper desync mitigation, attackers can exploit HTTP parsing inconsistencies to:

  • Steal data: Access tokens, session cookies, or sensitive information intended for other users
  • Poison caches: Inject malicious content that gets served to other users
  • Bypass security controls: Smuggle requests past your load balancer's security rules
  • Cause outages: Exhaust backend resources through crafted requests

Setting desync mitigation to "strictest" provides the strongest protection against these attacks.

Remediation Steps​

Prerequisites​

  • Access to the AWS Console with permissions to modify load balancer settings
  • Know which Application Load Balancer(s) need to be updated

AWS Console Method​

  1. Sign in to the AWS Console
  2. Navigate to EC2 > Load Balancers (in the left sidebar under "Load Balancing")
  3. Select the Application Load Balancer you want to update
  4. Click the Attributes tab
  5. Click Edit
  6. Find Desync mitigation mode and select Strictest
    • If "Strictest" causes compatibility issues with your application, try Defensive instead
  7. Click Save changes

Repeat for each ALB that failed the check.

AWS CLI (optional)

Set desync mitigation to strictest:

aws elbv2 modify-load-balancer-attributes \
    --region us-east-1 \
    --load-balancer-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/app/my-alb/50dc6c495c0c9188 \
    --attributes Key=routing.http.desync_mitigation_mode,Value=strictest

Replace:

  • arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/app/my-alb/50dc6c495c0c9188 with your ALB ARN

Alternative - Enable drop invalid headers (compensating control):

aws elbv2 modify-load-balancer-attributes \
    --region us-east-1 \
    --load-balancer-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/app/my-alb/50dc6c495c0c9188 \
    --attributes Key=routing.http.drop_invalid_header_fields.enabled,Value=true

List all ALBs to find ARNs:

aws elbv2 describe-load-balancers \
    --region us-east-1 \
    --query "LoadBalancers[?Type=='application'].[LoadBalancerArn,LoadBalancerName]" \
    --output table
CloudFormation (optional)

Add or update the LoadBalancerAttributes property in your ALB resource:

AWSTemplateFormatVersion: '2010-09-09'
Description: Application Load Balancer with desync mitigation enabled

Resources:
  ApplicationLoadBalancer:
    Type: AWS::ElasticLoadBalancingV2::LoadBalancer
    Properties:
      Name: my-secure-alb
      Type: application
      Scheme: internet-facing
      Subnets:
        - !Ref PublicSubnet1
        - !Ref PublicSubnet2
      SecurityGroups:
        - !Ref ALBSecurityGroup
      LoadBalancerAttributes:
        - Key: routing.http.desync_mitigation_mode
          Value: strictest
        - Key: routing.http.drop_invalid_header_fields.enabled
          Value: "true"

Outputs:
  LoadBalancerArn:
    Description: ARN of the Application Load Balancer
    Value: !Ref ApplicationLoadBalancer

Key attributes:

  • routing.http.desync_mitigation_mode: Set to strictest (recommended) or defensive
  • routing.http.drop_invalid_header_fields.enabled: Set to true as additional protection
Terraform (optional)

For a new ALB, include the desync_mitigation_mode attribute:

resource "aws_lb" "application" {
  name               = "my-secure-alb"
  internal           = false
  load_balancer_type = "application"
  security_groups    = [aws_security_group.alb.id]
  subnets            = var.public_subnet_ids

  desync_mitigation_mode = "strictest"
  drop_invalid_header_fields = true

  tags = {
    Environment = "production"
  }
}

For an existing ALB, add or update these attributes:

resource "aws_lb" "existing" {
  # ... existing configuration ...

  desync_mitigation_mode     = "strictest"
  drop_invalid_header_fields = true
}

Attribute reference:

  • desync_mitigation_mode: Valid values are monitor, defensive, or strictest (default is defensive)
  • drop_invalid_header_fields: Set to true to drop HTTP headers with invalid values

Verification​

After making changes, verify the fix:

  1. In the AWS Console, go to EC2 > Load Balancers
  2. Select your ALB and click the Attributes tab
  3. Confirm Desync mitigation mode shows Strictest (or Defensive)
CLI verification
aws elbv2 describe-load-balancer-attributes \
    --region us-east-1 \
    --load-balancer-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/app/my-alb/50dc6c495c0c9188 \
    --query "Attributes[?Key=='routing.http.desync_mitigation_mode' || Key=='routing.http.drop_invalid_header_fields.enabled']"

Expected output:

[
    {
        "Key": "routing.http.desync_mitigation_mode",
        "Value": "strictest"
    },
    {
        "Key": "routing.http.drop_invalid_header_fields.enabled",
        "Value": "true"
    }
]

Re-run the Prowler check to confirm remediation:

prowler aws --check elbv2_desync_mitigation_mode

Additional Resources​

Notes​

  • Strictest vs Defensive: The "strictest" mode provides maximum protection but may reject some legitimate requests that don't fully comply with HTTP standards. If you experience issues with legitimate traffic, try "defensive" mode first and monitor.
  • Testing recommended: Before enabling "strictest" mode in production, test with non-production traffic to ensure your application's HTTP requests are fully RFC-compliant.
  • Compensating control: Enabling drop_invalid_header_fields provides some protection but is not as comprehensive as "strictest" desync mitigation. Use both for defense-in-depth.
  • Network Load Balancers: This check applies only to Application Load Balancers (ALBs). Network Load Balancers (NLBs) operate at Layer 4 and don't have HTTP desync concerns.