Why not to use iframes for embedded dashboards | Hacker News Reader

Why not to use iframes for embedded dashboards

embeddable.com

28 pointsrogansage21 comments

> 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.

How is that different to any other library? Supply chain risk is a big problem.

Supply chain risk gets all the headlines, but personally i think its a bit overhyped.

That said, things like SRI don't really fully fix the supply chain issue. Supply chain issues usually mean the developer intentionally upgrades to a new version, that unbeknownst to them is malicious. It is usually not about a resource getting replaced with nobody realizing it, everyone realizes the upgrade is happening. In such a situation it is likely SRI hashes would get upgraded too.

Solutions like hashes or digital signatures are useless if the person being tricked is the one responsible for signing things.

Also clickjacking isn't a security risk for the page embedding the iframe. This shows fundemental misunderstanding.

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.

> 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?

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.

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.

Their product is listed as the best alternative.

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

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 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.

Reply on news.ycombinator.com