> Security teams have raised red flags about iframes for years. Cross-frame scripting, clickjacking, and credential phishing are common exploits, since the frame executes third-party code inside your trusted domain
I would disagree.
Yes iframes have security risks, but they generally pale in comparison to giving some other random site full control of your page, which is the alternative.
While i agree that is better than nothing, i've always had my doubts about this approach.
Do people really audit such code? I doubt it. Does the code really not insert any additional code that allows bypassing the whole scheme (esp. If the point is to dynamically insert content).
I also think most of the time, the biggest threat is not the vendor being intentionally evil but the vendor making a mistake that leads to XSS which someone else exploits. After all, if the vendor is intentionally being malicious they can probably sneakily bypass this sort of thing.
Many of these arguments are context dependent. If I embed an iframe, then ask a user to log in / provide credentials to whatever is loaded into that iframe, I can see the argument since it is difficult to for the user to verify the origin. However, for something "read only" like a dashboard, I really don't see the argument.
It was a hard requirement for us to make our dev tool 100% embeddable without iframes. From the vendor's perspective, it's an opportunity to differentiate from competitors and avoid potential future iframe limitations that others have mentioned.
This was my instinct when we first started, and years later, on 50% of sales calls someone asks if we use iframes (as a concern). Our enterprise clients don't want to highlight a third-party solution, and iframes scream "not native" to their users.
The technical challenges of avoiding iframes are real, but the business case for solving them has been clear for us.
> Your end users expect brand-consistent dashboards that match the host app down to the smallest pixel.
Is that really true? Aren't most end users now used to, e.g., YouTube and Twitter iframes looking exactly the same everywhere, no matter what the surrounding site looks like?
My experience reading this article was being confused about why someone is listing all the drawbacks with i-frames - even obscure drawbacks that most people would not ever encounter. Then I noticed it’s just an Ad for their product.
I think this kind of blog post should be illegal - there needs to be a disclosure at the beginning, ie, this is informative but it’s also an advertisement. Then I would know to not read any further.
I-frames are actually pretty useful tools. They’re the only way to allow HTML content from another site to exist on your site without trusting or sanitizing it. They actually work pretty well for dashboards.
They come with some serious drawbacks, most notably, not being able to edit the content of the iframe.
I generally prefer using an API or a npm module so I can customize the content of the iframe.
I keep revisiting this approach over and over again - I don't know, maybe I never learn. I'm not interested in analytics dashboards, my context is more around stringing together prototype/poc services into workflow pipelines. The idea usually is along the lines of "have an orchestrator service that knows what the user is trying to do, and serves a sequence of specific, embedded micro-UIs backed by services that implement each step of the overall process". I can't seem to shake this "do one thing and do it well" unix motto, and keep wanting to bring it over to UX design.
I worked on a project exploring this idea and an issue is that while each step in a user journey (get restaurants near me, show me menus, make an order, show me on a map) could invoke a distinct service, provided by different providers that just do that thing well, they all want ownership of the experience and the precious user data and prefer to consume input and render output rather provide output data for others to use - there’s no stdout to pipe. The upshot is apps do everything, which is the opposite of the Unix philosophy.
i don't understand this product - i feel like tools like v0 can one-shot an analytics dashboard these days. i do think something like https://upsolve.ai/ provides real value though
> Security teams have raised red flags about iframes for years. Cross-frame scripting, clickjacking, and credential phishing are common exploits, since the frame executes third-party code inside your trusted domain
I would disagree.
Yes iframes have security risks, but they generally pale in comparison to giving some other random site full control of your page, which is the alternative.
Another alternative is loading a library and setting it to a fixed version.
You're still giving a 3rd party full access to your website, but at least it's more auditable and safe.
Fwiw, I think iframes are great!
While i agree that is better than nothing, i've always had my doubts about this approach.
Do people really audit such code? I doubt it. Does the code really not insert any additional code that allows bypassing the whole scheme (esp. If the point is to dynamically insert content).
I also think most of the time, the biggest threat is not the vendor being intentionally evil but the vendor making a mistake that leads to XSS which someone else exploits. After all, if the vendor is intentionally being malicious they can probably sneakily bypass this sort of thing.
I have never understood the argument against iframes involving security.
Many of these arguments are context dependent. If I embed an iframe, then ask a user to log in / provide credentials to whatever is loaded into that iframe, I can see the argument since it is difficult to for the user to verify the origin. However, for something "read only" like a dashboard, I really don't see the argument.
Also clickjacking isn't a security risk for the page embedding the iframe. This shows fundemental misunderstanding.
It was a hard requirement for us to make our dev tool 100% embeddable without iframes. From the vendor's perspective, it's an opportunity to differentiate from competitors and avoid potential future iframe limitations that others have mentioned.
This was my instinct when we first started, and years later, on 50% of sales calls someone asks if we use iframes (as a concern). Our enterprise clients don't want to highlight a third-party solution, and iframes scream "not native" to their users.
The technical challenges of avoiding iframes are real, but the business case for solving them has been clear for us.
> Your end users expect brand-consistent dashboards that match the host app down to the smallest pixel.
Is that really true? Aren't most end users now used to, e.g., YouTube and Twitter iframes looking exactly the same everywhere, no matter what the surrounding site looks like?
We just use Observable Framework https://github.com/observablehq/framework
FWIW, Observable Framework has iframe embeds too: https://observablehq.com/framework/embeds#iframe-embeds
I think iframes are pretty darn handy and it's really not that hard to leverage their strengths in a secure manner.
My experience reading this article was being confused about why someone is listing all the drawbacks with i-frames - even obscure drawbacks that most people would not ever encounter. Then I noticed it’s just an Ad for their product.
I think this kind of blog post should be illegal - there needs to be a disclosure at the beginning, ie, this is informative but it’s also an advertisement. Then I would know to not read any further.
I-frames are actually pretty useful tools. They’re the only way to allow HTML content from another site to exist on your site without trusting or sanitizing it. They actually work pretty well for dashboards.
They come with some serious drawbacks, most notably, not being able to edit the content of the iframe.
I generally prefer using an API or a npm module so I can customize the content of the iframe.
it's for seo. they could have framed it better
I keep revisiting this approach over and over again - I don't know, maybe I never learn. I'm not interested in analytics dashboards, my context is more around stringing together prototype/poc services into workflow pipelines. The idea usually is along the lines of "have an orchestrator service that knows what the user is trying to do, and serves a sequence of specific, embedded micro-UIs backed by services that implement each step of the overall process". I can't seem to shake this "do one thing and do it well" unix motto, and keep wanting to bring it over to UX design.
I worked on a project exploring this idea and an issue is that while each step in a user journey (get restaurants near me, show me menus, make an order, show me on a map) could invoke a distinct service, provided by different providers that just do that thing well, they all want ownership of the experience and the precious user data and prefer to consume input and render output rather provide output data for others to use - there’s no stdout to pipe. The upshot is apps do everything, which is the opposite of the Unix philosophy.
This is incredible. Thank you so much for making this so I never have to explain this again
Their product is listed as the best alternative.
i don't understand this product - i feel like tools like v0 can one-shot an analytics dashboard these days. i do think something like https://upsolve.ai/ provides real value though
Oh it's more analytics crap.