Content Security Policy

Extensions
1

I’m running into an issue after moving to hosted test I’d like some help with. For my extension backend service (EBS), I’m using Google Firebase. The clients connect to Firebase to obtain live data. Here is what I’m running into:

Refused to load the script 'https://my-db-name.firebaseio.com/.lp?start=t&ser=80818288&cb=2&v=5' because it violates the following Content Security Policy directive: "script-src 'self' https://my-ext-id.ext-twitch.tv https://extension-files.twitch.tv".

This is sort of new to me, but I did try add the following to my respective client HTML files:

<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self' https://my-ext-id.ext-twitch.tv https://extension-files.twitch.tv https://my-db-name.firebaseio.com">

But I’m still seeing the CSP errors. Will setting the CSP like that even work? Any direction here would be appreciated.

Edit: So it looks like I’m able to affect the CSP errors I’m getting by modifying the <meta> tag, but only for things like font-src or style-src and not the one I actually need script-src. Still looking for help with this.

2

I tried to play around with Firebase as well and ran in to the same issue. I don’t think you’re going to be able to get it working because Firebase loads JS from Firebase dynamically (I think?) and the CSP the Iframe is running in only allows JS to be loaded from the Twitch CDN.

There might be a way to get it working though. I only messed with it for a bit before giving up because in the end they’re probably going to deny Firebase in the approval process due to un-readability/“obfuscation”.

3

@samcm is correct in that our CSP will prevent JS from being loaded from a source other than Twitch. There is also policy in regards to this: https://dev.twitch.tv/docs/extensions#guidelines-and-policies (the very first line).

4

It looks like that endpoint is the method Firebase uses to deliver a non-WebSocket fall-back when WebSocket connections fail (?.lp -> “Long Polling” endpoint), and that uses JSONP to deliver the data instead. In that scenario the JSONP ultimately gets included as a <script>, but only for (I believe) the purpose of delivering data when cross-domain policies in web browsers prohibits .json from being loaded directly.

The good news is that endpoint doesn’t get requested at all in the happy path where the WebSocket connects OK.

This leaves me thinking Firebase might still be fine to use as a WebSocket-only back-end, let’s say if you force it to not allow the long polling fall-back (firebase.database.INTERNAL.forceWebSockets()).

Re: readability of the libraries in the submitted zip, wonder if webpack-importing the Firebase requisites into a vendor.js would be preferable / make it fine? Since the libraries they provide on their static CDN appear to be minified e.g. https://www.gstatic.com/firebasejs/4.5.0/firebase-database.js

5

I ended up forcing WebSockets for the clients and adding the appropriate CSP sources. Seems to have worked out great for my extension.

1 Like
6

Curious - have you or anyone else had to sort out what URLs to whitelist for Firebase realtime database apps on extensions in light of the new extension policy? New Extensions policy for Content Security Policy (CSP) directives and timeline for enforcement

Looking in to this now, seemingly would need to be ws://[APP_ID].firebaseio.com for the websocket, https://[APP_ID].firebaseapp.com for any Firebase function APIs, any others?

7

I’m seeing wss://s-usc1c-nss-*.firebaseio.com/.ws?v=5&ns=[APP_ID] being connected to in testing, planning to try that in whitelist as well.

8

@bribrobot Did Twitch allowed this url in your review?
They did not allow wss://*.firebaseio.com on mine, so I had to changed it to a more specific one, I am waiting for the review. I haven’t added wss://s-usc1c-nss-*.firebaseio.com though.

9

Did you have any luck with this? I was initially using wss://[APP_ID].firebaseio.com but it seems like it doesn’t work by itself.