417: Iframe Allow Attribute Saga

CodePen Radio

There was a day not long ago where a Google Chrome browser update left any page with a CodePen Embed on it throwing a whole big pile of red JavaScript errors in the console. Not ideal, obviously.

The change was related to how the browser handles allow attributes on iframes (i.e. ). CodePen was calculating the appropriate values inside an iframe for a <em>nested</em> iframe. That must have been a security issue of sorts, as now those values need to be present on the <em>outside</em> iframe as well.</p> <p><a href="https://blog.codepen.io/2025/10/20/google-chrome-iframe-allow-permissions-problems/">We documented all this in a blog post</a> so hopefully we could get some attention from Chrome on this, and for other browser makers as well since it affects all of us. </p> <p>And I posted it on the ol' social media:</p> <p>Huge thanks to Bramus Van Damme who saw this, triaged it at Chrome, and had a resolution within a day:</p> <p>I think <a href="https://chromium-review.googlesource.com/c/chromium/src/+/7074672">the patch</a> is a great change so hats off to everyone involved for getting it done so quickly. It's already in Canary and don't really know when it'll get the stable but that sure will be good. It follows how Safari is doing things where values that aren't understood are just ignored (which we think is fine and inline with how HTML normally works). </p> <p>Fortunately we were able to mitigate the problem <em>a little</em> until then. For <em>most</em> Embedded Pens, a <script> is loaded on the page embedding it, and we dynamically create the <iframe> for you. This is just nice as it makes making an accessible fallback easier and gives you access to API-ish features for the embeds. We were able to augment that script to do a little browser user-agent sniffing and apply the correct set of allow attributes on the iframe, as to avoid those JavaScript errors we were seeing.</p> <p>But there's the rub: we'd rather not do any user-agent sniffing at all. </p> <p>If we could just put <em>all</em> the possible allow attributes we want on there, and not be terribly concerned if any particular browser didn't support any particular value, that would be ideal. We just can't have the scary console errors, out of concern for our users who may not understand them. </p> <p>Where we're at in the saga now is that:</p> <ol class="wp-block-list"> <li>We're waiting for the change to Chrome to get to stable.</li> <li>We're hoping Safari stays the way it is.</li> <li>OH HI FIREFOX.</li> </ol> <p>On that last point, if we put all the allow attributes we would want to on an <iframe> in Firefox, we also get console-bombed. This time not with red-errors but with yellow-warnings. </p> <p>So yes, hi Firefox, if you could also not display these warnings (unless a reporting URL is set up) that would be great. We'd be one less website out there relying on user-agent sniffing. </p>