No Cross-Origin-Resource-Policy restricts these resources
Updated
What this check looks for
Other sites may load this page's resources directly. For a public site that is normal; for private content it is worth restricting.
Why it matters
Nothing is wrong for a public page. It matters for anything user-specific: without this header another site can pull the resource into its own page and read side channels from it.
When the check passes, your report says: “A Cross-Origin-Resource-Policy restricts who may load these resources”.
What it costs your score
This check never deducts. It reports a fact — or reports that something could not be verified — and is shown on the report without moving the score.
- Severity
- info
- Default confidence
- confirmed
- Status when triggered
- info
- Deduction
- 0 points
- Family cap
- none
- Category
- Web security
- Module
- Web security headers
- Fix owned by
- user
- In the ruleset since
- 2026.09
How to fix it
Send Cross-Origin-Resource-Policy: same-origin on pages and user-specific resources, and choose wider values only where other origins must load them.
Without it, any site can pull your resources into its own page and probe them.
Send
same-originon HTML pages and on anything that depends on the visitor's session.Use
same-siteon asset hosts that only your own subdomains load from.Use
cross-originonly on assets meant to be embedded by other sites, and keep user-specific data off those hosts.Load each page with the browser console open afterwards. Chrome reports a resource this header blocked as
ERR_BLOCKED_BY_RESPONSE.
How to confirm it worked
curl -sSI https://‹host›/ | grep -i cross-origin-resource-policy
A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.
Technical detail
‹detail›
same-origin restricts a resource to your own origin; same-site allows your subdomains; cross-origin explicitly opens it up, which is what a CDN asset or a public API should say — it is a valid value, but it restricts nothing, so this check reports it exactly as it reports a missing header. A value browsers do not recognise is ignored and the resource stays open to every site, so it is reported the same way. The value is compared exactly, so Same-Origin is unrecognised, and a header sent twice reaches the browser as a list it cannot read as one policy, which it ignores too. This is the header a Cross-Origin-Embedder-Policy: require-corp page requires from every subresource it loads.
Browsers enforce it on the requests another page makes without CORS: an <img>, <script>, <video> or <link> pointing at your server. With same-origin, a page on any other origin that tries to load the resource gets a network error. That matters most for responses that change with the visitor's cookies — an avatar, an account-specific file, a JSON endpoint — because a resource pulled into someone else's page can be probed through its size, its timing or its decoding errors, and in a browser without full site isolation it can land in the attacking page's memory, where Spectre-class attacks read it.
On the HTML page this scan read, the header mostly states intent; its real work is on the resources your pages and API serve. Our security headers generator writes same-origin, which is right for the page and for anything only your own origin loads. Check who loads from a host before applying the same value to it: a static. or media subdomain that www loads from is a different origin and needs same-site, and an asset other sites are meant to embed needs cross-origin — chosen deliberately, because it opens the resource to everyone.
Standards and references
Test this on your domain
Run the check that produces this finding, on its own, against any domain.