Direct answer
CORS testing checks which browser origins may read an API response and whether credentialed requests expose protected data. A permissive header is a starting signal; the assessment needs the endpoint's data sensitivity, credential behavior, and a browser-readable response.
Identify intended browser clients
Write down the web origins that legitimately call the API. An origin includes scheme, host, and port. Public data used by many websites can require a different policy from an authenticated account export.
Reference: OWASP REST Security Cheat Sheet: CORS.
Compare allowed and untrusted origins
In a controlled test, inspect response headers for a known allowed origin and a separate origin you own that should be denied. Check the actual sensitive response, not only a preflight route or a generic error.
- Record Access-Control-Allow-Origin and credential-related headers.
- Check whether the API uses cookies, explicit bearer tokens, or public access.
- Separate an API's CORS policy from its ordinary authentication policy.
Verify browser behavior
A command-line client does not enforce browser CORS rules. Use a harmless browser proof in an authorized session to establish whether the untrusted origin can read protected test data. Keep the demonstration confined to your own account and test records.
- Confirm the browser actually sends the relevant credentials.
- Inspect whether the response is readable by the test page.
- Record browser errors and credential restrictions as part of the result.
Keep CORS and authorization distinct
The server still needs to protect the endpoint against unauthorized callers. Tightening CORS changes browser response sharing; it does not prevent non-browser clients from sending requests. Retest legitimate frontend calls after narrowing the origin policy.
Reference: OWASP REST Security Cheat Sheet: CORS.
Assessment limits
Wildcard access to intentionally public data is not inherently a vulnerability. A reflected origin header does not prove credentialed data theft. Preflight results and HTTP clients alone cannot establish browser exploitability.
Frequently asked questions
Is Access-Control-Allow-Origin: * always unsafe?
No. It can be appropriate for deliberately public resources. Evaluate whether protected data is readable from an unintended browser origin.
Does CORS block unauthorized API requests?
CORS governs browser access to responses. API authentication and authorization must protect data and state independently.
Why test the final response after preflight?
A preflight describes whether a browser may attempt certain cross-origin requests. The final response and browser credential behavior determine what the requesting page can read.
Primary sources and further reading
These guides combine published security guidance with practical assessment planning. Adapt checks to the owner's policy, environment, and authorized scope.