Is AWS ALB too permissive? Accepts suspicious headers, weak against DDoS

Question

While evaluating the security posture of the AWS Application Load Balancer (ALB), I noticed that it appears to accept and forward HTTP requests with suspicious headers, such as unusual User-Agent strings that are commonly used in DDoS attacks.

It’s surprising that AWS doesn’t offer basic header-level protections by default, protections that are typically included with services like Cloudflare (e.g., filtering of known bad user agents, malformed headers, or obfuscated values).

I understand that AWS WAF and Shield can be integrated, but relying on WAF to inspect and block millions of requests during an attack can lead to unexpected and excessive costs — which can be especially burdensome for small businesses or personal projects.

My questions:
* Is this permissive behavior by ALB intentional, and if so, is it purely for compatibility?
* Are there any plans to provide built-in header validation, rate limiting, or lightweight protections without needing a WAF, for example by an optional setting?
* Are there best practices for ALB users who want to harden security without incurring massive costs during high traffic or attack scenarios?

Gary Mclean · Answer

You can enable the setting on the ALB to drop Invalid Headers even without WAF. The attribute has FALSE as its default value.
Its limited as it only covers this:

*Indicates whether HTTP headers with header fields that are not valid are removed by the load balancer (true), or routed to targets (false). The default is false. Elastic Load Balancing requires that valid HTTP header names conform to the regular expression [-A-Za-z0-9]+, as described in the HTTP Field Name Registry. Each name consists of alphanumeric characters or hyphens. Select true if you want HTTP headers that do not conform to this pattern, to be removed from requests.*

https://repost.aws/knowledge-center/elb-alb-drop-not-valid-headers

SHAJAM · Answer

The Application Load Balancer is fundamentally designed to be a transparent Layer 7 proxy — its main purpose is:

* Forward traffic, not filter
* Compliant with apps using custom or non-standard headers
* Terminate HTTP/S
* Route requests to targets based on rules (host, path, header, etc.)
* Preserve original request as possible

This permissiveness is deliberate to maintain maximum application compatibility.

Shield stops infrastructure-level attacks before they hit your ALB — but it does not inspect the HTTP content or headers.

Is AWS ALB too permissive? Accepts suspicious headers, weak against DDoS

Add your answer

Relevant content