AWS API Gateway Support
Fixing CORS errors with AWS API Gateway.
A CORS error is the browser refusing a response because the right headers were missing, often on the preflight OPTIONS request or on an error response. It looks like an API problem but the API often works fine in Postman. We find which response lacks headers and fix it at the correct layer.
When You Need This
The situations where this work pays for itself.
Signs it is time
- Browser console shows 'blocked by CORS policy: No Access-Control-Allow-Origin header'
- The API works in Postman or curl but not from your web app
- Preflight OPTIONS requests return 403 or 404
- CORS works for successful calls but fails on errors or 401 responses
- Cookies or Authorization headers are involved and the wildcard origin is rejected
What you get
- A diagnosis showing which request and layer failed
- CORS configuration in infrastructure as code
- Lambda response helper that adds headers on every path
- Test commands for preflight and actual requests
How we do it
A clear, safe process you can follow along with.
1. Read the browser network tab
We find the failing request and check whether the preflight OPTIONS failed or the actual request lacked headers. These are fixed in different places.
2. Fix the preflight
On REST APIs, the OPTIONS method needs a response with Access-Control-Allow-Origin, Allow-Methods and Allow-Headers, either via a mock integration or the console's enable CORS action. On HTTP APIs, we configure the API's CORS settings and make sure authorizers do not block OPTIONS.
3. Fix the real response headers
With a Lambda proxy integration, API Gateway does not add CORS headers to your response. The function itself must return Access-Control-Allow-Origin in its headers object, including on error paths.
4. Cover gateway-generated errors
Authorizer rejections, throttling and 5XX errors created by API Gateway have no CORS headers unless you add them to Gateway Responses for DEFAULT_4XX and DEFAULT_5XX. This is why the browser shows CORS when the real problem is a 401.
5. Handle credentials and headers correctly
If the request sends cookies or uses credentials, the allowed origin must be the exact origin rather than a wildcard, and Access-Control-Allow-Credentials must be true. Every custom header the client sends must appear in Allow-Headers.
6. Redeploy and verify
REST API changes need a new deployment to the stage. We confirm with curl using an Origin header, then in the browser with cache disabled.
Mistakes we help you avoid
Common ways this goes wrong, and what we do instead.
Adding headers only to OPTIONS
The actual GET or POST response must also carry them.
Forgetting to redeploy a REST API stage
Console edits do nothing until the stage is deployed.
Using a wildcard origin with credentials
Browsers reject it. Use the specific origin.
Disabling CORS in the browser to test
It hides the problem. Real users still fail.
Frequently Asked Questions
Why does Postman work but the browser fails?
Postman does not enforce CORS. Browsers do, so a missing header only breaks browser calls.
Do I need CORS headers in my Lambda response?
For REST API with Lambda proxy integration and for HTTP APIs with payload handled by your function, headers you return are used as-is, so check what your API type adds. We test the actual response.
Why is only the 403 or 401 a CORS error?
Errors generated by API Gateway itself, such as authorizer denials, need CORS headers on Gateway Responses to be readable by the browser.
Want Help With Fixing CORS errors with AWS API Gateway?
Schedule an appointment. Tell us about your environment and we will outline the safest, highest-value approach.
Schedule Appointment › No commitment required