- Newest
- Most votes
- Most comments
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:
-
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.
-
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.
-
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.
-
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
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
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!
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

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.