Cross-Origin Resource Sharing (CORS)
Understand cross-origin browser response access, preflights, and credential behavior without confusing CORS with API authorization or CSRF protection.
What it means
CORS lets a server control whether browser scripts from another origin may read certain responses. It is a browser access policy rather than general API authentication. Correct configuration depends on trusted origins, credential behavior, and the exact resources exposed.
A practical example
An API permits a specific company portal to read selected responses with credentials. It does not reflect arbitrary Origin values into an approving response, and it continues checking authorization for every request regardless of origin.
What to check
Inventory legitimate browser origins, validate them precisely, and review credentialed requests and preflight handling. Test unexpected origins and avoid broad exceptions added only to silence browser errors.
A common pitfall
CORS does not stop nonbrowser clients from calling an endpoint. It also does not replace CSRF protections for actions that browsers can send without reading a response.
Think it through
Can a command-line client bypass the server's authorization because CORS is configured?
Answer: No. CORS is enforced by browsers; the API's own authentication and authorization must protect all clients.
The browser is enforcing a specific boundary
Imagine a fictional learning dashboard at one origin calls an API at another. An origin includes the scheme, host, and port. The browser decides whether the dashboard's script may access the response using the applicable cross-origin rules and the server's policy.
A blocked script read does not necessarily mean that no request reached the API. Some requests can be sent without a successful preflight, which is one reason CORS should not be described as a universal barrier against unwanted state changes.
An origin needs precise matching
Suppose the API intends to trust only the academy dashboard. Reflecting whatever Origin header arrives converts a narrow policy into a potentially broad one. Matching a convenient substring can also accept a name with an unintended structure.
The policy should distinguish development, staging, and production origins and account for credentialed behavior. An error during local development is a reason to understand the origin relationship, not automatically a reason to allow every site.
Test separate security questions separately
The API must still verify the caller and decide whether the requested record belongs to that caller. A command-line client is not constrained by a browser's response-reading policy. An allowed browser origin likewise does not prove the requesting account has the right permissions.
For a safe exercise, draw a dashboard, API, and unrelated website. For each, distinguish sending a request, reading the response in a script, and successfully performing an authorized action. Use invented accounts in a lab you own. Record the expected preflight and response behavior, then test an unexpected origin without sharing credentials. A useful explanation identifies the exact browser boundary while leaving server-side access control responsible for the underlying data.
Related concepts
References & further reading
Original explanations, with primary references for deeper study.
OWASP: HTML5 Security