New Extensions policy for Content Security Policy (CSP) directives and timeline for enforcement

[TravistyOJ]

Update (2022-01-24)
In order to minimize disruption and accommodate recent Extension reviews, we have made a few updates to how and when the CSP policy will be enforced this week.

The CSP enforcement date has been moved by two days to Thursday, January 27 and should begin sometime between 11am-12pm PST.

If you have submitted an Extension review request before January 25 at 12pm PST, your Extension will continue to function without the new CSP enforcement until the review has been completed. When your review is completed, regardless of the outcome, you can expect CSP enforcement for your Extension no sooner than 2 business days from that time. If your review takes place after January 27, Content-Security-Policy-Report-Only headers will be sent for the new policy and any potential refusals will be seen in the developer tools console of the browser loading the Extension.

If you submit an Extension review request after January 25 at 12pm PST, your Extension may not be reviewed before the CSP enforcement on January 27.

The original announcement is included below with only the enforcement date altered to reflect this update.

---

Since its launch, thousands of Extensions have delivered exciting and dynamic experiences to millions of creators and viewers on Twitch. As the Extensions framework allows a high level of flexibility, we must occasionally make technical and policy changes to ensure the security, privacy, and safety of our communities. Today we are announcing a new policy for Extensions for this reason:

2.12 You must provide all URLs that are fetched by the Extension front end on each version submission, this includes but is not limited to images, video, audio, and fetch/XHR requests.

Alongside this new policy, Extensions developers must now set three new fields in the metadata of their Extension, “Allowlist for Image Domains”, “Allowlist for Media Domains”, and “Allowlist for URL Fetching Domains”. These fields will be used to define the allowed domains in the CSP directives img-src, media-src, and connect-src respectively. With these fields, developers will be able to define the domains that images and media can be safely loaded from, and which HTTPS/WSS domains can be safely connected to.

Starting today, you can submit new Extension versions with these domain allowlists defined. On Tuesday, January 25, 2022 Thursday, January 27, 2022, all Extensions will be rendered with CSP policy enforced to only allow resources from your domain allowlists. We are making this announcement today to allow you sufficient time to update your Extension.

If you have any questions about this change, please consult the FAQ below, and feel free to comment directly on this thread.

Frequently Asked Questions

How can I test this change before the January 25 27 enforcement date?

While your Extension is in Hosted Test, you can use a tool to modify the headers (e.g. SimplyModifyHeaders) to rewrite your local CSP rules to only allow your list of trusted domains. You will add your domains to the CSP directives img-src, media-src, and connect-src. More information on CSPs can be found here.

Do all Extensions require setting the domains allowlists?

Any Extension that serves front-end resources outside of the uploaded asset package, or connects to a remote resource (XHR, WebSockets), will need to specify the trusted domains that will be used. If all of your front-end resources are included in your uploaded asset package, and your front end does not connect to a remote resource, you will not need to set anything in the domain allowlist fields.

Are any domains prohibited in the allowlist?

As a general rule, we cannot allow base domains of public hosting services. For example, if you are serving assets out of Amazon Web Services S3, we cannot allow https://s3.us-west-2.amazonaws.com, but we could allow the domain name that specifies your bucket: (e.g., https://some-bucket.s3.us-west-2.amazonaws.com).

What happens to my live Extension if no changes are made by the enforcement date?

Any requests to include or to connect to resources will be blocked by the CSP, with the exception of resources included in your asset package, served from Twitch’s CDN.

[BarryCarlyon]

A given extensions current CSP is

content-security-policy: default-src 'self' https://{CLIENTID}.ext-twitch.tv; block-all-mixed-content; img-src * data: blob:; media-src * data: blob:; frame-ancestors https://supervisor.ext-twitch.tv https://extension-files.twitch.tv https://*.twitch.tv https://*.twitch.tech https://localhost.twitch.tv:* https://localhost.twitch.tech:* http://localhost.rig.twitch.tv:*; font-src https://{CLIENTID}.ext-twitch.tv https://fonts.googleapis.com https://fonts.gstatic.com; style-src 'self' 'unsafe-inline' https://{CLIENTID}.ext-twitch.tv https://fonts.googleapis.com; connect-src https: wss: https://www.google-analytics.com https://stats.g.doubleclick.net; script-src 'self' https://{CLIENTID}.ext-twitch.tv https://extension-files.twitch.tv https://www.google-analytics.com;

Where {CLIENTID} is the extension ClientID.

Can you please provide what the new “default” CSP will be for an extension that provides no entries for img-src, media-src or connect-src

This will allow developers to test more accurately in advance of the date.

Please also provide any changes to any other response headers that will be made to improve our testing.

Both of these (headers and CSP) should be documented in the documentation.

I would also like the “Get Extensions” API endpoint to be extended to provide the new CSP fields. As then my local test environment can auto fetch the settings from the API rather than I manually setting this in two places (leading to desync)

UserVoice here: Add CSP fields to Get Extensions – Twitch UserVoice

Additional UserVoice: add twitch known CDN by default to the CSP Add the Twitch CDN to the new default CSP for Extensions – Twitch UserVoice

[BehEh]

Will the required domains for Google Analytics be included by default? While I’m struggling to find specific documentation, I suspect connect-src is required, and possibly also img-src (which GA possibly uses as a fallback).
Alternatively I’d suggest that the required domains are added to the Google Analytics in Extensions documentation.

Finally, while the suggested addon works to test this, it would be nice if at some point closer to the cut-off date we can have Twitch turn this on for hosted test (maybe only for extensions that have added this?) just so we can validate it in our own time rather than having to scramble after January 2022 because the way Twitch parsed the URLs was incorrect or something like that.

[BarryCarlyon]

@BehEh

Will the required domains for Google Analytics be included by default? While I’m struggling to find specific documentation, I suspect connect-src is required, and possibly also img-src (which GA possibly uses as a fallback).
Alternatively I’d suggest that the required domains are added to the Google Analytics in Extensions documentation.

I predict, yes, since these are already included in the current CSP. See my snippet in the prior post.
So the domains we provide will be added to the existing/default CSP.

So, we won’t have to specify self, googlefonts, analytics for example, as they need an additional CSP (for style-src, script-src) that we can’t add. So they should be incldued by default, in the other rules by Twitch

[renaudbiborg]

Hi, while making my extension compliant to the new Policy 2.12 for CSP I have realised that google analytics may use pixel tracking (i.e. load an image) if it considers the request is light enough.
This wil break when CSP come online on January 25th unless the domain www.analytics-google.com is ALSO added to the base img-src CSP policy.

However there is a way to force analytics to use xhr, setting the ‘transport’ variable (docs here ).
I propose that this is added to the documentation on google analytics in extensions

ga("create", ...);
ga("set", "anonymizeIp", true);
ga("set", "transport", "xhr");

Have a nice day.

[renaudbiborg]

Thanks Barry for merging the topics.

@BarryCarlyon

So, we won’t have to specify self, googlefonts, analytics for example, as they need an additional CSP (for style-src, script-src) that we can’t add. So they should be incldued by default, in the other rules by Twitch

Can someone from the dev team confirm Barry’s statement ? I guess it does not harm to add www.google-analytics.com in our requested CSP lists as well just in case, but it will be great to have definitive information from the team.

[jbulava]

To answer the questions regarding Google Analytics, https://www.google-analytics.com will be included in the default CSP for connect-src, script-src, and img-src. The latter being added because of the pixel tracking mentioned.

[jbulava]

Here is the full CSP that you can expect with placeholders for the Extension ID and the additional allowlists provided by Extension developers via the developer console. I’ve used line spacing instead of semicolons for readability.

content-security-policy:

default-src 'self' https://<extension_id>.ext-twitch.tv

block-all-mixed-content

img-src 'self' https://<extension_id>.ext-twitch.tv <allowlist> https://www.google-analytics.com data: blob:

media-src 'self' https://<extension_id>.ext-twitch.tv <allowlist> data: blob:

frame-ancestors https://supervisor.ext-twitch.tv https://extension-files.twitch.tv https://*.twitch.tv https://*.twitch.tech https://localhost.twitch.tv:* https://localhost.twitch.tech:* http://localhost.rig.twitch.tv:*

font-src 'self' https://<extension_id>.ext-twitch.tv https://fonts.googleapis.com https://fonts.gstatic.com

style-src 'self' 'unsafe-inline' https://<extension_id>.ext-twitch.tv https://fonts.googleapis.com

connect-src 'self' https://<extension_id>.ext-twitch.tv https://api.twitch.tv wss://pubsub-edge.twitch.tv <allowlist> https://www.google-analytics.com https://stats.g.doubleclick.net

script-src 'self' https://<extension_id>.ext-twitch.tv https://extension-files.twitch.tv https://www.google-analytics.com

Edit: forcing “plaintext” on the code highlighting

[Marenthyu]

I think it could help a lot if this list was included on the Extension Settings Page or linked to there

[BarryCarlyon]

Wooo!

I have updated the Express Middleware twitchextensioncsp inline with these notes

twitchextensioncsp

My only deviation is the extra rules for rig testing!

[jbulava]

The Restrictions on content section of the Extensions documentation has been updated to reflect the CSP changes and now includes this example with the line spacing for readability. I’ll pass along the feedback next week to potentially link to this resource from the “Capabilities” tab in the developer console.

[JoeNewtonQAST]

Is there any chance that the enforcement of this policy can be postponed for a few days? I realized that this was going to be a requirement based on the email I received on Friday evening. I promptly updated my extensions with the additional domains for CSP and submitted for review, however in my experience reviews usually take two to three business days. This would make my extensions non-functional starting Tuesday until the reviews are complete, likely prompting my users to uninstall my extensions.

I understand that this has been in the works for months now, but the announcements have been included in the standard Twitch Forums email that we all receive weekly. Sometimes I am busy and do not have time to read these email as thoroughly as I would like. I only noticed that this was a breaking policy change because of the email sent on Friday titled, “Twitch Extensions Content Security Policy (CSP) enforcement on January 25, 2022” which clearly was providing notice of a breaking change.

I suspect that I am not the only one that did not immediately notice this change. A few more days of leeway would be greatly appreciated.

[bribrobot]

@JoeNewtonQAST

I suspect that I am not the only one that did not immediately notice this change. A few more days of leeway would be greatly appreciated.

Yes, I just came across the same email notification Joe mentioned today. I’d like to echo their request for a postponement. I’m not sure we could get our extension dev environment back up and building to test the impact and put a CSP through review in time for this to not impact our players

[John_Hancock]

Yes, this was a brutally short notice MAJOR change.

[jboothe]

Totally agree on the extension. The original email looked like a standard newsletter. The subject line should have been similar to the one sent out a few days ago to elevate urgency.

[aaron]

+1 from our team as well

[jbulava]

Hi folks, you’ll see an update to the opening post in a minute. The TL;DR is that we are shifting the enforcement date by two days and any Extension with a submitted review before noon tomorrow will have the CSP enforcement put on hold until the review is completed by our team (plus some time for you to release it).

We appreciate your feedback on this thread and your patience as we figured out the right way to accommodate incoming reviews while also not compromising on this security update. Please feel free to include additional questions.

[JoeNewtonQAST]

Thank you for the reply and the additional time.

[guanzo]

My extension is currently down due to CSP

I got an email 8 days ago from the twitch dev team notifying me of the policy update and I submitted an update the same day. Got rejected due to one of the whitelisted domains. I fixed and resubmitted, now it’s in review. Blegh.

[CVS-Gaming]

Same. We got 5 extensions down. kekw.