Microphone in Cross-Origin iframe

What you’ll learn

1. 01What Actually Happens When a Microphone Runs Inside a Cross-Origin iframe?Welcome. This course explores what actually happens when a microphone runs inside a cross-origin iframe. If you build web recording widgets, embed communication tools, or integrate third-party video, you have felt the tension between delivering functionality and respecting user privacy. Today we unpack that tension from the browser's perspective. We will look at how the same-origin policy isolates frames, how Permissions Policy gates audio input, and how the allow attribute and HTTP headers combine to delegate microphone access. By the end you will understand the full delegation chain and the security model that controls it. Let's begin with the browser security model for embedded media.1 min
2. 02The Browser Security Model for Embedded MediaLet's unpack the browser security model that governs embedded media. By default, the same-origin policy isolates cross-origin iframes, blocking direct DOM access and preventing a parent page from reaching into a framed document. This is your first layer of defense. But isolation alone doesn't control access to powerful features like the microphone. That's where Permissions Policy, previously known as Feature Policy, comes in. The simplest way to delegate microphone access to an iframe is the allow attribute. The syntax is straightforward: allow equals microphone, and if you need both, allow equals microphone semicolon camera. However, delegation alone is not enough. Even with the correct allow attribute, getUserMedia requires a user gesture, what the spec calls transient activation. The browser will not prompt for permission unless the call is tied to a click or a tap inside the iframe. Finally, when the user grants permission, the top-level browsing context stores that persistent grant, scoped strictly to the iframe's origin. This means the parent page never holds the media handle. Next, we'll look at Permissions Policy: The Gatekeeper.2 min
3. 03Permissions Policy: The GatekeeperNow, let's look at the mechanism that actually enforces all this: Permissions Policy. Think of it as the gatekeeper. It controls feature delegation, and it's a separate layer from the Permissions API query you might use to check state. Here's the critical default: the allowlist for microphone is set to 'self'. That means any cross-origin iframe is blocked from the start. To delegate access, you have two tools. The first is the iframe's allow attribute. You'd write something like allow equals microphone, and point it at a specific origin. The second tool is the Permissions-Policy HTTP header. Both must agree. Policy inheritance uses an intersection model. If the header and the allow attribute don't both grant access, the feature is denied. There's no way around it. To diagnose this inside your iframe, you call permissions dot query, passing the name microphone. The state you get back reflects that combined decision. Next, we'll move from policy to code and explore the MediaDevices API inside the iframe.2 min
4. 04The MediaDevices API Inside the iframeNow, let's look at what actually happens inside that iframe when the MediaDevices API is called. The script calls getUserMedia with audio set to true. This call cannot happen in the background. It requires a user gesture, what the browser calls transient activation. A click or a tap inside the iframe. When the prompt appears, the user sees the iframe's origin, not the top-level page's domain. That is a key detail for user trust and for your security model. If the user grants permission, the promise resolves to a MediaStream. If not, it rejects with a NotAllowedError or a NotFoundError. The resulting MediaStreamTrack objects carry uncompressed PCM audio samples. There is no automatic origin blocking on the audio data itself, so once you have the stream, the bytes are yours. One more thing about enumerateDevices. If you call it cross-origin without an active microphone grant, the labels come back empty. You will see generic names like 'default' instead of the actual device string. Permission is required to get labeled device info.1 min
5. 05The User Experience and Permission PromptsNow let's examine what the user actually sees and what happens to permissions once they're granted. When a microphone prompt appears, the browser shows the top-level origin, not the embedded iframe that is actually requesting the device. So even if a third-party widget triggers the prompt, the user believes they are granting access to the main site they are visiting. Once the user clicks allow, persistent permissions are scoped to the top-level site and iframe origin pair. After that, the iframe gains access without re-prompting, even across page refreshes. This creates a serious trust problem. Untrusted embedded widgets can quietly inherit permissions and begin recording, with the user completely unaware of the true source of the request. This is often called permission hijacking. To avoid misleading your users, you must clearly label the iframe's purpose and recording intent. Never rely on the browser prompt alone to communicate what is happening. Next, we will explore Security Considerations and Attack Vectors.1 min
6. 06Security Considerations and Attack VectorsNow let's talk about security considerations and attack vectors. When a microphone runs in a cross-origin iframe, several risks come into play. First, clickjacking. A transparent iframe can be layered on top of a button, tricking a user into granting mic access without realizing it. Second, the sandbox attribute. Remember, calling getUserMedia inside a sandboxed iframe requires allow-same-origin, not just allow-scripts. Without it, the request fails. There's also permission hijacking. A compromised third-party widget, like a chat plugin, can inherit delegated permissions. The user sees the top-level origin in the prompt, not the widget's origin, and the iframe gets access without a re-prompt. Once permissions are delegated, the cross-origin iframe can record audio silently. That's eavesdropping. Browsers mitigate this with a few defenses. A user gesture is required. A persistent audio indicator shows on the tab. And the origin is displayed in the permission prompt, though as we discussed, it's the top-level origin, not the iframe's. Next, we'll explore cross-origin isolation and the audio worklet.2 min
7. 07Cross-Origin Isolation and the Audio WorkletNow let's talk about cross-origin isolation and the audio worklet. When you run a microphone inside a cross-origin iframe, advanced audio processing often requires low-level APIs like SharedArrayBuffer and high-precision timers. These APIs are only available when the document is cross-origin isolated. To enter that state, you need both the Cross-Origin-Opener-Policy and Cross-Origin-Embedder-Policy headers. COEP requires cross-origin resources to explicitly opt in with a CORP header. For iframes, this gets stricter. The iframe element itself needs the allow attribute set to cross-origin-isolated. And the entire frame chain, from the top-level page down to the deepest nested iframe, must be in an isolated state. Missing just one link breaks the chain. Why does this matter for audio? An AudioWorklet processing a cross-origin microphone stream needs isolation to perform low-latency custom DSP or noise suppression. Without it, the worklet cannot access the necessary buffers and timers. Next, we'll look at the practical implementation guide for parent page setup.2 min
8. 08Practical Implementation Guide: Parent Page SetupNow let's walk through the parent page setup. The first step is to send the Permissions-Policy HTTP header with your page response. For microphone access, you would set microphone equals self and the specific origin you want to allow, like https colon slash slash widget dot example. This header establishes the site-wide baseline. Next, on the iframe element itself, add the allow attribute with the value microphone. This is the per-frame delegation. The key rule here is the intersection model. The origin must appear in both the header's allowlist and the iframe's allow attribute. If either layer is missing, the feature is blocked. Remember, the default for cross-origin microphone is self, meaning no external origin gets access unless you explicitly opt in. You can validate your setup in DevTools under the Application tab, inside the Permissions Policy section. There you can see the effective policy for each frame. Next, we will look at what needs to happen inside the iframe itself.1 min
9. 09Practical Implementation Guide: Inside the iframeNow let's move inside the iframe and look at the code you need to write. First, feature detection. Check if navigator.mediaDevices.getUserMedia exists. If the top-level document has not delegated the microphone permission, this call will fail before any prompt appears. Next, wrap your getUserMedia call in a try-catch block. You must handle three specific errors. NotAllowedError means the user denied the prompt or the permission policy blocked access. NotFoundError means no audio input device is connected. SecurityError often means the context is not secure or the iframe is sandboxed without allow-same-origin. When you catch any of these, show a clear fallback message. Never leave the user staring at a silent failure. The full flow requires a user gesture. Attach the request to a button click, then pass the stream to a MediaRecorder or audio context. For diagnostics, call permissions.query with the name microphone. This tells you whether the blocked state came from policy or user choice. Up next, we will tackle debugging and troubleshooting.2 min
10. 10Debugging and TroubleshootingWhen a microphone stream fails inside a cross-origin iframe, the fix starts with DevTools. First, check the frame's permissions. Under the Application panel, inspect the Permissions-Policy header and confirm the iframe tag carries an allow attribute with microphone listed. Without both, the browser blocks access by default. Next, open the Media panel to monitor active MediaStream tracks. If no tracks appear, you haven't captured yet. If they appear and then disappear, the stream was likely revoked. Now look at the console. Catch NotAllowedError and SecurityError specifically. A NotAllowedError usually means insufficient permissions or a missing user gesture. A SecurityError often points to a sandboxed iframe without allow-same-origin, or a non-HTTPS context. Use the Sensors tab or call enumerateDevices to see whether the browser recognizes any audio input. Follow that with permissions.query to confirm the current microphone state. Finally, test across browsers. Chrome, Firefox, and Edge may accept a gesture that occurred a few seconds earlier. Safari requires a direct, synchronous user gesture. If audio capture fails only on Safari, this is likely the cause. Next, we'll look at browser compatibility and evolving standards.2 min
11. 11Browser Compatibility and Evolving StandardsNow let's look at browser compatibility and evolving standards. Chrome, Firefox, Safari, and Edge all support Permissions Policy for iframe microphone delegation. But the default posture has tightened over time. Chromium removed default cross-origin getUserMedia access back in Chrome 63. You now need to explicitly opt in with an allow attribute. Security patches have also landed rapidly. CVE-2026-14007, for example, addressed a Permissions Policy bypass that let attackers override microphone restrictions in Chrome. Firefox 66 fixed getUserMedia on sandboxed null-principal iframes that lacked allow-same-origin. These fixes show that the threat model is real. So monitor spec discussions and browser intent-to-ship notices for changes to embedded media permissions. The ground is still shifting. That brings us to our final slide: Summary and Best Practices.1 min
12. 12Summary and Best PracticesLet's pull everything together with a concise summary. First, permission delegation is a dual-key system. The Permissions-Policy header and the iframe allow attribute must both agree on the origin before the microphone wakes up. Second, a user gesture is mandatory. You must call getUserMedia directly from a click or tap handler to satisfy transient activation requirements. Third, set a restrictive Permissions-Policy header. Explicitly lock down the microphone directive and delegate access only to trusted origins you control. Fourth, defense in depth is critical. Combine Permissions-Policy with Content Security Policy frame-src, the sandbox attribute, and X-Frame-Options to create layered protections. Finally, test across browsers. Use DevTools to inspect active policies and verify media tracks actually connect. Thank you for working through this material. Apply these patterns, and you'll keep cross-origin media access secure and predictable.1 min