SharedArrayBuffer is usually missing because the page is not cross-origin isolated. Check that crossOriginIsolated is true, then confirm COOP is same-origin, COEP is require-corp or credentialless, and no Permissions-Policy blocks the feature. Blocked embeds and duplicate headers are the usual hidden causes.
What the page needs
MDN states that features such as SharedArrayBuffer and unthrottled Performance.now() timers are only available if the document is cross-origin isolated. The conditions: COOP same-origin, COEP require-corp or credentialless, and the feature not blocked by Permissions-Policy for cross-origin-isolated.
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp
Debug checklist
- Test the flag. In the console, read
crossOriginIsolated. MDN says both Window and WorkerGlobalScope expose it. False means a condition is missing. - Read the real response headers of the top-level document, not an asset. Use the Network panel or
curl -sI. - Check COOP is exactly
same-origin. MDN namessame-originas the value that provides isolation, so test with it before trying others. - Check COEP is
require-corporcredentialless. - Look for duplicates. MDN says COEP set more than once, or with multiple tokens, is treated as
unsafe-none. A proxy plus an app can cause this. - Check workers. Workers expose their own
crossOriginIsolatedflag, so read it there too if a worker is where the failure shows. - Check Permissions-Policy for a rule that disables cross-origin-isolated.
Blocked embeds
After COEP is on, any cross-origin resource loaded in no-cors mode without a CORP header is blocked under require-corp. Typical victims: third-party images, fonts, analytics scripts and iframes. Fixes, in order of preference:
| Cause | Fix |
|---|---|
| Your own CDN asset | Add a Cross-Origin-Resource-Policy header allowing the page |
| Third party image or script | Use the crossorigin attribute if the vendor supports CORS |
| Vendor will not cooperate and logged-out content is fine | Use COEP credentialless |
| Embed not essential | Remove it from the isolated page |
Add report-to to COEP with a Reporting-Endpoints header, as MDN shows, so blocked URLs appear in reports instead of silently failing. For the difference between the two COEP values, see require-corp vs credentialless.
A common pattern: it works locally but not in production
Development servers often set the two headers directly, so isolation works on your machine. In production, a CDN, a load balancer or a static host may strip or override them, or serve the HTML from a different path than the one you configured. The fix is to compare the live response headers of the exact HTML document URL against your local ones, and then check every redirect hop that lands on it. A header set only on the final response will be missing if the browser was served a cached copy of an earlier version, so also test in a private window after deploying.
Popups
If the page opens an OAuth window, COOP same-origin will sever the reference. See which COOP value keeps popups working before deciding.
Safe feature detection
if (crossOriginIsolated) {
const buffer = new SharedArrayBuffer(16);
// use shared memory
} else {
// fall back to a regular ArrayBuffer
}
This is the pattern MDN shows. It keeps the page working where isolation is not available, such as an unsupported browser.
Quick check
Can I check isolation inside a worker?
Yes. MDN says WorkerGlobalScope exposes the same crossOriginIsolated property as Window.
Does COOP alone enable SharedArrayBuffer?
No. MDN lists COEP as the paired header.
Safeguard's SBOM and dependency scan show which third-party packages your front end loads, a good input for deciding which embeds survive COEP. Try the free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
