Skip to content

ALB Listener Attributes: Headers Missing in Non-2XX Responses

0

Issue Description I'm experiencing an issue with CORS headers in AWS Application Load Balancer (ALB). While the headers are correctly set for successful responses (2XX), they're missing for error responses (4XX, 5XX), causing CORS issues in my frontend application.

** Current Configuration**

ALB Listener Attributes

I've configured the following using the AWS CLI:

--listener-arn arn:aws:elasticloadbalancing:us-east-1:hidden:listener/app/hidden/c1dc9f235ff14e5f/9b5c0e65d0762hidden
--attributes Key="routing.http.response.strict_transport_security.header_value",Value="max-age=31536000;includeSubdomains;preload"
Key="routing.http.response.access_control_allow_origin.header_value",Value="*"

Expected Headers

  • HTTP Strict Transport Security (HSTS): max-age=31536000; includeSubdomains; preload
  • Access-Control-Allow-Origin: *
  • Access-Control-Allow-Headers: *
  • Access-Control-Allow-Methods: HEAD, GET, POST, OPTIONS, DELETE, CONNECT, PUT, PATCH, TRACE
  • Access-Control-Allow-Credentials: true
  • Access-Control-Max-Age: 36000
  • X-Content-Type-Options: nosniff
  • X-Frame-Options: DENY

Environment Details

  • Service: AWS Application Load Balancer
  • Region: us-east-1
  • Load Balancer Type: Application
  • Protocol: HTTP/HTTPS

Expected Behavior

  • CORS headers should be present in ALL responses, regardless of the HTTP status code
  • Frontend applications should be able to handle error responses properly
  • Headers should be consistent across all response types

Actual Behavior

  • Headers are correctly included in 2XX responses
  • Headers are missing in non-2XX responses (4XX, 5XX)
  • Frontend applications fail to process error responses due to CORS restrictions

Example Response Headers

Successful Response (2XX)

http: HTTP/1.1 200 OK access-control-allow-origin: strict-transport-security: max-age=31536000; includeSubdomains; preload ... [other headers present]

Error Response (4XX/5XX)

http HTTP/1.1 404 Not Found ... [CORS headers missing]

Questions

  1. Is this a known limitation of the ALB listener attributes feature?
  2. How can I configure the ALB to include CORS headers in all responses, including error responses?
  3. Are there any workarounds or alternative approaches to ensure consistent header presence across all response types?

Additional Context

  • The ALB is configured using CloudFormation
  • Frontend applications are running on different domains
  • CORS headers are critical for our microservices architecture

Any guidance or solutions would be greatly appreciated!

4 Answers
2

The issue you're experiencing with CORS headers missing in non-2XX responses from your Application Load Balancer (ALB) is indeed a known limitation of the ALB listener attributes feature. By default, ALB only adds custom headers to successful responses (2XX status codes).

To address this limitation and ensure CORS headers are present in all responses, including error responses, you have a few options:

  1. Use a custom error page: Configure your ALB to use a custom error page for 4XX and 5XX responses. This custom error page can include the necessary CORS headers. You can set this up in your ALB's error configuration.

  2. Implement CORS handling at the application level: Instead of relying solely on the ALB for CORS headers, implement CORS handling in your backend application. This way, your application can set the appropriate headers for all types of responses, including errors.

  3. Use AWS CloudFront with ALB: Place CloudFront in front of your ALB. CloudFront allows you to add custom headers to all responses, including error responses. You can configure CloudFront to add the necessary CORS headers to all responses, regardless of the status code.

  4. Use a Lambda@Edge function with CloudFront: If you choose to use CloudFront, you can also implement a Lambda@Edge function to dynamically add CORS headers to all responses. This gives you more flexibility in header management.

For your specific configuration, you might want to consider implementing option 2 or 3. Handling CORS at the application level gives you the most control and ensures consistent behavior across all response types. If you prefer to keep this logic out of your application, using CloudFront with your ALB would be a good alternative.

Remember to test thoroughly after implementing any changes to ensure that all your CORS headers are present in both successful and error responses, and that your frontend applications can properly handle all types of responses.

Sources
HTTP header modification for your Application Load Balancer - Elastic Load Balancing
Troubleshooting CORS - Amazon Simple Storage Service
Drop not valid headers in Application Load Balancer | AWS re:Post

answered a year ago
EXPERT
reviewed a year ago
  • is it true? I had a load balancer with headers also in the 4xx responses, in all responses but I configured it using aws client v2 and I don't remember how I did it.

1

Hi,

On your question about headers, responses always tend to be reduced to a very minimum in their content (incl headers) for errors: you want to disclose the very minimum quantity of information to help legit users solve their problems but prevent potential attackers to obtain information that they can reuse in a bad way.

That is one of the reasons why some headers are missing in some error responses.

Best,

Didier

EXPERT
answered a year ago
EXPERT
reviewed a year ago
0

I finally set up a CloudFront in front of my ALB—a solution I personally dislike because it requires additional infrastructure. I’d appreciate any updates on this topic to help avoid unnecessary resource creation for my backend. Thank you!

answered a year ago
0

CORS headers in AWS Application Load Balancer have some known limitations and behaviors that can affect error responses. CORS headers are only returned in requests with successful integration responses. Custom error page is a recommended option, Enable custom error responses in ALB and Configure error responses for each status code. Few best practices below.

  • Use CloudFormation  for consistent infrastructure management
    
  • Implement monitoring for CORS-related errors
    
  • Test with different response codes
    
  • Consider rate limiting for error responses
    
AWS
EXPERT
answered a year ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.