Cross-Origin-Embedder-Policy: require-corp and credentialless
Cross-Origin-Embedder-Policy makes your document refuse cross-origin subresources that have not explicitly opted in, which is the second half of turning on cross-origin isolation.
At a glance
- Direction
- Response only, on a document or worker response.
- Defined in
- The HTML standard (WHATWG)
- When absent
- unsafe-none. Cross-origin resources load normally and the document is not isolated.
- Values
- unsafe-none (default), require-corp, credentialless
- What require-corp demands
- Every cross-origin subresource sends Cross-Origin-Resource-Policy or passes a CORS check.
- Unlocks
- SharedArrayBuffer and high resolution timers, when paired with COOP same-origin
- In the headers checker
- Shown in the raw response header table. It is not one of the graded headers.
In detail
The require-corp value inverts the usual default. Instead of any site being able to embed any image, script or font, every cross-origin subresource has to say yes explicitly: either it carries a Cross-Origin-Resource-Policy header that permits your origin, or the request is made with CORS and the response passes the check. Anything that does neither fails to load, and the failure appears as a blocked request rather than a CORS message.
The credentialless value is the pragmatic middle ground. Cross-origin no-cors requests are allowed again but are sent without cookies or other credentials, so the resource comes back in its public form. That works for public images and fonts and fails for anything depending on the visitor's session with the third party, which is exactly the class of resource the isolation model wants to keep out.
The reason to accept that cost is cross-origin isolation. Browsers withdrew SharedArrayBuffer and precise performance timers after speculative execution attacks, and the way to get them back is a document that has proven no cross-origin content shares its process. This header is the half of that proof concerned with what the document pulls in; the opener policy handles what it stays connected to.
Roll it out by auditing subresources first. Every third party image, font, script and iframe on the page needs checking, and the ones you do not control need either a resource policy header from their operator or a switch to CORS loading. On an established site that is a project, not a one line change.
Examples
Cross-Origin-Embedder-Policy: require-corpCross-Origin-Embedder-Policy: credentiallessRequests to other origins are still made but stripped of credentials, so a signed-in avatar from another site comes back anonymous or not at all.
<img src="https://cdn.example.net/logo.png" crossorigin="anonymous" alt="Logo">This only works if the asset host answers with Access-Control-Allow-Origin. Otherwise it has to send Cross-Origin-Resource-Policy: cross-origin instead.
Things that catch people out
- Enabling require-corp usually breaks embedded video players, map widgets and advertisement frames on the first deploy, because none of them send a resource policy by default.
- The document also needs Cross-Origin-Opener-Policy: same-origin. This header alone gives you all of the breakage and none of the isolation benefit.
- Workers inherit the policy from the document that created them, so a worker loading an uncooperative script fails for the same reason the page would.
Try it: HTTP Headers Checker
Check a live URL or paste headers you already have. It grades six security headers from A+ to F and lists every other header the response returned.
HTTP Headers Checker
LOCAL · Browser-OnlyView HTTP response headers for any URL
Enter any website URL to fetch and analyze its HTTP response headers. We'll automatically add https:// if needed.
Why Check Security Headers?
Security headers protect your website against common attacks like XSS, clickjacking, and MIME sniffing. They're set by your web server and cost nothing to implement. Missing security headers are one of the most common findings in security audits.
Related HTTP headers
All http headers →Cross-Origin-Opener-Policy: isolating your browsing context
What COOP severs between your page and the windows it opens, how same-origin differs from same-origin-allow-popups, and its part in cross-origin isolation.
Cross-Origin-Resource-Policy: who may embed this response
How CORP lets a response refuse to be embedded by other sites, how same-site differs from same-origin, and why asset hosts have to send cross-origin.
Access-Control-Allow-Origin: who may read this response
How the allow origin header is matched, why a wildcard fails with credentials, why it takes only one origin, and why Vary: Origin is mandatory when you echo.
Permissions-Policy: turning browser features off by default
How Permissions-Policy allowlists are written, the empty parentheses that disable a feature, and how the syntax differs from the Feature-Policy header.
Clear-Site-Data: wiping browser state on logout
How Clear-Site-Data clears cookies, storage and caches for your origin, which directives are safe on a logout response, and where support is uneven.
Reporting-Endpoints: where browser reports are sent
How Reporting-Endpoints names collectors for CSP violations and deprecation warnings, how it differs from the older Report-To header, and what arrives.
Tools for this
- HTTP Headers Checker Free online HTTP headers checker - view HTTP response headers for any URL
- HTTP Request Builder Free online HTTP request builder - build and test HTTP requests with custom headers and body