Cross-Origin Policy Checker
Check Cross-Origin-Opener-Policy (COOP), Cross-Origin-Embedder-Policy (COEP), and Cross-Origin-Resource-Policy (CORP) headers. These headers enable browser isolation features required for SharedArrayBuffer and high-resolution timers. Get a security score and setup guidance.
How to Use Cross-Origin Policy Checker
- 1Enter a URL to check cross-origin isolation headers.
- 2COOP, COEP, and CORP headers are fetched and analyzed.
- 3Each header value is explained with security implications.
- 4Cross-origin isolation status and recommendations are shown.
ZenovayAnalytics
Analytics without the cookie banner.
- Real-time visitor tracking
- Privacy-first, no cookie banner
- Set up in two minutes
Related Tools
Password Generator
Generate strong, random passwords with customizable length, characters, and complexity.Password Strength Checker
Check how strong your password is. Get an estimated crack time and improvement suggestions.HMAC Generator
Generate HMAC signatures using SHA-256, SHA-384, or SHA-512 with the Web Crypto API.AES Encryption/Decryption
Encrypt and decrypt text using AES-GCM with PBKDF2 key derivation. Runs entirely in your browser.Frequently Asked Questions
What are COOP, COEP, and CORP headers?▾
These three headers work together to enable cross-origin isolation in browsers: (1) Cross-Origin-Opener-Policy (COOP) — controls whether your page can share a browsing context group with cross-origin popups; (2) Cross-Origin-Embedder-Policy (COEP) — requires all resources loaded by your page to have explicit cross-origin permission; (3) Cross-Origin-Resource-Policy (CORP) — controls who can load a specific resource. Together they prevent Spectre-like side-channel attacks.
What is cross-origin isolation and why do I need it?▾
Cross-origin isolation is a browser security state that enables high-resolution timers (performance.now()), SharedArrayBuffer, and WASM threads. These were disabled after the Spectre vulnerability was discovered because they could be exploited for timing attacks. A page becomes cross-origin isolated when it sets both COOP: same-origin AND COEP: require-corp (or credentialless). Without cross-origin isolation, high-performance web apps (WebAssembly, audio worklets, parallel computation) are limited.
What is the difference between require-corp and credentialless for COEP?▾
COEP: require-corp requires every cross-origin resource to explicitly opt in via a CORS header or Cross-Origin-Resource-Policy header. This is strict but breaking — third-party resources that don't have these headers will fail to load. COEP: credentialless (newer) loads cross-origin resources without sending credentials (cookies, client certificates), allowing them to load without CORS/CORP headers but stripping their authentication context. Credentialless is easier to deploy but requires browser support (Chrome 96+, Firefox 119+).
How do I deploy COOP without breaking OAuth and SSO?▾
OAuth flows use popup windows that need to communicate back to the opener window. With COOP: same-origin, this communication via window.opener is blocked. Solutions: (1) Use COOP: same-origin-allow-popups as an intermediate step. (2) Use postMessage() instead of window.opener for OAuth callback communication (most modern OAuth libraries do this). (3) If your OAuth provider opens a popup, ensure they also set COOP on their domain. Many providers (Google, GitHub) support this.
What is Cross-Origin-Resource-Policy (CORP) for?▾
CORP prevents other websites from embedding your private resources via <img>, <script>, or <iframe>. Without CORP, any website can load your authenticated image at yourapp.com/user/avatar.png and learn information from it (e.g., whether a user is logged in, via cross-origin image probing). Set CORP: same-origin on private user data resources. Set CORP: cross-origin on public CDN assets that need to be embedded anywhere.