Skip to main content

🛡️ AWS ELB Load Balancer is not configured with defensive or strictest desync mitigation mode🟢

  • Contextual name: 🛡️ Load Balancer is not configured with defensive or strictest desync mitigation mode🟢
  • ID: /ce/ca/aws/elb/load-balancer-desync-mitigation-mode
  • Tags:
  • Policy Type: COMPLIANCE_POLICY
  • Policy Categories: RELIABILITY, PERFORMANCE

Logic​

Similar Policies​

Description​

Open File

Description​

This policy identifies AWS ELB Classic and Application Load Balancers that are not configured with an HTTP desync mitigation mode of defensive (default) or strictest.

Note: The routing.http.drop_invalid_header_fields.enabled attribute (AWS ELB Application Load Balancer is not configured to drop invalid HTTP headers) was introduced to provide baseline protection against HTTP desync by dropping malformed HTTP headers. The routing.http.desync_mitigation_mode attribute was later added to offer more comprehensive and configurable protection against HTTP desync attacks. You are not required to enable both attributes; instead, you should select the option that best aligns with your application’s security and compatibility requirements.

Rationale​

HTTP desync occurs when a load balancer and its backend targets interpret HTTP request boundaries differently. This condition can be exploited through HTTP Request Smuggling attacks, enabling an attacker to:

... see more

Remediation​

Open File

Remediation​

Configure HTTP Desync Mitigation Mode​

Update the HTTP desync mitigation mode to defensive or strictest to prevent malformed or ambiguous HTTP requests from reaching backend targets. This helps protect applications from HTTP Request Smuggling–related attacks.

Recommendation: For most environments, the default defensive mode provides strong protection while maintaining application availability. Choose strictest for maximum security, but validate that your application can function with RFC-strict traffic, as it blocks all "Acceptable" and "Ambiguous" requests

From Command Line​
For Application Load Balancers​

Run the following command to set the desync mitigation mode to defensive (recommended for most environments):

aws elbv2 modify-load-balancer-attributes \
    --load-balancer-arn {{load-balancer-arn}} \
    --attributes Key=routing.http.desync_mitigation_mode,Value=defensive

To enforce the highest level of protection, you may optionally use strictest instead of defensive after validating application compatibility.

... see more

policy.yaml​

Open File

Linked Framework Sections​

SectionSub SectionsInternal RulesPoliciesFlagsCompliance
💼 AWS Foundational Security Best Practices v1.0.0 → 💼 [ELB.12] Application Load Balancer should be configured with defensive or strictest desync mitigation mode1no data
💼 AWS Foundational Security Best Practices v1.0.0 → 💼 [ELB.14] Classic Load Balancer should be configured with defensive or strictest desync mitigation mode1no data
💼 Cloudaware Framework → 💼 Threat Protection48no data
💼 FedRAMP High Security Controls → 💼 AC-4(21) Physical or Logical Separation of Information Flows (M)(H)1155no data
💼 FedRAMP High Security Controls → 💼 CM-2 Baseline Configuration (L)(M)(H)3133no data
💼 FedRAMP Low Security Controls → 💼 CM-2 Baseline Configuration (L)(M)(H)32no data
💼 FedRAMP Moderate Security Controls → 💼 AC-4(21) Physical or Logical Separation of Information Flows (M)(H)55no data
💼 FedRAMP Moderate Security Controls → 💼 CM-2 Baseline Configuration (L)(M)(H)333no data
💼 NIST SP 800-53 Revision 5 → 💼 AC-4(21) Information Flow Enforcement _ Physical or Logical Separation of Information Flows3755no data
💼 NIST SP 800-53 Revision 5 → 💼 CA-9(1) Internal System Connections _ Compliance Checks39no data
💼 NIST SP 800-53 Revision 5 → 💼 CM-2 Baseline Configuration732no data
💼 PCI DSS v3.2.1 → 💼 6.5.1 Injection flaws, particularly SQL injection. Also consider OS Command Injection, LDAP and XPath injection flaws as well as other injection flaws.5no data
💼 PCI DSS v3.2.1 → 💼 6.5.2 Buffer overflows.5no data
💼 PCI DSS v3.2.1 → 💼 6.5.3 Insecure cryptographic storage.5no data
💼 PCI DSS v3.2.1 → 💼 6.5.4 Insecure communications.5no data
💼 PCI DSS v3.2.1 → 💼 6.5.5 Improper error handling.5no data
💼 PCI DSS v3.2.1 → 💼 6.5.6 All “high risk” vulnerabilities identified in the vulnerability identification process.5no data
💼 PCI DSS v3.2.1 → 💼 6.5.7 Cross-site scripting (XSS).5no data
💼 PCI DSS v3.2.1 → 💼 6.5.8 Improper access control.5no data
💼 PCI DSS v3.2.1 → 💼 6.5.9 Cross-site request forgery (CSRF).5no data
💼 PCI DSS v3.2.1 → 💼 6.5.10 Broken authentication and session management.5no data
💼 PCI DSS v4.0.1 → 💼 6.2.4 Software engineering techniques or other methods are defined and in use by software development personnel to prevent or mitigate common software attacks and related vulnerabilities in bespoke and custom software.5no data
💼 PCI DSS v4.0 → 💼 6.2.4 Software engineering techniques or other methods are defined and in use by software development personnel to prevent or mitigate common software attacks and related vulnerabilities in bespoke and custom software.5no data