Above we mentioned security concerns ? let's go into this in a bit more detail now. We are not expecting you to understand all of this content perfectly the first time; we just want to make you aware of this concern, and provide a reference to come back to as you get more experienced and start considering using
<iframe>
s in your experiments and work. Also, there is no need to be scared and not use
<iframe>
s ? you just need to be careful. Read on…
Browser makers and Web developers have learned the hard way that iframes are a common target (official term:
attack vector
) for bad people on the Web (often termed
hackers
, or more accurately,
crackers
) to attack if they are trying to maliciously modify your webpage, or trick people into doing something they don't want to do, such as reveal sensitive information like usernames and passwords. Because of this, spec engineers and browser developers have developed various security mechanisms for making
<iframe>
s more secure, and there are also best practices to consider ? we'll cover some of these below.
Note:
Clickjacking
is one kind of common iframe attack where hackers embed an invisible iframe into your document (or embed your document into their own malicious website) and use it to capture users' interactions. This is a common way to mislead users or steal sensitive data.
A quick example first though ? try loading the previous example we showed above into your browser ? you can
find it live on GitHub
(
see the source code
too.) Instead of the page you expected, you'll probably see some kind of message to the effect of "I can't open this page", and if you look at the
Console
in the
browser developer tools
, you'll see a message telling you why. In Firefox, you'll get told something like
The loading of "
https://developer.mozilla.org/en-US/docs/Glossary
" in a frame is denied by "X-Frame-Options" directive set to "DENY"
. This is because the developers that built MDN have included a setting on the server that serves the website pages to disallow them from being embedded inside
<iframe>
s (see
Configure CSP directives
, below.) This makes sense ? an entire MDN page doesn't really make sense to be embedded in other pages unless you want to do something like embed them on your site and claim them as your own ? or attempt to steal data via
clickjacking
, which are both really bad things to do. Plus if everybody started to do this, all the additional bandwidth would start to cost Mozilla a lot of money.
Only embed when necessary
Sometimes it makes sense to embed third-party content ? like youtube videos and maps ? but you can save yourself a lot of headaches if you only embed third-party content when completely necessary. A good rule for web security is
"You can never be too cautious. If you made it, double-check it anyway. If someone else made it, assume it's dangerous until proven otherwise."
Besides security, you should also be aware of intellectual property issues. Most content is copyrighted, offline and online, even content you might not expect (for example, most images on
Wikimedia Commons
). Never display content on your webpage unless you own it or the owners have given you written, unequivocal permission. Penalties for copyright infringement are severe. Again, you can never be too cautious.
If the content is licensed, you must obey the license terms. For example, the content on MDN is
licensed under CC-BY-SA
. That means, you must
credit us properly
when you quote our content, even if you make substantial changes.
Use HTTPS
HTTPS
is the encrypted version of
HTTP
. You should serve your websites using HTTPS whenever possible:
- HTTPS reduces the chance that remote content has been tampered with in transit.
- HTTPS prevents embedded content from accessing content in your parent document, and vice versa.
HTTPS-enabling your site requires a special security certificate to be installed. Many hosting providers offer HTTPS-enabled hosting without you needing to do any setup on your own to put a certificate in place. But if you
do
need to set up HTTPS support for your site on your own,
Let's Encrypt
provides tools and instructions you can use for automatically creating and installing the necessary certificate ? with built-in support for the most widely-used web servers, including the Apache web server, Nginx, and others. The Let's Encrypt tooling is designed to make the process as easy as possible, so there's really no good reason to avoid using it or other available means to HTTPS-enable your site.
Note:
GitHub pages
allow content to be served via HTTPS by default.
If you are using a different hosting provider you should check what support they provide for serving content with HTTPS.
Always use the
sandbox
attribute
You want to give attackers as little power as you can to do bad things on your website, therefore you should give embedded content
only the permissions needed for doing its job.
Of course, this applies to your own content, too. A container for code where it can be used appropriately ? or for testing ? but can't cause any harm to the rest of the codebase (either accidental or malicious) is called a
sandbox
.
Content that's not sandboxed may be able to execute JavaScript, submit forms, trigger popup windows, etc. By default, you should impose all available restrictions by using the
sandbox
attribute with no parameters, as shown in our previous example.
If absolutely required, you can add permissions back one by one (inside the
sandbox=""
attribute value) ? see the
sandbox
reference entry for all the available options. One important note is that you should
never
add both
allow-scripts
and
allow-same-origin
to your
sandbox
attribute ? in that case, the embedded content could bypass the
Same-origin policy
that stops sites from executing scripts, and use JavaScript to turn off sandboxing altogether.
Note:
Sandboxing provides no protection if attackers can fool people into visiting malicious content directly (outside an
iframe
). If there's any chance that certain content may be malicious (e.g., user-generated content), please serve it from a different
domain
to your main site.
CSP
stands for
content security policy
and provides
a set of HTTP Headers
(metadata sent along with your web pages when they are served from a web server) designed to improve the security of your HTML document. When it comes to securing
<iframe>
s, you can
configure your server to send an appropriate
X-Frame-Options
header.
This can prevent other websites from embedding your content in their web pages (which would enable
clickjacking
and a host of other attacks), which is exactly what the MDN developers have done, as we saw earlier on.
Note:
You can read Frederik Braun's post
On the X-Frame-Options Security Header
for more background information on this topic. Obviously, it's rather out of scope for a full explanation in this article.