Cross-Origin Resource Sharing (CORS) is a browser-enforced security and integration mechanism that controls which external origins may access a web application's resources. It relies on standardized HTTP headers to allow or block cross-origin requests. Proper configuration of Access-Control headers affects both security and interoperability in modern web and…
Use this profile to understand the building block briefly, place it in the model, and switch to the 360° assessment when needed.
Theoretical construct: explains a term, principle, or mental model.
What organizes, connects, or makes decisions possible.
Cross-Origin Resource Sharing (CORS) is a browser-side rule set for requests between different origins. Using HTTP headers, it specifies which foreign origins may read responses and when the browser must check or block a request before it proceeds.
CORS emerged from the tension between the same-origin policy and the reality of the web, where pages must load and request resources from other origins. To allow controlled exceptions, CORS was standardized as an HTTP-header-based mechanism. The W3C specification defines the model, and the later Fetch standard places it within the browser’s unified fetching architecture.
Think of CORS as border control inside the browser. Every cross-origin request carries its `Origin` label. The server decides through response headers whether that origin may read the reply. For simple requests, that permission can be enough on its own; for riskier methods, the browser first asks with an `OPTIONS` preflight. Only when origin, method, headers, and, if relevant, `Credentials` align does the browser send the actual request.
The browser baseline restricts reading responses to the same origin unless another mechanism allows an exception.
An origin is the combination of scheme, host, and port and defines the relevant trust boundary.
Certain requests may be sent without a preflight when their method and headers stay within the allowed standard set.
Before some cross-origin requests, the browser sends an `OPTIONS` request to ask which methods and headers are permitted.
This response header names the allowed origins or `*`, which determines who may read the response.
Cookies, HTTP authentication, and client certificates need explicit permission; they cannot be combined with `*`.
CORS matters when web front ends need data from a separate API, a different subdomain setup, or an external service. It enables controlled sharing, but it does not replace authentication, authorization, or server-side security controls. Misconfigured headers often cause blocked requests, overexposed responses, or issues with cookies and other credentials.
Where this building block is located in the topic model.
No structure path available.
Explore how this building block connects to concepts, methods, technologies, and tools.
These sources establish the term and its professional meaning.
All direct connections of the current building block in a compact text view.
This classification shows where the building block typically matters, how demanding it is, and what kind of impact it has in the model.
The level within the organization (enterprise, domain, team) at which the AssetBlock is applied.