Cross-Origin Resource Policy Checker

Check the Cross-Origin-Resource-Policy on a resource and see whether it matches the way that resource is actually embedded.

Passive public check

a2z.tools reads publicly visible information from the address you enter. It is a read-only request - nothing is submitted, changed or probed.

Address to check Reads the response headers of a public URL. Point it at a resource, not just a domain.

CORP is about resources, not pages

Cross-Origin-Resource-Policy lets a resource state who is allowed to embed it. It is the header an image, font, script or API response sends to say “only my own origin may pull me into a document”.

That makes it different from the other cross-origin headers, and it changes how to read a result here. On an HTML page, a missing CORP header means very little - pages are not usually embedded as subresources, so there is not much to protect. On an image, a font, or an authenticated API response, it matters considerably more. Point this tool at the URL of a resource, not just at a domain, or you will be assessing the home page and learning nothing about your assets.

What it protects against

Ordinarily a cross-origin site can embed your image but not read its pixels. Under Spectre-class speculative execution attacks that boundary weakened: a resource pulled into another site's process could, in some circumstances, be read rather than merely displayed. CORP lets a resource refuse to be pulled into that process at all, which is a stronger guarantee than the same-origin policy alone provides.

It also stops straightforward hotlinking of private assets, though that is a side benefit rather than the design goal.

The three values

same-origin - only pages from this exact origin may embed it. The right default for anything private.
same-site - any subdomain of the same site may embed it. Useful when your own subdomains need the asset; worth confirming you control every subdomain.
cross-origin - anyone may embed it. Necessary and correct for public CDN assets.

cross-origin is not a misconfiguration

This is the point most tools get wrong. If you serve fonts, images or scripts from a CDN for other sites to use, cross-origin is the setting you want - and you need it explicitly, because any page with COEP: require-corp will refuse to load your asset without it. Marking it as a weakness would be telling people to break their own CDN.

So this tool reports cross-origin as informational and asks the only question that matters: is this resource meant to be public? If yes, the setting is right. If no, change it.

Where to apply it

The practical approach is a default of same-origin across your responses, with cross-origin applied deliberately to the paths that serve public assets. Set it at the web server or CDN rather than per application route - it is a static header and application code is the wrong place to remember it.

Related: Cross-Origin-Embedder-Policy Checker for the header that makes CORP a requirement, and Cross-Origin Policy Generator to produce a consistent set.

Frequently asked questions

I checked my domain and got very little. Why?

Because you checked an HTML page. CORP is a resource header, and its absence on a page is close to meaningless. Enter the full URL of an image, font, script or API response to get a useful answer.

Is cross-origin a security problem?

Not by itself. It is the correct setting for a public CDN asset and is required for such assets to work on pages that set COEP. It is only wrong if the resource was not meant to be public, which is a question about the resource rather than the header.

How is CORP different from CORS?

CORS governs whether script may READ a cross-origin response. CORP governs whether the resource may be EMBEDDED at all, and it applies to resources loaded as subresources rather than to fetch and XHR. They solve different problems and are often both needed.

Does CORP replace a hotlinking rule?

It overlaps with one, but it is enforced by the browser rather than by your server, and it is aimed at process isolation rather than bandwidth. Referer-based hotlink rules are still a separate thing.

References

Related tools

What this tool can and cannot tell you. It reports the configuration a site exposes to an ordinary visitor. It does not log in, submit anything, or test for vulnerabilities, so a passing result means the public configuration looked correct at the moment of the check - not that the site is secure.

Security guidance here follows current published sources - OWASP, MDN, the relevant RFCs, NIST, CISA, FIRST and MITRE - which are linked beside the specific claims they support.