Embedding pens from CodePen

Would love to hear about what security problems you had.


There are two particular vectors that are painful

  1. Playing sound, so people could create really annoying topics
  2. Consuming high CPU by running stuff in tight loops with timers

Maybe the embed should have a mode where it runs nothing until the user opts in?


Yeah, or defaulting to the non-Result tab by default, be it HTML, JS, or CSS. That way the user has to select Result to get it to run.

Having a “click to play” mode would be ideal, as part of the embed. That is, an embed that only runs when the user initiates the action.


Ah yes! I just wanted to make sure they weren’t really security concerns. Obnoxiousness concerns are pretty bad too though ;).

You aren’t alone here. Ello decided to write their own thingy (Embetter) for embeds so that they are only loading ALL embeds on-demand. Gitter has also asked us about sound-suppression.

I totally agree that click-to-play is a great plan. Especially for oEmbed, where the whole point is that ANY Pen can be embedded and it’s directed to make it easy for user-generated-content kind of scenarios. And we can leave alone the kinda “standard” embed for people who are, like, writing blog posts and want to demo their stuff more directly.

We’ll work on that and get back to you.


it sure will :slight_smile: let us know when/how and we can turn it back on


Hey Team!

We’ve worked on a fix for this: click-to-play, as you suggested.

We haven’t deployed it yet, but it would be how all oEmbed embedded Pens would behave.

  1. When the embed loads, you get a (very lightweight) placeholder with the title of the Pen and author and such. Plus a big “Run Pen” button.

  2. If anywhere on there is clicked/tapped, it loads the embed.

Thus, no unexpected sound, no unexpected crazy CPU use, no going to a page with a zillion embeds and feeling the lag, etc.

That work for you?


Sure does! Sounds great

1 Like


This has been deployed now. Everything feels pretty solid. Definitely let us know if there’s anything else you’d need, to get us enabled again :smile:

1 Like

Does this apply to all existing codepens, or does it have to be a brand new codepen? As we whitelisted it at our instance and I’m not seeing the improvements.

@techapj can you turn codepen embeds on by default in the oneboxer now? It should be safe as they are all click-to-play per above.

1 Like

I think the way oEmbed works is that it does the oEmbed request once ever, when the content is published, than just stores what it got back forever. So it maybe won’t affect all existing embeds but only newly-posted ones.

I’ll drop a test here:


@chriscoyier, in IE and FF, we’re seeing this

But Chrome shows

Example at


Further review indicates it is the .background-overlay background not being taken into account

Seems both Firefox and IE have a problem with these

background: -webkit-radial-gradient(center, ellipse cover, rgba(0,0,0,0.5) 20%, rgba(0,0,0,0.85) 100%);
background: radial-gradient(center, ellipse cover, rgba(0,0,0,0.5) 20%, rgba(0,0,0,0.85) 100%)

Because when I put

background: #ccc;

via Developer Tools in both browsers, I’m able to get a background that is more representative of what I see in Chrome.

Ahh yep!

Fixed that now, was a little mixup with the autoprefixer. Just checked firefox again, and its all good.


Okay, codepen is now whitelisted by default in onebox:



That’s wonderful. Thanks for all the feedback and help and responsiveness.


It still dosent work… Did somone get a fix?

Let’s see:


Looks just fine to me, no idea what you’re talking about.


Is this still working?