Vulnerabilities
CORP vs CORS for Embedding and Fetch Isolation
September 13, 2022
CORP vs CORS for embedding and fetch isolation is a deny-by-default versus allow-by-name split. Cross-Origin-Resource-Policy (same-origin or same-site) tells browsers to refuse this response as a cross-origin no-cors subresource — images, scripts, and fetches that would otherwise be opaque. CORS Access-Control-Allow-Origin is the opposite conversation: a named origin may read the body. You often want CORP on HTML and private APIs, and CORS only where a browser client on another origin must read JSON. COEP require-corp on a document then requires CORP or CORS on everything it embeds. RoastMyOpsec grades CORS wildcards on app-shaped responses. It does not score CORP today and it does not attempt Spectre-class tests.
The practical difference
CORP is a lock on being pulled in. CORS is a key for being read. A marketing homepage can set CORP same-origin so random sites cannot no-cors load your HTML as a mysterious subresource. A public widget JS file that others must <script src> cannot use CORP same-origin — that would break the embed. COEP is how an app opts into requiring CORP on its whole tree; brochure sites should not copy that from a lab.
See COOP vs COEP for isolation headers, and Timing-Allow-Origin vs CORS for RUM stopwatches.
How to choose based on the resource
HTML documents: CORP same-origin is a reasonable default with framing controls. Authenticated JSON: CORP same-origin plus CORS allowlist for the SPA origin only. CDN scripts meant for other sites: no CORP same-origin; use SRI. If you turned on COEP, every cross-origin asset needs CORP or CORS — that is why marketing GTM dies.
| Control | Question it answers | When it wins | Takeaway |
|---|---|---|---|
| CORP same-origin | May others no-cors load this? | HTML, private APIs, user images | Default lock |
| CORP same-site | Same, but sister hosts OK | www + static. on one eTLD+1 | If you actually share that way |
| CORS allowlist | May this origin read the body? | SPA calling api. | Named origins; see wildcard guide |
| COEP require-corp | Must every embed play along? | App isolation, not brochure GTM | See COOP vs COEP |
What the roast can see
Wildcard CORS is the finding. Missing CORP is not an automatic F. Confirm CORP at the CDN so HTML is not using the same header pack as a public widget script.
Common mistakes
The first mistake is CORP same-origin on a script other sites must load.
The second mistake is CORS * plus CORP same-origin on the same API (the messages fight).
The third mistake is COEP on www because a checklist said 'isolation.'
Free audit the URL you own
RoastMyOpsec is a defensive public-surface roast: headers, cookies, sensitive paths, and more — no exploit payloads. Start with the free audit, then open the vault if the blurred findings look expensive.
Free audit nowFAQ
- Is missing CORP a vulnerability?
- It is missing isolation, not an open API. Prioritize CORS wildcards, CSP, and framing. Add CORP on documents and private APIs when you can test embeds.
- Does RoastMyOpsec score CORP?
- Not as a free header gate. CORS wildcards in app mode are scored. Confirm CORP in staging.
- Do I need CORP if I have CORS?
- They answer different questions. CORS is read access. CORP is no-cors embedding. Many APIs want both: tight CORS and CORP same-origin.
Sources
Related guides
Vulnerabilities
CORS Credentials vs Wildcard OriginsVulnerabilities
CORS Wildcard vs Allowlist for Public APIsVulnerabilities
Timing-Allow-Origin vs CORS for Cross-Origin Telemetry