This post is brought to you by Matt Swann, Senior Security Engineer on the SharePoint security team, and Humberto Lezama-Guadarrama, Program Manager on the Office Developer Platform team.
When you build apps for SharePoint 2013 (or even classic solutions) you can host pages on SharePoint. Often, you will also want to IFRAME those pages in other experiences, for example, when using app parts. By default, SharePoint 2013 prevents cross-domain IFRAMING of pages as a security measure to prevent clickjacking. This post explains what clickjacking is, how SharePoint prevents it, and how to allow your pages to be IFRAMED if your scenarios call for it.
Clickjacking is a web attack that tricks a victim into clicking a link or button that they did not intend to click. An attacker's website may exploit a clickjacking vulnerability by hosting the target page in an IFRAME and layering benign content around it, so that the victim will click the desired link. For more information, see the OWASP guidance on clickjacking.
To defend against clickjacking exploits, a site may prevent its pages from being loaded in an IFRAME. It can do so by setting an X-Frame-Options header in the HTTP response, which instructs the browser to disallow framing. For more details about X-Frame-Options, see the post IE8 Security Part VII: ClickJacking Defenses on IEBlog. Microsoft also published a KB article, Mitigating framesniffing with the X-Frame-Options header, which describes how to configure IIS to send this header.
SharePoint 2013 uses the X-Frame-Options header to prevent its pages from being targeted by a clickjacking attack. Each HTTP response sends an X-Frame-Options: SAMEORIGIN header, which indicates that this page must not be loaded in an IFRAME if the outer (hosting) page is on a different domain than the SharePoint page. This has some implications for IFRAME scenarios with SharePoint:
Note: HTML pages hosted on app webs aren't affected by the clickjacking protection. They can be IFRAMED without restrictions because they are pages explicitly authored by the app developer.
SharePoint page developers can opt-out of clickjacking protection by adding the AllowFraming control to their .aspx pages:<WebPartPages:AllowFraming runat="server" />
This control instructs SharePoint not to send the X-Frame-Options header when this page is requested. Without the X-Frame-Options header, the page is able to be IFRAMED.
Note: When you are using any of the Microsoft developer tools, such as Visual Studio, this Web Part is automatically added when creating new pages.
SharePoint page developers should carefully evaluate whether their page may be vulnerable to a clickjacking exploit when the AllowFraming control is used. Their page must not expose forms, buttons, or other functionality that could allow a user to modify content or change settings that affect security.
When you are working with SharePoint on Office 365 (also known as SharePoint Online) you may run into an error when viewing apps that use Web Parts, as described in this forum thread. While the symptoms seem similar, getting a "This content cannot be displayed in a frame" message, the root cause of the issue is different. What happens in the case discussed in the forum is that sites involved in SharePoint authentication may end up in different IE "zones" and so not be able to share cookies. This results in attempting to display a login page within an IFRAME, which can't be done for security reasons. This is a known issue that affects only Internet Explorer (other browsers don't have security zones) and folks on various teams are working on a resolution. You can monitor the referenced thread for any updates.
Also, if you are using our cross-domain library, you may want to take a look at the blog post Solving cross-domain problems in apps for SharePoint. It has a reference about how you can overcome the "zones" issue when using our library on pages that are not SharePoint-hosted.
As always, if you have comments or questions please let us know or hit our forums.