Difference between revisions of "Cross-Origin iFrame"
From MgmtWiki
(→Problems) |
(→Problems) |
||
| Line 8: | Line 8: | ||
==Problems== | ==Problems== | ||
| − | * Limitations that have been placed on iFrames can (with the exception of running | + | * Limitations that have been placed on iFrames can (with the exception of running plugins) be disabled by the source web site which may not fully share the user's security concerns. |
# Submit forms | # Submit forms | ||
# Change the parent web page’s URL | # Change the parent web page’s URL | ||
Revision as of 10:42, 12 March 2021
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.
Context
- 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.
- Early on security was addressed 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.
Problems
- Limitations that have been placed on iFrames can (with the exception of running plugins) be disabled by the source web site which may not fully share the user's security concerns.
- 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)
Solutions
References
- Iframes as a Security Feature does actually acknowledge some of the security problems with iFrames.
