Building the Publisher Interface

Iframe security – too much of a good thing?

In recent years, we've moved CHILI GraFx from a single server solution, owned and maintained by the client, to CHILI GraFx — a fully blown SaaS solution. Among the many advantages? No server, no maintenance. Spin up an environment, give the client a URL, and they are ready to start integrating. It's fantastically quick and easy to adopt, but we discovered a fly in the ointment: browser security.

CHILI GraFx is served to the client in an iframe, which is a special type of HTML frame that can display content from another website.

You're probably already familiar with iframes from advertising. For adverts, the iframe usually points to an ad subscription company that serves one or more adverts into the iframe. The website owner then hopes you will click on an advert so they can earn a few cents.

While iframes are really useful, browser creators (think Apple, Firefox, Google, Microsoft, etc.) soon realized that they could also pose a serious security risk. A malicious hacker could, for example, include JavaScript in an advert designed to trick you into giving up your password for a completely different site.

To combat this, browser makers implemented a same-origin policy in their products. This stopped JavaScript from a different domain running in your website's domain.

In other words, the website you're viewing has no access to what's inside an iframe; and the iframe content has no access to the surrounding browser window.

Security problem solved? Well yes, but...

There are good guys using iframes too

What if you found yourself in a situation where you needed the content of an iframe to communicate with the website page it was embedded in?

As an example, let's say you wanted to create a custom "Save" button on your webpage that saved content from inside an iframe embedded in your page. Or how about if you wanted to take variables from your browser window and pass them into the iframe?

In both cases, you'd be stymied by the fact that JavaScript cannot communicate into or out of an iframe.

That's great for advert security but was bad for the CHILI Editor. Our editor frequently needs this type of functionality, as do many other browser-based solutions.

So while we wanted to use iframes to deliver a product that was quick and easy to integrate, we also wanted a solution that did not require complicated server proxies or unsupported browser tricks to get it talking with the environment it was embedded in.

A solution...

Many applications and frameworks run in iframes just like CHILI GraFx. Thankfully, browser manufacturers realized this some time ago and came up with the postMessage function to facilitate safe communication between iframes and the parent website.

postMessage is a function, found on the window object, that will allow you to send a message to and from an iframe. It is secure for two reasons:

1. The website is configured to expect the message.
2. The message includes origin information, letting the website in the iframe, and outside the iframe, know where the message came from.

It works just like when you want to send a text message to a friend: you need to know their number first. And when your friend receives your text message, they can review the phone number it came from and decide whether they want to respond.

When communicating with CHILI GraFx, it is even simpler. It is more like sending a text to a store or service asking for info like opening times or product prices. We just respond to your request and don’t care about the origin. In other words, our solution just reads the message request and responds.

And the Publisher Interface on a better solution

So, in order to make the interaction between iframes and web pages easier, we wrapped all the complexity of postMessage into a simple library that we've called Publisher Interface, and we’ve made it freely available as our first truly open source project at CHILI publish. (This is an exciting venture for us at CHILI publish and we’ll discuss it in more detail in a future blog post.)

Meanwhile, as a bonus, we have provided a well-documented interface that will have developers wanting to work with this library over the default editorObject.

You can check it out on GitHub.

Want to get involved?

If the above gives you a warm tingling feeling and you feel ready for an exciting new adventure in a very international, multicultural, bleeding-edge scale-up, don’t lose a minute—go to our job page and apply now!

And if you’re not interested in a career-switch right now, we hope you’ll take a look at what we do anyway then follow us on NPM and GitHub (maybe even give us a star). We’re sure to be posting new codebases on both in the near future.