AWS Application Load Balancer security hardening — server header removal
AWS Application Load Balancer · Security Header Hardening
TL;DR — The server: awselb/2.0 response header on AWS Application Load Balancers exposes your infrastructure software to anyone who looks. You can disable it using a single load balancer attribute: routing.http.response.server.enabled = false. This guide shows you how.

What is the problem?

When a client makes an HTTP request to an application behind an AWS Application Load Balancer, the ALB includes a Server response header by default. It looks like this:

HTTP Response # Default ALB response headers (excerpt) HTTP/2 200 content-type: application/json date: Fri, 14 Mar 2026 04:30:00 GMT server: awselb/2.0 x-amzn-requestid: abc123...

This header tells any attacker — or automated scanner — that your application is sitting behind an AWS Elastic Load Balancer, version 2.0. While this alone does not constitute a critical vulnerability, it is a textbook information disclosure finding and is flagged in:

Why attackers care: Information disclosure is the first stage of reconnaissance. Knowing you run ALB/2.0 tells an attacker which known vulnerabilities, misconfigurations, and bypass techniques to try first. It reduces the time from probe to exploit.

The fix: routing.http.response.server.enabled

AWS introduced the ability to disable this header via a load balancer attribute. The attribute is:

Attribute name routing.http.response.server.enabled
Available values true or false
Default value true (header is sent by default)
Effect when false The server: header is omitted from all ALB responses

How to disable it — 3 methods

Method 1: AWS Console

  1. Open the EC2 Console and navigate to Load Balancers.
  2. Select your Application Load Balancer.
  3. Click the Attributes tab.
  4. Click Edit in the top right.
  5. Scroll to HTTP response headers and toggle Server header to Off.
  6. Click Save changes.

Method 2: AWS CLI

Bash / AWS CLI # Replace YOUR_ALB_ARN with your actual load balancer ARN aws elbv2 modify-load-balancer-attributes \ --load-balancer-arn YOUR_ALB_ARN \ --attributes Key=routing.http.response.server.enabled,Value=false

To verify the change was applied:

Bash / AWS CLI aws elbv2 describe-load-balancer-attributes \ --load-balancer-arn YOUR_ALB_ARN \ --query 'Attributes[?Key==`routing.http.response.server.enabled`]'

Method 3: Terraform

Terraform (HCL) resource "aws_lb" "main" { name = "my-app-alb" internal = false load_balancer_type = "application" security_groups = [aws_security_group.alb.id] subnets = aws_subnet.public[*].id # Disable server header to prevent information disclosure preserve_host_header = false desync_mitigation_mode = "defensive" drop_invalid_header_fields = true enable_http2 = true enable_waf_fail_open = false enable_deletion_protection = true tags = { Environment = "production" Security = "hardened" } } # Disable server header via attribute resource "aws_lb_attribute" "disable_server_header" { load_balancer_arn = aws_lb.main.arn key = "routing.http.response.server.enabled" value = "false" }

Verify the fix

After applying the change, confirm the header is no longer present in ALB responses:

Bash / curl # Check response headers — server header should be absent curl -sI https://your-app-domain.com | grep -i server # Expected output after fix: (no output — header is gone) # Before fix: server: awselb/2.0
Expected result: The curl command should return no output for the server header. If it still appears, wait 60 seconds for propagation and test again.

Additional ALB hardening recommendations

While you are in the ALB attributes panel, consider applying these additional hardening measures. All are low-risk, high-value changes:

Drop invalid headers

routing.http.drop_invalid_header_fields.enabled = true
Drops requests with malformed HTTP headers, reducing attack surface.

Desync mitigation mode

routing.http.desync_mitigation_mode = defensive
Protects against HTTP desync and request smuggling attacks.

HTTPS redirect

Add a listener rule to redirect all HTTP (port 80) traffic to HTTPS (port 443) with a 301 permanent redirect.

Enable access logs

access_logs.s3.enabled = true
Essential for incident response and compliance audits.

Why does this matter for your VAPT report?

In our experience running penetration tests, the server: awselb/2.0 header appears in roughly 60% of AWS-hosted web applications we test. It is consistently flagged as an informational to low severity finding depending on the client's compliance framework.

For SOC2 Type 2 auditors and ISO 27001 assessors, it is evidence that the organisation has not fully hardened its infrastructure against information disclosure. Fixing it takes under 5 minutes and removes the finding completely from your next VAPT report.

Found this in your VAPT report? If Summit flagged the server header in your report, apply the fix above and contact us via your Slack channel. We will verify it is resolved and update your certificate status within 24 hours.
AWS ALB Security Headers Information Disclosure Hardening OWASP