Third party embeds - security
Table of Contents
Pugpig apps embed all sorts of content from polls to comments, videos to tweets. HTML content in apps are displayed in a webview. This means embeds will work in a similar way to how they operate on a website and a SDK will not be required. Some providers, however, restrict who is allowed to embed their content - often by whitelisting domains.
Here are some common questions that you may have when looking at third party embeds.
Protocol relative URLs
We cannot support protocol relative URLs. These are a security anti-pattern, more details on which can be found here:
https://www.screamingfrog.co.uk/seo-spider/issues/security/protocol-relative-resource-links/
Why we can't expose a normal hostname/port?
We need to proxy our requests so that we can control caching, downloading and offline behaviour. There is no way for us to use a real proxy, so we must use what we call our No[t technically a pro]xy—Noxy for short.
Our Noxy works by listening on an OS assigned port on the loopback interface and then we point the web view at the Noxy. This means the from the user agent’s perspective the origin is localhost:n, where n is the OS assigned port number.
We don’t have an IANA assigned port number and even if we did, multiple concurrent instances of our apps would collide on the port. So our only recourse is to use an OS assigned random (but stable*) port number.
*The OS may sometimes (rarely) reassign our port, which changes our origin from localhost:n to localhost:m.
What we require on the CSPs/other from the vendors?
We do not require any CSPs on embeds from vendors. If a vendor wishes to add a CSP we need to add http://localhost:*
and the vanity domain at a minimum.
While we understand http://localhost:*
isn't ideal, it is the only way, you could conditionally add this to your CSP header based on our user agent.
Are there any workarounds where the vendor has to set a fixed host?
Yes, we can, on a case by case basis, proxy the embed. Here we would give the vendor a fixed location where we would would host the proxy. Then we would iframe our proxy into the app. This will not work with a CSP frame ancestors header but may work with other domain locking technologies.
What does this mean for CORS headers?
Unfortunately this means you will need to allow http://localhost:???? (where ???? is a random port number) to your heads. Some systems we deal with do allow this using dynamic CORS headers, but if you don't support this you will need to allow a wildcard CORS header for everything.
Will AMP mode work?
Several vendors have a 'Google AMP mode'. These tend to have less stringent requirements. For most, but not all, these embeds will work in app with not further changes.