Audit CORS rules against real browser origins
Create an origin and credential matrix for your API. Check preflight behavior, actual responses, cache variation, and unexpected origin matches.
A CORS audit determines which browser origins can read a response. It does not replace API authentication or permission checks. Start with the clients that are meant to call the API, including their schemes and ports. Treat a development origin as an explicit exception, not a pattern that automatically reaches production.
MDN explains the CORS request and response rules, including credentialed requests and preflight behavior. The matrix below is a practical way to compare those browser rules with your intended clients.
Write an exact origin matrix
Use reserved example names in the review document. Run tests only on the controlled application and test origins named in the scope. Include a near-match hostname so a permissive suffix check cannot pass unnoticed.
| Origin class | Credentials | Intended response access |
|---|---|---|
| Approved application origin | Required session mode | Allowed after normal authorization |
| Same hostname, wrong port | Same mode | Denied unless separately approved |
| Similar suffix on another host | Same mode | Denied |
| Unrelated controlled origin | Same mode | Denied |
| Null origin | Defined client mode | Denied unless the use case requires it |
Record the exact allow-origin response, not only whether a header exists. A server that reflects every supplied origin has not implemented an allowlist.
Test the full browser exchange
Check both the preflight and the subsequent response. A permitted OPTIONS request does not prove the browser can read the actual result. Test the methods and request headers used by the real client, then repeat with an unapproved combination.
For credentialed responses, verify that the policy names an allowed origin rather than using the wildcard. If the response changes according to Origin, inspect the cache behavior and the appropriate Vary handling. Exercise authentication errors as well as successful responses, since different middleware paths may emit different headers.
Keep CORS separate from authorization
Confirm that the same API denies an unauthorized caller without relying on browser enforcement. Non-browser clients do not gain a permission boundary from CORS. Also inspect whether a cross-origin request can cause a mutation even when its response cannot be read; that belongs in the CSRF review.
Save one result per matrix row with browser version, route, response status, and readable-body outcome. Assign unexpected origins to the policy owner. Remove obsolete preview origins during deployment cleanup so the allowlist remains a record of current clients rather than historical exceptions.
Find the gaps before your next launch
Use the release checklist to identify changed security boundaries and missing evidence. Discuss the application paths you want reviewed before launch.