In one paragraph
A missing Cross-Origin-Resource-Policy header leaves a response without an explicit CORP restriction on its use in no-cors browser loads. This is optional hardening, not proof that another website can read private data. Choose same-origin, same-site, or cross-origin according to who legitimately embeds each resource, and test actual resource requests before applying a global policy.
Why it matters
Browsers allow some cross-origin resource loading without giving the embedding page ordinary JavaScript access to the response. Images and classic scripts are familiar examples. CORP lets a response limit its availability in relevant no-cors loading contexts, helping reduce certain cross-origin information-exposure risks.
CORP is not a server-side access check. The request may still reach the server, and non-browser clients are not prevented from downloading a public file. Protect private data with authentication and authorisation independently of this header.
It is also not interchangeable with CORS. CORS controls approved browser sharing for CORS-mode requests; CORP applies to relevant no-cors use. A valid CORS-enabled load can be handled differently from an ordinary no-cors embed. Avoid describing CORP as a blanket ban on every cross-origin fetch or iframe.
How WebAuditOS evaluates this finding
The supplied rule checks the header on HTML responses only. Presence of any value passes; absence produces an informational warning. Non-HTML or unavailable responses are not graded. A declared cross-origin value passes despite intentionally allowing broad use.
The rule does not assess the asset and data responses where this control can be particularly relevant. A passing homepage says nothing about a private download, and an absent header on a public information page may be low priority. Validate the resource and request context rather than optimising only the report colour.
How to fix it
- Inventory responses by intended consumers. Separate application-only resources, assets shared across your own hosts, public CDN files, customer embeds, and authenticated data. Do not assume one policy suits them all.
- Use same-origin when relevant no-cors consumers should be limited to the exact origin:
Cross-Origin-Resource-Policy: same-originA different hostname, scheme, or port can be a different origin even within your organisation. Confirm how the application loads each resource.
- Consider same-site for resources deliberately shared within your site boundary, and cross-origin for intentionally public cross-origin use. A company-owned CDN on an unrelated registrable domain is not automatically same-site.
- Apply the setting at the layer serving the resource. For example, in nginx:
add_header Cross-Origin-Resource-Policy "same-origin" always;Scope the rule appropriately. A global same-origin setting applied to a public asset bucket can break external consumers. Framework middleware may already emit a default, so inspect the final response before adding duplicates.
- Verify request mode as well as response headers. Test actual image, script, and fetch use from intended and unintended origins. CORS-enabled resources need their own accurate CORS configuration; adding CORP does not authorise CORS sharing.
- If deploying COEP: require-corp on a consuming page, inventory its cross-origin dependencies. Those resources must satisfy the applicable CORP or CORS requirements. This is a separate integration decision from clearing an informational HTML-header warning.
- Test browser and non-browser consumers separately. Link-preview crawlers fetching server-side do not normally enforce browser CORP, but bot controls, authentication, and content delivery can still prevent their requests. Do not treat a working preview as proof that browser embedding remains functional.
- Rescan the HTML finding and maintain separate checks for important assets and private resources. Confirm authorisation with unauthenticated requests regardless of header status.
What the fix can break
An overly narrow policy can leave partner logos, customer widgets, or application assets unusable in no-cors contexts. Their servers may still record successful requests, making the failure look confusing.
A global security middleware change can introduce the header on routes whose external users were never inventoried. Use narrowly scoped public-asset exceptions where legitimate, not a permissive value everywhere by default.
Same-site allows a wider boundary than same-origin. If sibling hosts include untrusted user content, that wider scope may not match your security goals. Evaluate who controls the permitted contexts rather than assuming all subdomains are equally trusted.
Questions
Is CORP a replacement for authentication?
No. It is browser-side response-use control, not a guarantee that requests cannot reach or retrieve a resource. Enforce private access server-side.
Does same-site mean every domain owned by our company?
No. Site boundaries are not corporate ownership boundaries. A separate CDN domain can be cross-site even when you operate both.
Why does cross-origin pass the check?
The supplied rule tests presence, not restrictive strength. That value can be correct for public resources but does not mean private resources are protected.
Where should I go next?
Review COOP and nosniff. Each addresses a separate browser behaviour.