Update cross-origin resource access instructions

[ajayojha]

Clarified requirements for cross-origin isolation and resource embedding.

Related issues and pull requests

Fixes #42236

[github-actions]

Preview URLs

• /en-US/docs/Web/Security/Practical_implementation_guides/CORP

(comment last updated: 2025-12-08 11:43:02)

[hamishwillee]

Thanks @ajayojha

@chrisdavidmills You're marked as reviewer on this. IMO the fix to the stated problem is accurate. I think that is the least problem with this document though.

The document implies/indicates the vulnerability fixed by CORP is that attacked by spectre/meltdown. That is not true. The vulnerability was fixed by removing access to the performance.now and SharedArrayBuffer everywhere.
What CORP did was provide a mechanism to allow access to those APIs to be safely restored.

The doc mixes the idea of restricting access to image and scripts that would otherwise be allowed by no cors mode by default with this idea that you need CORP for cross origin isolation. They kind of are orthogonal.

The problem with all that is that when you get to this section on "To enable {{jsxref("SharedArrayBuffer")}} and {{domxref("Performance.now()") ..." it is dangling. It isn't clear why you need to do this, and it is implied that you have to serve the file as same-origin when cross-origin isolation doesn't care - it just wants to know that the serving site has specified that the file can be embedded in the given contexts.

We should probably split this conceptually into two - "what the server that is setting CORP should do" and "what the server that wants to access those APIs should do".

I'm not sure if we need to mention the cross-origin isolation stuff at all. Depends what the point of this security guide is supposed to be. Do you know?

I tried suggesting a bunch of fixes on this, but without deciding on ^^^ it keeps on unravelling on me.

[chrisdavidmills]

Thanks a lot, @ajayojha. Your changes look mostly good; I've got a few suggestions for improving the text further.

We do need to address the issue @hamishwillee brings up too. Are you interested in updating the doc further to help with that? We can certainly give you some guidance to help out.

To answer your question, @hamishwillee, the guide is supposed to be for helping users of the HTTP Observatory tool to fix their site so that it scores better on the Cross Origin Resource Policy test scores outlined at https://developer.mozilla.org/en-US/observatory/docs/tests_and_scoring (search for the "Cross Origin Resource Policy" heading to find them).

I don't know a great deal about CORP usage; I mostly copied this information from the original Observatory security team docs, back when we moved it over to MDN.

[ajayojha]

We do need to address the issue @hamishwillee brings up too. Are you interested in updating the doc further to help with that?

Thanks @chrisdavidmills, I am definitely interested in updating the document further to address the issue.

I will draft an updated structure and wording and share the proposed title and revised text here before pushing any changes.

[hamishwillee]

I don't know a great deal about CORP usage; I mostly copied this information from the original Observatory security team docs, back when we moved it over to MDN.

Both CORS and CORP allow a server to control what use is made of its resources, and are a statement that it is safe for some other site to use their resources safely

CORS primarily for programmatic access - e.g. fetch, and is a controlled relaxation of the single-origin rule (i.e. you can allow a particular site access). However it doesn't apply to some files, such as scripts and images.

CORP is designed for a server to control how its content might be embedded safely in other sites. In particular, it is for preventing same-origin access to resources such as images and scripts that are allowed by CORS. It mostly is used to restrict declarative access.

CORP is very much designed to patch this spectre hole where a document with a script or img tag can be loaded into a process controlled by the attacker. If you set same-origin for the CORP on your script this can't happen. If you set cross-origin on a script then it might happen - the COEP basically says that's OK if the CORP has been set - it means that the CORP site knows that the particular script isn't a concern if loaded into an attackers process.

Hope that helps.

Thanks both!