Third party embeds - security
Written by Hughie Molloy
Updated at June 2nd, 2025
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 now considered an anti-pattern. There is no reason not to use https:// everywhere in URLs instead of detecting the current protocol. There are three reasons we do not support them:
- They are considered a security risk. Vulnerability scanners and security software raises them as a security risk and can lead to a Man in the Middle Attack. For example SonarQube and Screaming Frog will flag them (https://www.screamingfrog.co.uk/seo-spider/issues/security/protocol-relative-resource-links/)
-
They are considered an anti-pattern. They made sense in 2010 when HTTPS was expensive but make no sense at all now: https://www.paulirish.com/2010/the-protocol-relative-url/ - In many cases in an app or a webview, they simply will not work. The webview could present as either a file:// URL (in the case of offline caching) or an internal http:// URL in the case of an on-device proxy. In both cases, protocol relative calls to a third party will either not work or be insecure
Note that since 2015, the US Government advises against using them on federal sites: https://digital.gov/2015/08/14/secure-central-hosting-for-the-digital-analytics-program/
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.