Wiki · Concept · Last reviewed June 25, 2026

Cross-Origin Resource Sharing

Cross-Origin Resource Sharing, or CORS, is the Fetch-standard browser mechanism that lets a server opt in to exposing selected cross-origin responses to scripts running in another origin.

Category: Concept Updated: June 25, 2026 Tags: browser security, CORS, agents, web governance

Definition

Cross-Origin Resource Sharing is part of the WHATWG Fetch Standard. It gives browsers a protocol for deciding when a script on one origin may read a response from another origin. MDN describes the practical shape as an HTTP-header mechanism: a server indicates which outside origins may be permitted to load resources, and the browser enforces the result for web content. The important word is expose. CORS is not a general authorization system for the server; it is a browser rule for whether JavaScript receives a usable cross-origin response.

This distinction matters for AI systems because browser agents inherit ordinary web boundaries and then add model-mediated action. A page can ask an agent to fetch, summarize, click, or paste across contexts. CORS may stop a script from reading a response, but it does not decide whether an agent should trust text, obey a tool description, or transfer information between sessions.

Mechanism

The usual CORS exchange begins with an Origin request header and a response header such as Access-Control-Allow-Origin. If the server returns a matching origin, or a wildcard where allowed, the browser can expose the response to the requesting script. If the header is missing or does not match the request, browser script access fails even if the network request itself reached the server.

Some cross-origin requests require a preflight. In that path, the browser sends an OPTIONS request before the actual request, using headers such as Access-Control-Request-Method and Access-Control-Request-Headers to ask whether the method and headers are acceptable. The Fetch Standard defines CORS-preflight fetch behavior, and MDN notes that preflight is used to check whether the server will permit the actual request. Successful preflight responses commonly use Access-Control-Allow-Methods, Access-Control-Allow-Headers, and sometimes Access-Control-Max-Age.

Credentials are the sharp edge. Fetch treats credentials as including cookies, TLS client certificates, and HTTP authentication entries. A credentialed CORS response cannot use the simple wildcard pattern in the same way as a non-credentialed response. For requests that include credentials, the server needs the right origin-specific response and Access-Control-Allow-Credentials: true. That is why a CORS review should separate public cross-origin reads from authenticated or session-bearing reads.

Agent Context

For AI Browsers and Computer Use, CORS is a boundary around page scripts, not a boundary around the model's whole cognition. An AI browser may see visible text, screenshots, downloaded files, browser chrome, tool output, and prior messages. CORS can keep one page's script from directly reading another origin's protected response, but a model with access to rendered content may still carry facts across tasks unless the agent runtime imposes its own context controls.

CORS evidence is still useful. It tells reviewers whether a web surface is relying on browser-enforced response sharing, whether a tool panel is exposed only to selected origins, and whether an authenticated API is available to arbitrary pages. In agent systems, pair CORS review with Fetch Metadata Request Headers, Content Security Policy, sandboxing, permission records, and audit logs.

Governance Use

A serious governance review should record the requesting origin, target URL, HTTP method, request headers, response status, CORS response headers, credential mode, redirect chain, browser version, and whether a preflight occurred. For agentic browsing, add the model instruction, the active tool, the frame origin, and whether the request was triggered by human action, model output, page script, or a tool callback.

The central question is not "does this endpoint have CORS?" The better questions are which origins can read which responses, whether credentialed reads are narrowly scoped, whether error responses leak useful data, whether preflight results are cached longer than the operational risk justifies, and whether the same policy applies to production, staging, and authenticated subdomains.

Limits

CORS does not make a server private. It does not authenticate users, authorize actions, validate business rules, block server-to-server requests, or prevent all cross-site request forgery. Simple cross-origin requests may still be sent by browsers even when their responses are not exposed to script. Servers that mutate state must rely on normal authorization, CSRF defenses, cookie attributes, origin checks where appropriate, and application-specific validation.

CORS also cannot evaluate meaning. It cannot know whether a prompt is malicious, whether an allowed origin has been compromised, whether a browser extension changes the page, or whether a model is about to paste sensitive text into an allowed destination. Its contribution is narrower and still valuable: it makes one class of cross-origin response sharing explicit enough to test.

Review Record

Source Discipline

Claims about CORS should cite the Fetch Standard for normative browser behavior and browser documentation for operational explanation. For a live service, standards citations are not enough. Reviewers should test the actual endpoint with representative origins, methods, headers, credential modes, and browsers.

Spiralist Reading

Spiralism reads CORS as a disciplined answer to a common confusion: contact is not consent, and reachability is not permission to read. The web lets many requests cross borders; CORS says which responses may become usable knowledge inside a page. For agentic browsers, that lesson should widen. Every exposed response, tool result, and rendered page fragment asks the same governance question: who is allowed to carry this across the boundary?

Sources

Return to Wiki