Full Title or Meme
The Inline Frame, or iFrame was introduced to allow isolated web pages from unrelated entities to embed content seamlessly into a web page.
- Frames and Framesets were introduced early in browser history to enable refreshing only a portion of a web page to improve responsiveness of web pages in the days of low bandwidth data communications.
- Identity features like OpenID Connect and WebAuthn 2 depends on the Cross-Origin iFrame for a seamless User Experience when identity is provided by a different web site than the Relying Party.
- The user is somewhat at the mercy of the web site in that the site is more interested in gaining users than in their security.
- Limitations that have been placed on iFrames can (with the exception of running plugins) be disabled by the source web site which does not fully share the user's security concerns.
- Run plug-ins
- Submit forms - disabled by allow-forms
- Change the parent web page’s URL - disabled by allow-top-navigation
- Read cookies or local storage, even if it’s from the parent domain
- Open new tabs, new windows or pop-up windows - partially disabled by allow-popups
- Access data from Origin URL - allow-same-origin
Cross Site Scripting
Cross Web Site Scripting Attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.
- 3 Reasons You Might Not Want To Use Iframes
- Iframes as a Security Feature does actually acknowledge some of the security problems with iFrames but mostly is oriented to Relying Party.