On this page
What is the problem with the ALB server header?
When a client sends a request to an application behind an AWS Application Load Balancer, the load balancer includes a Server header in its responses by default:
HTTP/2 200
content-type: application/json
date: Fri, 14 Mar 2026 04:30:00 GMT
server: awselb/2.0The ALB server header tells an attacker, or an automated scanner, that the application sits behind an AWS Elastic Load Balancer. On its own that is not a critical vulnerability, but it is a textbook information disclosure finding. It is covered by:
- OWASP WSTG-INFO-02: Fingerprint Web Server
- NIST SP 800-115, the technical guide to information security testing
- Most enterprise security questionnaires and compliance audits
- Summit VAPT reports, where we flag it on every engagement it appears in
Why attackers care
Information disclosure is the first stage of reconnaissance. Knowing the stack tells an attacker which known misconfigurations and bypass techniques to try first, which shortens the path from probe to exploit.
The fix: a listener attribute
AWS lets you remove the header through HTTP header modification on the listener:
- Attribute
routing.http.response.server.enabled- Scope
Listener: set it on each HTTP and HTTPS listener- Values
true | false- Default
true (the header is sent)- Effect of false
The ALB no longer adds the Server header on that listener
This is a listener attribute, not a load balancer attribute. Many older guides use modify-load-balancer-attributes, which rejects this key.
How to disable the ALB server header: 3 methods
Method 1: AWS console
- Open the EC2 console and choose Load Balancers.
- Select your Application Load Balancer.
- On the Listeners and rules tab, choose the listener’s protocol and port to open its details page.
- On the Attributes tab, choose Edit.
- Under ALB server response header, turn off Server header.
- Choose Save changes, then repeat for every other listener (for example port 80 and port 443).
Method 2: AWS CLI
List the listeners first, then update each one:
# Find the listener ARNs for your load balancer
aws elbv2 describe-listeners \
--load-balancer-arn YOUR_ALB_ARN \
--query 'Listeners[].ListenerArn'
# Disable the server header on one listener (repeat for each ARN)
aws elbv2 modify-listener-attributes \
--listener-arn YOUR_LISTENER_ARN \
--attributes Key=routing.http.response.server.enabled,Value=falseConfirm the change:
aws elbv2 describe-listener-attributes \
--listener-arn YOUR_LISTENER_ARN \
--query 'Attributes[?Key==`routing.http.response.server.enabled`]'Method 3: Terraform
Recent versions of the Terraform AWS provider expose the listener attribute directly on aws_lb_listener. If terraform validate rejects the argument, upgrade the provider.
resource "aws_lb_listener" "https" {
load_balancer_arn = aws_lb.main.arn
port = 443
protocol = "HTTPS"
ssl_policy = "ELBSecurityPolicy-TLS13-1-2-2021-06"
certificate_arn = aws_acm_certificate.main.arn
# Remove "server: awselb/2.0" from responses on this listener
routing_http_response_server_enabled = false
default_action {
type = "forward"
target_group_arn = aws_lb_target_group.app.arn
}
}Verify the fix
After the change, check that the header is gone:
# Should print nothing once the header is removed
curl -sI https://your-app-domain.com | grep -i '^server:'
# Before the fix it prints: server: awselb/2.0Expected result
The curl command returns no server line. If it still appears, check that you changed every listener the domain uses, and that the header is not being added by your application itself.
More ALB hardening while you are there
These load balancer attributes are low-risk and worth applying in the same change window:
Drop invalid header fields
routing.http.drop_invalid_header_fields.enabled = true
Drops headers that are not valid HTTP, which reduces request-smuggling risk.
Desync mitigation
routing.http.desync_mitigation_mode = defensive
Protects against HTTP desync attacks. Use strictest if your clients allow it.
Redirect HTTP to HTTPS
Add a port 80 listener rule that returns a 301 redirect to HTTPS on port 443.
Access logs
access_logs.s3.enabled = true
Gives you the request history you need for incident response and audits.
A wider review of load balancer, WAF and IAM configuration is part of a cloud security assessment.
Why the ALB server header matters for your VAPT report
In our testing, the server: awselb/2.0 header appears on roughly 60% of AWS-hosted web applications. It is rated informational to low severity depending on the client’s framework, and it shows up in nearly every web application VAPT report for AWS workloads.
For SOC 2 and ISO 27001 assessments, it is a small but visible sign that infrastructure has not been fully hardened. Fixing it takes minutes and removes the finding from your next report.
Found this in your Summit report?
Apply the fix above and tell your Summit project lead. We will re-test the finding and update its status in your report.
Frequently asked questions
Is the ALB server header a vulnerability?
On its own it is an informational or low-severity finding, not an exploitable flaw. It is reported because it tells attackers which infrastructure you use, and auditors and enterprise security questionnaires expect it to be removed.
Is routing.http.response.server.enabled a load balancer attribute or a listener attribute?
It is a listener attribute. Set it to false on each HTTP and HTTPS listener with modify-listener-attributes, not modify-load-balancer-attributes.
Does removing the server header break anything?
No. Browsers and HTTP clients do not depend on the Server response header. The change applies to responses the load balancer sends and does not affect your targets.
Will this remove the server header my application sets?
The attribute controls the header the ALB itself adds. If your web server or framework (for example nginx or Express) also sets a Server or X-Powered-By header, remove it in that software's configuration too.
