{"id":52079,"date":"2021-11-21T15:07:46","date_gmt":"2021-11-21T15:07:46","guid":{"rendered":"https:\/\/barrycarlyon.co.uk\/wordpress\/?p=52079"},"modified":"2021-11-26T15:27:05","modified_gmt":"2021-11-26T15:27:05","slug":"twitch-extensions-part-6-dev-environment-updates-content-security-policy","status":"publish","type":"post","link":"https:\/\/barrycarlyon.co.uk\/wordpress\/2021\/11\/21\/twitch-extensions-part-6-dev-environment-updates-content-security-policy\/","title":{"rendered":"Twitch Extensions Part 6 \u2013 Dev Environment Updates – Content Security Policy!"},"content":{"rendered":"\n

In part 5<\/a> we wrote about a suitable testing platform for building your extensions on, essentially we create a static content server, that mimics the Twitch CDN for testing with.<\/p>\n\n\n\n

Twitch Announced on the Forums<\/a> that they are revising the CSP (Content Security Policy) that extensions use to protect and control what can be loaded. I wrote about this in the previous blog post<\/a>.<\/p>\n\n\n\n

I’m currently waiting on a response from Twitch (via the forums) about any other changes to the CSP, but for now, you can test the changes today!<\/p>\n\n\n\n

What Even is CSP<\/h2>\n\n\n\n

First lets do a quick explanation of what CSP, CSP is Content Security Policy, a browser technology to help control what a given Website can load and what browser functions are allowed.<\/p>\n\n\n\n

The HTTP Content-Security-Policy<\/code><\/strong> response header allows web site administrators to control resources the user agent is allowed to load for a given page. With a few exceptions, policies mostly involve specifying server origins and script endpoints. This helps guard against cross-site scripting attacks (Cross-site_scripting<\/a>).<\/p>https:\/\/developer.mozilla.org\/en-US\/docs\/Web\/HTTP\/Headers\/Content-Security-Policy<\/a><\/cite><\/blockquote>\n\n\n\n

You can read more about CSP and the various things it can do over on the MDN Web Docs<\/a>. There is a lot more that can and can’t be done with CSP more than just controlling what content can be loaded from where, but for Twitch Extensions we only need to consider the parts of the Policy that affect Twitch Extensions.<\/p>\n\n\n\n

Twitch Extension CSP Policy<\/h2>\n\n\n\n

Twitch is requiring Extension developer to declare the Connect, Img, and Media domains, which in the policy are connect-src<\/code>, img-src<\/code> and media-src<\/code>. You can declare this in the Developer Console<\/a> for a version of your extension, under the Capabilities tab.<\/p>\n\n\n\n

\"The<\/a>
The new Extension Dashboard fields<\/figcaption><\/figure>\n\n\n\n

Now, the items you enter here only apply when you are using Hosted Test (or release), since Hosted Test will use Twitch’s CDN, and thus Twitch’s Server which can load and use the relevant fields, but in localtesting (aka not the CDN) we need to set this up ourselves.<\/p>\n\n\n\n

Local Testing a CSP<\/h2>\n\n\n\n

If you have been following this series, then you already have a Node\/Express server that will run a static output for you. We can easily add CSP headers to this server using a module called Helmet<\/a>, generally speaking it’s wise to consider adding helmet (or CSP Headers in general) to any website you run to protect your users, but I digress!<\/p>\n\n\n\n

So, how to set this up for Testing with.<\/p>\n\n\n\n

Normally I’d say, on server start call the API to get the current extension settings from the console, however, the API at this time has not been updated to include the new fields, I raised a UserVoice requesting the new fields<\/a> be added to the endpoints. And you can upvote that here<\/a>.<\/p>\n\n\n\n

So for now, we’ll need to populate the CSP for Helmet manually.<\/p>\n\n\n\n

Configuring Helmet for CSP<\/h2>\n\n\n\n

The first thing I did was look at a released extension to see what the current CSP is, which I then split out into a object for configuring Helmet with. Then I looked at what the rig needs, and then looked at what you need to add to correctly simulate a CSP.<\/p>\n\n\n\n

The base CSP for a Twitch Extension is, here twitch.client_id<\/code> is loaded from an external config file, and represents the location that Hosted Test and Release use to host your files. Which I’ll touch on later.<\/p>\n\n\n

\n\/*\nCurrent base CSP rules subject to change\n\nSee:\nhttps:\/\/discuss.dev.twitch.tv\/t\/new-extensions-policy-for-content-security-policy-csp-directives-and-timeline-for-enforcement\/33695\/2\n\nThis example is based off a live extension\n*\/\n\nlet contentSecurityPolicy = {\n    directives: {\n        defaultSrc: [\n            "'self'",\n            `https:\/\/${twitch.client_id}.ext-twitch.tv`\n        ],\n        connectSrc: [\n            "'self'",\n            `https:\/\/${twitch.client_id}.ext-twitch.tv`,\n            'https:\/\/extension-files.twitch.tv',\n            'https:\/\/www.google-analytics.com',\n            'https:\/\/stats.g.doubleclick.net'\n        ],\n        fontSrc:    [\n            "'self'",\n            `https:\/\/${twitch.client_id}.ext-twitch.tv`,\n            'https:\/\/fonts.googleapis.com',\n            'https:\/\/fonts.gstatic.com'\n        ],\n        imgSrc:     [\n            "'self'",\n            'data:',\n            'blob:'\n        ],\n        mediaSrc:   [\n            "'self'",\n            'data:',\n            'blob:'\n        ],\n        scriptSrc:  [\n            "'self'",\n            `https:\/\/${twitch.client_id}.ext-twitch.tv`,\n            'https:\/\/extension-files.twitch.tv',\n            'https:\/\/www.google-analytics.com',\n            'https:\/\/stats.g.doubleclick.net'\n        ],\n        styleSrc:   [\n            "'self'",\n            "'unsafe-inline'",\n            `https:\/\/${twitch.client_id}.ext-twitch.tv`,\n            'https:\/\/fonts.googleapis.com'\n        ],\n\n        frameAncestors: [\n            'https:\/\/supervisor.ext-twitch.tv',\n            'https:\/\/extension-files.twitch.tv',\n            'https:\/\/*.twitch.tv',\n            'https:\/\/*.twitch.tech',\n            'https:\/\/localhost.twitch.tv:*',\n            'https:\/\/localhost.twitch.tech:*',\n            'http:\/\/localhost.rig.twitch.tv:*'\n        ]\n    }\n}\n\nconst helmet = require('helmet');\n\/*\nYou can use Security Headers to test your server, if this server is web accessible\nhttps:\/\/securityheaders.com\/\nIt'll test that your CSP is valid.\nBest testing done with an extension, on Twitch or in the rig!\n*\/\n\nconsole.log('Going to use the following CSP', contentSecurityPolicy);\n\napp.use(helmet({\n    contentSecurityPolicy\n}));\n<\/pre><\/div>\n\n\n
This I add after app.listen<\/code> and before anything else! It does need to go before your app.use<\/code> for express.static<\/code><\/p>\n\n\n\n
This will configure your test server to use the base\/default CSP. And will log it out the full CSP to the console when you start the server.<\/p>\n\n\n\n
The Extension Developer Rig<\/h2>\n\n\n\n
So the next step is how to enable your test server to work in the Twitch Extension Developer Rig<\/a>. I don’t often use the rig, but it’s handy for spot testing views and mobile when I don’t have my phone handy (or the Extension has not been iOS allow listed yet!)<\/p>\n\n\n\n
The Extension Rig is built in Electron, which means it will include calls to file and in testing it spot calls some other things.<\/p>\n\n\n\n
For the rig I add the following rules, which I append to the default CSP using a Config Switch.<\/p>\n\n\n
\n\/*\nshould we enable the Rig?\n\nThe rig being an electron app, will call some other things\nAs well as having a file:\/\/ based parent\n*\/\nif (csp_options.enable_rig) {\n    let rig_sources = {\n        connectSrc: [\n            'wss:\/\/pubsub-edge.twitch.tv'\n        ],\n        frameAncestors: [\n            'http:\/\/localhost:*',\n            'file:\/\/*',\n            'filesystem:'\n        ]\n    }\n\n    \/\/ append these to the CSP\n    for (let sourceType in rig_sources) {\n        for (let x=0;x<rig_sources[sourceType].length;x++) {\n            contentSecurityPolicy.directives[sourceType].push(rig_sources[sourceType][x]);\n        }\n    }\n}\n<\/pre><\/div>\n\n\n
Nothing to silly there, but important if you are testing in the rig. Only enable this in your server when rig testing not testing on the Twitch website, as it’s overly permissive and might catch you out later.<\/p>\n\n\n\n
My Sources<\/h2>\n\n\n\n
The final thing to do is to setup your sources, now this gets a little weird, as a valid CSP rule can omit the schema of the URL (see note).<\/p>\n\n\n\n
For this example\/setup we are adding the content domains to all three CSP directives. Using this example you can adjust and modify this as granularly as you want.<\/p>\n\n\n
\n\/*\nDid we configure places that we can\/may load media from\nAnd yes we are just gonna glob them to all three groups\nFor example purposes\n*\/\ncsp_options.content_domains.forEach(domain => {\n    contentSecurityPolicy.directives.imgSrc.push(domain);\n    contentSecurityPolicy.directives.mediaSrc.push(domain);\n    contentSecurityPolicy.directives.connectSrc.push(domain);\n});\n<\/pre><\/div>\n\n\n
Note<\/strong>: In testing browsers will not enable\/allow WSS if you declare a schema-less domain of www.example.com<\/code>. So if you want WSS you need to declare it explicitly, for this I declare wss:\/\/www.example.com<\/code> and https:\/\/www.example.com<\/code> in the rule (not the lack of a trailing \/<\/code>).<\/p>\n\n\n\n
I configure these schema+domains in an external configuration file for the server. Here is an example config.json<\/code>:<\/p>\n\n\n
\n{\n    "listen": 8050,\n\n    "csp_options": {\n        "enable_rig": true,\n        "report_uri": false,\n        "ebs_domain": "myebs.com",\n        "content_domains": [\n            "https:\/\/mywebsite.com",\n            "wss:\/\/mywebsite.com"\n        ]\n    },\n\n    "twitch": {\n        "client_id": "abcdefg"\n    }\n}\n\n<\/pre><\/div>\n\n\n
EBS?<\/h2>\n\n\n\n
If your extension utilizes an EBS you’ll need to declare that and add it to your connect-src<\/code>, however if you also load images from your EBS you can skip this step.<\/p>\n\n\n\n
I generally put my images and assets on a seperate server to my EBS, but for test purposes, this server example adds the EBS domain to all three declarations, for both schemas:<\/p>\n\n\n
\n\/*\nDid we configure an EBS to call\n*\/\nif (csp_options.ebs_domain) {\n    console.log('Appending EBS Domain');\n    let ebs_rules = {\n        imgSrc: [\n            'https:\/\/' + csp_options.ebs_domain,\n            'wss:\/\/' + csp_options.ebs_domain\n        ],\n        mediaSrc: [\n            'https:\/\/' + csp_options.ebs_domain,\n            'wss:\/\/' + csp_options.ebs_domain\n        ],\n        connectSrc: [\n            'https:\/\/' + csp_options.ebs_domain,\n            'wss:\/\/' + csp_options.ebs_domain\n        ]\n    }\n\n    for (let sourceType in ebs_rules) {\n        for (let x=0;x<ebs_rules[sourceType].length;x++) {\n            contentSecurityPolicy.directives[sourceType].push(ebs_rules[sourceType][x]);\n        }\n    }\n}\n<\/pre><\/div>\n\n\n
Full Example!<\/h2>\n\n\n\n
I put all of this together as a full example over on my GitHub. See Part 6 of the repository<\/a>. This provides a “rig” as described in Part 5<\/a> but with the additional CSP Fields included.<\/p>\n\n\n\n
To set this up do as follows<\/p>\n\n\n\n