Embedded content is an ingrained part of the modern online experience – from YouTube videos and like buttons to advertisements and so much more. The average internet user may not realize just how much third-party content is embedded into each page they visit.
Apart from the dynamic user experience and revenue-generation that embedded third-party content can provide, there is an additional benefit that doesn’t get quite enough attention: data security.

In particular, a popular tool for embedding external content – called iframes – offers an extra coating of protection when it comes to securing customers’ sensitive data.

By incorporating iframes into their web page design, organizations can leverage a remarkably safe web design tool that protects their code and helps secure their users’ personal information.

For online businesses that collect, store or transfer sensitive data, especially information that falls under the scope of compliance for PCI DSS, GDPR, or CCPA requirements, iframes are a powerful security tool.

On top of that, combining a standard iframe security approach with more advanced data security technology, such as data aliasing, businesses can bring their risk of a sensitive data breach as close to zero as they can possibly get.

But, before we get into supercharging iframes and offsetting iframe security vulnerabilities, let’s do a quick walkthrough of iframes and why they’re an unsung hero in the world of data privacy.

What are Iframes?

In the world of web development, iframes are a secure method of embedding content from other sites onto your own page. They are simply isolated containers on a web page that are managed completely independently by another host, usually a third party.

To put it simply, it’s a separate web page inside of your existing web page.
Examples of iframes include tweets embedded into news articles, YouTube videos embedded into a blog post, sidebar ads, social media buttons – the list is nearly endless.

These types of securely-embedded web applications seem commonplace today, but iframes weren’t always so prominent in web browsing.

The History of the Iframe Element

In the old days of web development, web pages were just collections of individual static pages. To split up different portions of a site, like the menu or the sidebar, we separated each section using frames.

Frames were effective in that they allowed each piece of a web page to refresh on their own, so you could click on one menu bar and it would reload independently – without the entire page having to reload every time a user clicked a single function.

With such slow internet speeds back then, it was crucial to save as many kilobytes as possible. In 1993, for example, dial-up internet speeds peaked at a whopping 56 kbps (compared to 5 mbps in 2009 to 96.25 mbps in 2018). At the maximum internet performance in 1993, a low-quality 700 mb video would take 28 hours to download at and up to 5 days downloading at full speed.

Load times were important, and every little bit of extra efficiency helped.

Making it so that you could interact with individual frames independently without reloading other areas of the page, like scrolling down a sidebar, made loading times less painfully long.

These frame-based layouts were called framesets and served as the building blocks of modern web design.

Introducing: Inline Frames

By the late 90s, the next step in the evolution of web page layout arrived, and it’s still impacting how web development is done today: the inline frame element, or “iframe element.”

First enabled by Microsoft Internet Explorer in 1997, iframe elements were isolated web pages that could be embedded onto a parent web page. This allowed you to embed content from another site into a frame just like you would with any other element of the web page – without being forced to use a frameset.

To create a wall of protection between the host web page and the loaded page (what’s inside the iframe), web browsers implement a barrier to prevent any manipulation from either side.

If they’re not from the same domain, the parent HTML document and the iframe don’t have access to each other’s CSS styles, DOM or JavaScript functions, cookies, or local storage. The iframe and the parent web page are treated, essentially, like two separate browser windows by the browser.

Keeping this separation is important because this means that you can add third-party content and functionality onto your web page without having to give that external party access they don’t need.

Any third-party code that you insert directly into your own HTML/JavaScript without the security of iframes would attain the same exact access as your own code.

Plus, the accessibility goes both ways: the parent domain’s code has no access to the underlying programming of the contents of the iframe either.

Adding the Sandbox Attribute into the Equation

Using an iframe with content from a different domain embedded into your site triggers a browser’s cross-domain policies, which maintains a separation between your code and the iframe’s content – preventing it from accessing your DOM, cookies, or local storage.

However, even with these automatic cross-site protections, an iframe element from a different domain still CAN:

• Auto-play videos
• Display forms
• Trigger alerts
• Run plugins – including malicious ones
• Allow pop-ups

We don’t want iframes to be able to interact with our own web pages to this degree – or any degree, at all. This can allow for iframe security issues and risks that could have severe consequences.

Thankfully, a solution to this was developed called the sandbox attribute, first made available on Internet Explorer 10.

Inserting the sandbox attribute secures an iframe even more sturdily, ensuring that the document within the iframe CANNOT:

• Submit forms
• Change the parent web page’s URL
• Run plug-ins
• Read cookies or local storage, even if it’s from the parent domain
• Open new tabs, new windows or pop-up windows
• Run any JavaScript (even if it would only impact what’s inside the iframe)

Any of these restrictions, excluding running plug-ins, can be turned off while leaving the rest enabled. It truly depends on which functions you need the iframe to perform, and which permissions it should have access to.

In order to lift a restriction that the sandbox attribute adds, you simply need to add a flag to the sandbox attribute’s value:

• allow-forms: lifts restriction on form submission
• allow-scripts: lifts restriction on JavaScript execution plus enables automatic triggering of features
• allow-popups: lifts restrictions on popup windows
• allow-same -origin: lifts restrictions that prevent retaining access to data from the original URL
• allow-top-navigation: lifts restrictions on the document from exiting the frame from the top-level window

These simple sandbox attributes like allow-scripts and allow-top-navigation segment the webpage and offer a greater level of protection. By combining sandboxing with iframe protections, businesses can customize exactly how they want their embedded content to behave while reducing iframe security risks.

Online companies would be wise to implement this level of protection, but what they don’t realize is that there is an additional step they can take to further protect their users’ sensitive data: data aliasing through VGS Collect.js

Iframe + Data Aliasing = Maximum Protection from Sensitive Data Breaches

Even when online businesses use iframes and sandboxing where their customers input sensitive data, that private – and legally protected – information still has to be sent and stored somewhere.

Just the act of possessing sensitive information, from Social Security Numbers to credit card numbers, puts your company’s database within regulatory scope. Collecting, storing, and transferring consumer data automatically puts you in range of having to comply with regulatory rules like PCI DSS, CCPA and GDPR requirements.

Not only that but maintaining sensitive data on your servers means that there will always remain some level of vulnerability.

To put it simply: if it’s there, it can be stolen by someone. That means that your system, even with sandboxed iframes, can become victimized by phishing attacks.

Fortunately, Very Good Security’s iframe security solution VGS Collect.js provides a safe workaround.

VGS’ unique data aliasing technology provides an added layer of protection to iframes and the sandbox attribute – enabling you to work with sensitive data without actually possessing it on your own database.

Data aliasing works by intercepting and redacting sensitive data, in real-time, then replacing it with a synthetic data alias before it touches your systems. All the original sensitive data is secured in the VGS Vault, and much your network is almost instantly removed from the compliance scope.
Within an iframe, VGS Collect.js generates an individual iframe for each field – bolstering each form with an added layer of protection.

On top of that, by using VGS Collect.js, businesses get compliance and privacy solutions included, and can even immediately gain certain levels of PCI Compliance after implementation is complete.

With our frame security in combination with VGS Collect.js, online businesses can minimize their data security risk to the greatest degree – and avoid any future embarrassing sensitive data breaches.

Try out a free demo of VGS Collect.js here.