1

I am developing a web application (like a widget) that my potential clients will use on their websites for the benefit of their users. I was thinking about the best way to deliver the application to them and at the same time be able to control who is using my widget so that I can bill them correctly.

I checked a few previous posts like iframe for a widget and iframe best practices limitations and JS to load iframe but they are 7-10yr old and not exactly what I'm trying to do.

That being said, so far ... the best way to deliver seems to be a combination of:

  • iframe
  • Content-Security-Policy frame-ancestors HTTP header
  • cookies + $http_referer checks on the server side to avoid sneaky users

On the load I'm going to send a secret key with URL to deliver a customized/branded version and I'm planing to rely on cookies for subsequent calls

I have a few questions here:

  1. Should I use an iframe tag with specific URL directly, like

    <iframe src="https://superwidget.com/SecretKey=12345678"></iframe>

or should I use a JavaScript to load/create iframe element using the same URL? Is there any benefit from using one or another except being able to defer a load of an iframe in the JS version?

  1. So I'm planing to use iframe / CSP / http referer / cookie combo ... Is there any other (better) way to deliver a widget and make sure only allowed audience using it?

  2. Anything else I'm missing here

Any help appreciated!

Pavel Kovalev
  • 7,521
  • 5
  • 45
  • 67
  • why do you need an iframe at all? this sounds like you could just as easily use javascript to just add your widget to the page, you lose all the hassles of iframes, and you gain the ability to interact with the source page, such as being able to redirect to another page when needed, or check the size of the screen and minimize on mobile, and allow maximizing to full viewport size, etc... and you can validate any calls to backends come from that known domain, also... – jan6 Jul 11 '21 at 20:45

2 Answers2

2

My recommendation would be to use javascript. That way, in your javascript, you can validate if the DOMAIN NAME for the page that the javascript is called from is authorized for that client's token. If it is, load the IFrame with the custom content.

This will also allow you to have greater control over user experience.

ullfindsmit
  • 279
  • 1
  • 5
  • 20
1

If I were you I would use a simple iframe. The page should be retrived with a key (eg. ?key=some-special-key-in-base-16-58-or-64).

You backend should later on verify that the Refer: not-your-site.com header is whitelisted for that specific API key.

If, instead, you need to use a js widget, you could use the key as a param when requesting the js file and let the verification backend use the classic Host: not-your-site.com header.

You could send a custom widget that asks them to pay/renew the system if the key or the refer is not valid. Some people visitng the site might not like this idea so think carefully about implementing it. If you are not on top of the pyramid of the team let someone with more responsabilty choose.

The advantage of using an iframe widget over a js one is that it has a sandbox and therfor cannot be accesed by the parent site. Please note that it might be a disvantage if you want to let your consumers to modify the widget with their own js.

Please note that SCP has to always be set correctly if you want all of this to work.

Last tip: Using the hosts file to fake two sites on the same machine won't work, on Windows 10 at least, so you'll have to use two different machines.

DadiBit
  • 769
  • 10
  • 22