Giters

bluwy / whyframe

Develop components in isolation with just an iframe

Home Page:https://whyframe.dev

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

whyframe as a security tool(?)

weizman opened this issue · comments

commented

Hi @bluwy, this is just great!

I was wondering, would it be possible in your opinion to use this tool for security?

For example, if I want to be able to display some content to the user for them to interact with (e.g. "here's your password: XXX"), but I want that content to not be accessible to the rest of the application (assuming for example that I don't trust the scripts in my app) - do you believe whyframe can be adjusted to fit such need?

From a quick look, it seems that the iframe being used must be a same origin, but intuitively I believe successfully changing that to a cross-origin/sandboxed iframe might accomplish that security goal I refer to.

How big the delta between the current state and such a secured state is in your opinion (as someone who's familiar with the core)?

commented

Hi! That's an interesting usecase which isn't something I've planned for.

The way whyframe works now is by relying on your existing build tool, and sharing chunks between it. For example, you may have index.html for your app, and there will be __whyframe/index.html for the iframe, and they will share the same scripts/styles (if there are specifed).

So splitting it out as separate origins might not work well here.

Also, the ergonomics of using iframes directly in your code today requires the "extraction heuristic" to be lax, which could be another concern security-wise. For example, the iframe might be including more JS than needed.

In conclusion, I think it may not be the best fit for now. It's not built for security in mind, and I don't want to hold liability on that 😅 It would be safer instead if you manually hook up the iframes yourself. There's also some utilities I made to simplify communicating between the parent and iframe which could be useful for you.

commented

Thanks for thinking out load with me here.

This is a problem we identified in our team a while ago and been pondering an adequate solution for it.
Both iframes and ShadowDOM are on the table, and although I'm more in favor of the ShadowDOM approach, whyframe seemed like it might have what it takes for the job.

Either way, this is really cool, thanks for the quick and thorough response!

commented

No problem 👍 I'll close this for now but feel free to continue the discussion.

About iframe vs shadowdom, that's also something I've pondered while building this. The conclusion was that it isn't the right fit as shadowdom doesn't always reflect the document-scoped intent you want. For example,

  • if I have document.addEventListener('click'), I probably want to listen to the root of the "wrapper" (iframe or shadowdom). And you can't achieve that with shadowdom.
  • if I have .dialog { position: fixed } or .dialog { height: 50vh }, I probably want that to be relative to the root of the "wrapper" as well. And can't be acheived with shadowdom.

So it depends on the level of control you have, and tradeoffs you can accept.