Wiki · Concept · Last reviewed June 25, 2026

Cross-Origin Resource Policy

Cross-Origin Resource Policy is a browser response-header rule for deciding which no-cors cross-origin or cross-site requests may receive a resource body.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: browser security, cross-origin isolation, resource loading, agents, web governance

Definition

Cross-Origin Resource Policy, or CORP, is an HTTP response-header mechanism defined by the Fetch Standard. A resource owner sends Cross-Origin-Resource-Policy to state whether no-cors requests from other origins or sites should be allowed to receive that resource. MDN's header reference describes the policy as a signal that the browser should block no-cors cross-origin or cross-site requests to the resource.

CORP is related to, but different from, Cross-Origin Resource Sharing. CORS exposes selected cross-origin responses to scripts. CORP protects the resource itself in opaque no-cors contexts, such as ordinary image loads or other embedded subresources.

How It Works

The Fetch Standard defines three case-sensitive values: same-origin, same-site, and cross-origin. same-origin allows only the same origin. same-site allows a broader site relationship. cross-origin allows other origins to load the resource.

CORP applies to no-cors requests. MDN's guide notes that a response header does not prevent the request from being sent. The protection happens at response handling: the browser denies access to the body when the policy check fails. In Fetch terms, a failed check can become a network error for the consuming context.

CORP also connects directly to Cross-Origin Embedder Policy. A document using COEP require-corp can require cross-origin subresources either to be same-origin or to send a suitable CORP header. The permissive cross-origin value lets a public resource opt into that isolation regime.

Agent Context

CORP matters for browser agents because agents open dashboards, trigger previews, render documents, load images, collect screenshots, and test forms. A blocked no-cors resource can look like a flaky request, broken image, missing script, or incomplete document. Treating it only as an error loses the governance signal.

For an agent runtime, CORP should be read as a resource owner's boundary. If the agent is asked to retry through a different endpoint, proxy the asset, or scrape a server-side copy, the system should make that change explicit. Automated work should not dissolve the browser boundary invisibly.

Governance Use

Governance use starts with dependency inventory. A site that serves private images, user documents, account avatars, internal JSON endpoints, or generated previews should know which resources are reachable through no-cors embedding paths. Public assets may need cross-origin. Sensitive resources may need same-origin. Shared services inside one registrable site may consider same-site, remembering that same-site is broader than same-origin.

For AI-mediated browsing, CORP events belong in task logs. Record the top-level URL, resource URL with secrets removed, request mode, destination, observed CORP value, related COEP and CORS context, browser version, task identifier, and nearby agent action. If Fetch Metadata request headers are available, preserve relevant site and destination indicators. Avoid raw cookies, bearer tokens, full query strings, or document contents unless a narrow incident review requires them.

Limits

CORP is not authentication. It does not decide who may use an account, grant JavaScript read access, replace CORS, or secure a server endpoint by itself. It also does not stop the HTTP request from reaching the server, so logs, rate limits, and request-side effects still matter. Its narrower job is controlling whether an opaque no-cors response body can cross an origin or site boundary.

It can also break legitimate embeds. Fonts, images, media, payment widgets, analytics pixels, generated PDFs, and documentation assets may be consumed from more places than their owners realize. Governance review should test real browsers, because operational behavior depends on Fetch, COEP, CORS, and rendering paths together.

Minimum Evidence Record

For agent-mediated browsing, preserve the response URL, exact Cross-Origin-Resource-Policy value, top-level URL, initiating URL when available, request mode, destination, related CORS outcome, related COEP value, browser version, task identifier, agent action, and whether a user approved a workaround. Strip secrets from URLs before storage.

Source Discipline

Use the Fetch Standard for formal header values and policy-check behavior. Use MDN's header reference for implementation-facing syntax. Use MDN's CORP guide for the distinction between sending a request and exposing the body, and for the relationship between CORP and COEP. Use CORS sources separately when evaluating script read access.

Spiralist Reading

Spiralism reads CORP as a quiet refusal of ambient consumption. The web made it easy to point a page at someone else's resource and let the browser carry it home. CORP lets the resource answer: only from here, only from this site, or openly from anywhere.

The agent-era lesson is restraint. A capable browser agent can find another route to many assets: proxy it, screenshot it, request it through a server, or ask a tool outside the page. CORP is a reminder that not every failed load is a problem to solve.

Sources

Return to Wiki