This post explains why CORS request fails on the browser(Chrome, Firefox, etc.) when server CORS configuration and ‘Add response headers’ on the Application Lad Balancer(ALB) are set
Situation
- CORS(Cross-Origin resource sharing) is configured on the server side to allow cross-origin requests.
- ‘Add response headers’ is configured on ALB listener to add CORS header on the response as the following example:
> Access-Control-Allow-Origin header: *
> Access-Control-Allow-Methods header: GET, OPTIONS, POST
> Access-Control-Allow-Credentials header: true
- However, the client request fails with CORS error on the browser, while the request succeeds on the Postman.
Description
This error occurs because browsers enforce CORS (Cross-Origin Resource Sharing) policy restrictions that prohibit the simultaneous use of Access-Control-Allow-Credentials : true and Access-Control-Allow-Origin : *. When these two header values are configured together, the browser blocks the request before it reaches the Application Load Balancer(ALB), resulting in a CORS policy violation error.
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
• '*' means ANY website can make requests
• 'true' means cookies/auth headers are included
• Result : Any malicious site can steal user credentials
The browser blocks Access-Control-Allow-Origin: * with Access-Control-Allow-Credentials: true to prevent credential theft attacks where any malicious website could make authenticated requests using the user's cookies or tokens. This combination would allow any site on the internet to access sensitive user data from trusted services, creating a massive security vulnerability. The browser enforces that credentialed requests can only come from explicitly trusted origins, not from wildcard origins.
- Request succeeded (
Access-Control-Allow-Origin disabled )

- Request CORS error (
Access-Control-Allow-Origin set to * )

Preflight Request Behavior
Preflight request is an automatic HTTP OPTIONS request sent by browsers before certain cross-origin requests to check if the actual request is allowed.
The preflight request may not be blocked because the browsers do not strictly enforce the incompatible combination of Access-Control-Allow-Credentials : true and Access-Control-Allow-Origin : * during the preflight phase. Consequently, preflight requests typically receive a 200 OK response, while subsequent actual requests (e.g., POST, GET) are blocked by the browser's CORS policy enforcement.
Browser-Specific CORS Enforcement
CORS errors are exclusively enforced by web browsers as a security mechanism to protect users from cross-origin attacks. When accessing the same endpoints through non-browser clients such as Postman, mobile applications, or server-side HTTP clients, CORS restrictions do not apply, and requests succeed regardless of the header configuration. This behavior is by design, as CORS is a browser-implemented security policy rather than a server-side restriction.
Resolution
- Return the original request Origin in the response.
- Make sure that you do not configure
Access-Control-Allow-Origin header value * with Access-Control-Allow-Credentials header value true
Related Information
[1] https://docs.aws.amazon.com/elasticloadbalancing/latest/application/enable-header-modification.html#header-modification-attributes