CORP and COEP Headers: Control Who Loads Your Files

Short answer: Cross-Origin-Resource-Policy (CORP) is a response header that tells browsers which other websites may load a file from you, for example an image, script or document. Cross-Origin-Embedder-Policy (COEP) is a header on your own pages that requires every file they embed from other sites to agree to be embedded. Most small websites do not need COEP. CORP is a simple extra protection for private or sensitive files, and it is also a useful, but partial, brake on hotlinking in browsers.

Where these headers fit

Browsers separate websites from each other using the same-origin policy. A page on one site cannot read the data of a page on another. But the web was built so that sites can freely display each other’s resources: an image, a script, a font or a stylesheet from another domain loads without much question. That openness is useful, and it is also a risk. In some situations, a malicious page can load your file, even though it cannot read it directly, and then use side channels in the browser to learn something about it.

CORP and COEP are part of a family of “cross-origin” headers that give you control over this. They sit alongside the others described in HTTP security headers explained, and work best together with the opener policy in Cross-Origin-Opener-Policy and the data-sharing rules in CORS.

Cross-Origin-Resource-Policy

CORP is set on the resource, such as an image or a script, by the server that sends it. It has three values.

same-origin: only pages from exactly the same origin, meaning the same scheme, host and port, may load the file.
same-site: pages from the same registrable site, for example your main site and your subdomains, may load it.
cross-origin: any website may load it. This is what you want for a public image or script that other sites are meant to use.

If a page on another site tries to load a file that is protected by a stricter value, the browser blocks the request. Note what CORP controls: loads that come from other pages, such as an image tag, script tag or fetch in no-cors mode. It does not affect a person who types the address in the browser, and it does not stop tools like curl that do not follow browser rules. It is a defence for visitors’ browsers, not an access control system. For real privacy, you still need authentication, as in protecting private downloads.

Cross-Origin-Embedder-Policy

COEP is set on your page and sets the rule for what that page may embed. Its values are:

unsafe-none: the default. The page can embed cross-origin resources freely.
require-corp: the page may load cross-origin resources only if they say, through a CORP header or through CORS, that embedding is permitted.
credentialless: the page may load cross-origin resources, but without sending cookies or other credentials with those requests, which removes the need for each provider to opt in.

The main reason to use COEP is cross-origin isolation. When a page sets COEP to require-corp or credentialless together with a Cross-Origin-Opener-Policy of same-origin, the browser can treat it as isolated. Isolation unlocks powerful features, including shared memory in the browser and more precise timers, that are otherwise restricted because of side-channel attacks. Applications such as in-browser editors, image tools or games sometimes need them. An ordinary business website, blog or shop does not.

Do you need them?

A typical brochure site or blog. You do not need COEP. Adding it would only risk breaking embeds. CORP is optional.
A shop or site with a login area. Consider CORP for private files such as invoices, user uploads and anything behind a login, along with the other protections.
A site that provides files to other sites, for example a CDN, a font host or an image service. Use cross-origin deliberately, so that your files keep working for the sites that use them.
A web application that needs cross-origin isolation. Plan COEP and COOP carefully, with developer help.

If you are unsure, start with the bigger wins. The guide to adding security headers on Apache, Nginx, WordPress and CDNs lists the more common headers to configure first.

CORP and hotlinking

Hotlinking happens when another site displays your image by pointing straight at your server, using your bandwidth. A CORP value of same-origin or same-site on images causes compatible browsers to refuse to display them on other sites, so it helps against casual hotlinking. But it is not a complete solution. It only works for visitors whose browsers support it, it does nothing against a server that fetches the image and re-hosts it, and it also blocks legitimate uses, such as an image used in a partner’s page or in a link preview. For the main techniques, see hotlink protection.

What can go wrong

Public images stop appearing elsewhere. A strict CORP value on a file that others are meant to display, such as a logo used by partners, breaks it.
Embeds break under COEP. With require-corp, any third-party image, frame, script or font that does not send the right header is blocked. Typical examples are maps, video players, analytics and advertising scripts.
Fonts and fetches behave differently. Resources requested with CORS follow the CORS rules, and CORP applies to no-cors requests. Mixing them without a plan creates confusing failures.
Cached or proxied responses. A CDN or cache may send a different header from your server, or strip it. Test what visitors really receive.

How to set them

Headers are set in the web server or CDN configuration. In an Nginx configuration, the line that applies a CORP value to a folder of private files has the form add_header Cross-Origin-Resource-Policy "same-origin" always;. On Apache you use the equivalent directive from the headers module, and many CDNs and security plugins have a field for custom headers. As with every header, apply the strict value only to the paths that need it, such as a private uploads folder, and use cross-origin for files meant for sharing.

A small example: a business keeps customer invoices in a folder that is only reachable after login. The owner adds a strict CORP value for that folder, so that another website cannot embed or probe those files through the visitor’s browser, while the login check remains the real barrier. The public product photos are left as they were, because partners display them. That split, strict for private paths and open for shared ones, is the most common sensible use.

Test safely

Use the report-only mode for COEP. A separate header, Cross-Origin-Embedder-Policy-Report-Only, lets the browser report what would be blocked without blocking it. Collect reports for a while before you enforce.
Set CORP on a small group of files first, and open the site and any partner pages that use them.
Use the developer tools. The console and the Network tab name blocked requests and the policy that blocked them.
Test on several browsers and on a phone, and clear caches and CDN layers after each change.
Keep a rollback. Know how to remove the header quickly if something important breaks.

Keep in mind that browsers are the ones that enforce these headers, and they evolve. Support and defaults change over time, so check current browser documentation before relying on a specific behaviour, and recheck your setup after major browser or CDN changes. Treat the headers as a layer of defence in depth, tested regularly, instead of a setting you apply once and forget.

How Site AI Audit helps

Site AI Audit does not test CORP or COEP on individual files. It checks the security headers on your pages, HTTPS and its redirect, SSL certificate and exposed software versions, in addition to SEO, speed and e-mail authentication. Re-checking after a configuration change shows whether your header setup stays consistent. The first check is free, covers up to 50 pages and needs no sign-up. You can run a free check of your website or see the plans for weekly monitoring.

The bottom line

CORP lets a server say who may load its files, and COEP lets a page demand that everything it embeds has agreed to be embedded. For most small sites, the practical step is modest: leave COEP alone, consider a stricter CORP value for private resources, mark intentionally public files as cross-origin, and test every change in report mode or on a small set of files first. Use these headers as one layer among many, not as a replacement for authentication.

FAQ

Is CORP the same as CORS?

No. CORS lets a server allow other sites to read a response. CORP controls whether other sites may load a resource at all in no-cors situations, such as an image or script tag. They solve related but different problems.

Do I need COEP for my WordPress site?

Almost certainly not. COEP is needed mainly for cross-origin isolation in advanced web applications. On a normal WordPress site it may break maps, videos, ads and analytics.

What happens if I set CORP to same-origin on all images?

Other websites can no longer display them in compatible browsers, which stops casual hotlinking but also blocks partners, link previews and any intended use elsewhere. Apply it selectively.

Will these headers improve my SEO or speed?

No. They are security controls. A wrong setting can even hurt, for example by breaking images that other sites or tools should display, so test before enforcing.

Does CORP protect files from direct download?

No. A visitor can still open the address directly, and a script outside a browser can still fetch it. Use login checks and server-side permission rules for files that must stay private.