What Does “Cross-Origin-Resource-Policy Header Missing” Mean?

How Scanners Detect This Finding

CORP scanners look at resource responses and determine whether a valid Cross-Origin-Resource-Policy value is present. Automated guidance often recommends same-origin, but that value is not automatically correct for a CDN, public image host, shared font service, or other intentionally reusable resource.

Treat the finding as a resource-classification task. Security comes from expressing the intended sharing model accurately, not from maximizing restriction without regard to consumers.

Practical Security Scenario

A private resource that is never meant to be consumed by another origin can declare same-origin, strengthening the browser’s handling of no-cors cross-origin loads. By contrast, a public CDN image used by many unrelated sites must remain cross-origin loadable; marking it same-origin would turn a security hardening change into an outage.

The risk model also changes when COEP is enabled. A COEP-protected document may require its cross-origin resources to opt in through CORP or CORS. CORP then becomes part of a coordinated isolation architecture rather than a standalone header.

Where This Control Should Be Applied

Set CORP on the resources for which you can define a clear ownership and sharing boundary. User-specific or origin-private resources commonly fit same-origin; resources intentionally shared across related subdomains may fit same-site; broadly reusable public resources may need cross-origin.

Do not use CORP as an access-control substitute. Network clients can still make requests, and sensitive APIs still require authentication and authorization. CORP is a browser resource-use policy layered on top of those application controls.

Why CORP Exists

The Same-Origin Policy does not prevent every cross-origin resource from being requested. Images, scripts, styles and other resources can be loaded in contexts where the requester does not get normal CORS-readable access. Side channels and cross-site inclusion patterns can still create information exposure opportunities.

CORP lets the resource owner opt into a clearer boundary. MDN describes it as protection against certain cross-origin requests and notes its role in reducing speculative side-channel attacks such as Spectre as well as cross-site script inclusion risks.

CORP is applied to the resource response, not as a general API authorization control. A private JSON endpoint still requires authentication and authorization. A public CDN asset may deliberately need cross-origin rather than a restrictive value.

CORP Values

• same-origin: Only the same scheme, host, and port may load the resource in the covered no-cors context. Strongest general restriction.
• same-site: Allows origins that are considered the same site. This is broader than same-origin.
• cross-origin: Explicitly allows cross-origin loading; useful for public resources and for resources that must be embeddable under COEP.
• No-cors focus: CORP primarily affects no-cors requests. CORS-enabled fetches use the CORS protocol for cross-origin permission.
• COEP relationship: Pages using COEP require cross-origin resources to grant appropriate permission through CORP or CORS, depending on request mode.

Related Ammune guides: Cross-Origin-Embedder-Policy Header Missing, Cross-Origin-Opener-Policy Header Missing, and CORS Misconfiguration.

Choose CORP Per Resource

For a private same-origin application resource:

Cross-Origin-Resource-Policy: same-origin

# For a deliberately public CDN asset:
Cross-Origin-Resource-Policy: cross-origin

Common Remediation Mistakes

• Setting same-origin on all CDN content and breaking legitimate cross-origin consumers.
• Using cross-origin on sensitive user-specific resources simply to make an embedding error disappear.
• Confusing same-site with same-origin; same-site is intentionally broader.
• Assuming CORP blocks the network request itself. The browser policy mainly prevents exposing/using the response body in covered contexts.
• Enabling COEP on a page without ensuring its cross-origin dependencies send compatible CORP or CORS headers.
• Ignoring browser-specific compatibility issues for specialized resource types such as PDFs.

How to Fix a Missing CORP Header

1. Classify resources by intended audience. Separate private/user-specific responses, first-party shared assets, and public cross-origin resources. CORP should describe the sharing boundary of each resource class, not simply the hostname.

2. Use same-origin for origin-private resources. Choose same-origin when a resource should only be loadable by documents from the exact same scheme, host, and port.

3. Use same-site only for deliberate same-site sharing. This can support assets shared across sibling subdomains under the same site, but it is a broader trust boundary than same-origin and should be chosen intentionally.

4. Use cross-origin for truly public embeddable resources. If a CDN asset, widget, image, or other resource is intentionally available to unrelated origins, cross-origin communicates that policy and can be necessary when an embedding page enforces COEP.

5. Test real embedding and browser behavior. Exercise images, scripts, fonts, PDFs, iframes, and other affected resources from their real consumers. Also coordinate CORP with COEP/CORS rather than assuming one header replaces the others.

Configuration Examples

CORP is best applied per resource class. A blanket edge rule is safe only when every response behind it has the same sharing requirement. Static assets, authenticated HTML, API responses, downloads, and public CDN content often need different policies.

add_header Cross-Origin-Resource-Policy "same-origin" always;
# Use location blocks to set cross-origin only for intentionally public assets.

Header always set Cross-Origin-Resource-Policy "same-origin"

Classify responses and set CORP at the layer that knows whether the resource is private, same-site shared, or public.

How to Test the Fix

1. Inventory which resources are consumed from other origins before enabling a restrictive policy.
2. Inspect resource responses—not only HTML documents—for the expected CORP value.
3. Test CDN assets, fonts, images, downloads, workers, and any resources loaded by a COEP-enabled page.
4. Verify that authenticated/private resources remain protected by application authorization regardless of CORP.
5. Re-run the site-isolation scanner and diagnose COEP/COOP separately if they remain missing.

Test from both same-origin and cross-origin pages using the same request mode the application actually uses. Browser developer tools can show blocked resource loads. Pay particular attention to PDFs and other complex embedded content because browser-specific compatibility behavior can differ.

How to Think About Severity

ZAP rates 90004-1 as Low and the rule is beta. A missing CORP header is usually a defense-in-depth/site-isolation gap rather than a standalone compromise. Risk increases when responses contain private or user-specific information that should never participate in cross-site resource loads.

CORP also becomes more operationally important when COEP is enabled on consuming documents, because those documents may require cross-origin resources to opt in through CORP or CORS. Treat the three controls as related but distinct policies.

How Ammune Fits

CORP controls how browsers expose resource bodies across origins in specific request modes. Ammune analyzes the API requests and responses themselves, including discovery, sensitive-data exposure, and abnormal usage patterns.

A resource can have a correct CORP header and still be returned to an unauthorized authenticated caller through a direct API request. Browser isolation does not replace server-side authorization or runtime monitoring.

Production Remediation Checklist

• Classify each resource as private same-origin, same-site shared, or intentionally public cross-origin.
• Use same-origin for resources that should not be loaded by sibling or external sites.
• Use same-site only when sibling-origin sharing is an explicit requirement.
• Use cross-origin for resources intentionally embeddable by unrelated origins.
• Avoid applying one blanket CORP value to unrelated resource classes without review.
• Test fonts, images, scripts, iframes, downloads, and PDFs used by real consumers.
• Review COEP requirements on documents that embed these resources.
• Remember that CORS still governs requests made in CORS mode.
• Re-run ZAP 90004-1 and review COEP/COOP findings separately.
• Document the sharing boundary so future CDN or subdomain changes do not widen it accidentally.

Frequently Asked Questions

Primary References