Friends who have done web development should have experienced that HTML gives us great flexibility — we can write basic content like <p>hello world</p>, and also reference external resources through methods like <img src="https://othersite.com/hello.png">. However, behind this "freedom" lie many security and usage pitfalls. I've fallen into them several times, so today I'll clarify these cross-origin related knowledge points based on my actual experiences.

In HTML web development, pages can not only provide local content through tags like <p>hello world</p>, but also embed external resources through the form of <img src="https://othersite.com/hello.png">. While the high degree of freedom in resource referencing in HTML brings convenience to development, it also leads to security issues such as resource abuse and illegal invocation of cross-origin interfaces. Browser security policies like CORP, CORS, COOP, and COEP are the core solutions to these problems. This article will analyze their functions and configuration methods one by one.

I. CORP (Cross-Origin Resource Policy)

The core function of CORP is to control cross-origin access permissions for resources, that is, to determine whether a resource is allowed to be referenced and loaded by pages from other origins, solving the problem of resources being illegally framed and referenced.

In typical scenarios, if a gallery site stores a large amount of high-definition resources, without permission restrictions, other sites can build pages through simple HTML and directly reference the image resources of the site, without bearing storage and bandwidth costs, leading to the abuse of the original site's resources. At this time, CORP response headers can be configured for image resources to restrict only resources from the same domain / same-site domain from being fetched.

The core values and meanings of the CORP response header are as follows. Browsers will intercept resource reference requests from unauthorized origins based on the configuration:

Table

After configuring CORP: same-site, when non-site domains reference resources through tags like <img>, the browser will directly block the loading, fundamentally preventing resource abuse.

II. CORS (Cross-Origin Resource Sharing)

The core function of CORS is to control cross-origin invocation permissions for interfaces, that is, to determine whether an interface is allowed to be requested by pages from other origins, whether it can carry custom headers / credentials, and whether non-basic response headers can be read. It is the core strategy for solving cross-origin interface invocation problems, with finer control dimensions than CORP, mainly applicable to API interface scenarios.

Typical Cross-Origin Invocation Problems and Solutions

1. Interface called illegally: If the interface is configured with Access-Control-Allow-Origin: *, it means that all origins are allowed to call the interface and obtain responses, which can easily lead to self-use interfaces being illegally requested by third parties. Changing this value to a specified business domain name (such as yoursite.com) can restrict only this domain name from calling the interface, and third-party requests will be blocked by the browser.
2. Cross-origin response headers cannot be read: When requesting an interface across origins, the browser only allows JS to read a few basic response headers such as Content-Type by default. If you need to read custom/non-basic headers such as Server and X-Request-Id, you need to configure Access-Control-Expose-Headers to specify the names of the response headers that are allowed to be exposed.
3. Custom request headers are intercepted: When carrying custom headers during cross-origin requests, the browser will intercept the request. You need to configure Access-Control-Allow-Headers to specify the names of the request headers that are allowed to be carried, otherwise the request cannot be sent normally.

CORS Core Response Header Configuration

CORS implements fine-grained control through multiple exclusive response headers. The default rules, values, and functions of each header are as follows, covering all dimensions of "who can call, how they can call, and what data they can get":

1. Access-Control-Allow-Origin (Controls allowed request origins)

• Default rule: Cross-origin requests are not allowed by default.

• Core values:

  Value	Description
  *	Allows arbitrary origins to access resources (⚠️ Cannot be used with Access-Control-Allow-Credentials: true)
  https://example.com	Only allows specified origins to access resources, precisely controlling the access scope.
  null	Allows origins with Origin: null to access (e.g., local file:// pages, sandboxed iframes).

2. Access-Control-Allow-Methods (Controls allowed request methods)

• Default rule: Cross-origin request methods are not allowed by default.

• Core values:

  Value	Description
  GET/POST/PUT/DELETE/PATCH	Allows a single specified HTTP request method.
  OPTIONS	Allows preflight requests (the mandatory preceding request for complex cross-origin requests).
  GET, POST, OPTIONS	Allows multiple request methods, separated by commas.

3. Access-Control-Allow-Headers (Controls allowed request headers)

• Default rule: Only basic request headers within the CORS whitelist (e.g., Accept, Content-Type) are allowed to be carried.

• Core values:

  Value	Description
  Content-Type/Authorization	Allows specified standard request headers to be carried.

4. Access-Control-Allow-Credentials (Controls whether credentials are allowed to be carried)

• Default Rule: By default, no credentials are allowed to be carried

• Core Values:

  Value	Description
  true	Allows cross-origin requests to carry credentials (Cookies, Authorization, TLS client certificates, etc.)
  （Header not returned）	Default behavior, prohibits carrying any credentials

5. Access-Control-Expose-Headers (Controls which response headers are allowed to be read)

• Default Rule: Only basic response headers within the CORS whitelist are allowed to be read by JS

• Core Values:

  Value	Description
  X-Request-Id/Server	Allows specified non-basic response headers to be read by JS
  Content-Length	Allows the resource content length response header to be read by JS
  X-A, X-B	Allows multiple response headers to be read, separated by English commas

6. Access-Control-Max-Age (Controls the cache time for preflight request results)

• Default Rule: By default, preflight request results are not cached, and a preflight request is required for every complex cross-domain request

• Core Values:

  Value	Description
  0	Do not cache preflight request results, verification is required every time
  600	Cache preflight results for 10 minutes, reducing duplicate requests
  86400	Cache preflight results for 24 hours (browsers may have their own upper limits, subject to actual browser behavior)

III. COOP & COEP Cross-Origin Isolation Policies

COOP (Cross-Origin-Opener-Policy) and COEP (Cross-Origin-Embedder-Policy) are both response headers configured on HTML documents, not on resources/interfaces. They work together to achieve cross-origin isolation for pages, reducing security risks such as side-channel attacks and page hijacking, and also unlocking the use of some high-privilege Web APIs.

1. COOP (Cross-Origin-Opener-Policy) Cross-Origin Opener Policy

The core function of COOP is to control the browser window context (browsing context) sharing permissions between different pages. It primarily affects the relationship between a page opened via window.open() and the original page, and whether they are allowed to access the window.opener property. By isolating pages, it reduces the risk of information leakage and hijacking.

After enabling COOP, the browser will force cross-origin pages into different processes based on the configuration, prohibiting the sharing of execution environments. Its core values and behaviors are as follows:

Table

2. COEP (Cross-Origin-Embedder-Policy)

The core function of COEP is to control the page's permission to load and use cross-origin resources. After enabling it, all embedded cross-origin resources on the page must be authorized through CORP or CORS. Otherwise, after the resource request is successful, the browser will prevent the page from using the resource (it does not intercept the resource request).

Its core values and behaviors are as follows. The core is to ensure that the page can only use trusted cross-origin resources:

Table

3. Key Enforcement Rules for COOP & COEP

1. Scope of Enforcement: The browser only checks and enforces COOP/COEP configurations when the page is loaded as a document, including: top-level page navigation (opened directly from the address bar), documents loaded in an iframe, and pop-up windows opened by window.open(). For non-document resources such as images, audio, video, and scripts, the COOP/COEP configuration in their response headers is invalid, and the browser will not perform any checks.
2. Enforcement Timing: COOP takes effect when the page is created / the window context is connected. COEP takes effect when the page attempts to use embedded cross-origin resources.

4. Combined Effect of COOP + COEP

When an HTML page is configured with both COOP and COEP, and all embedded cross-origin resources in the page meet the CORP/CORS authorization requirements, the browser will mark the page as cross-origin isolated.

Pages in this state can safely use some high-permission Web APIs, such as SharedArrayBuffer and high-precision timers (performance.now() without precision limitations). These APIs are only open to cross-origin isolated pages by default due to security risks.

IV. Complete Flowchart of Browser Security Model

Core Summary

1. Strategy Positioning Distinction: CORP manages **cross-origin access permissions for resources** (whether resources can be used), CORS manages **cross-origin invocation permissions for interfaces** (whether interfaces can be called, and how they can be called), COOP/COEP manages **cross-domain isolation rules for pages** (whether windows can be shared, and whether unauthorized cross-origin resources can be used);
2. Configuration Carrier Distinction: CORP and CORS are configured in the **response headers of resources/interfaces**, while COOP and COEP are configured in the **response headers of HTML documents**;
3. Practical Configuration Key Points: To read non-basic response headers across origins, configure Access-Control-Expose-Headers; to carry custom request headers, configure Access-Control-Allow-Headers; to unlock high-permission APIs, configure COOP+COEP simultaneously and meet cross-origin resource authorization requirements;
4. Scope of Effectiveness Distinction: COOP/COEP only takes effect for HTML documents and does not affect non-document resources (images, scripts, etc.), while CORP/CORS takes effect for both resources and interfaces.