Standardise `textpattern` CSP overrides when confirmed working

[petecooper]

• [ ] @philwareham to confirm current CSP on .com is viable
• [ ] @petecooper to roll out to other sites

Can close when done.

[philwareham]

We are missing a Access-Control-Allow-Origin header on textpattern.com - which currently prevents fonts being shared across domains (on compliant browsers i.e. Firefox).

Short-term, can we try add_header Access-Control-Allow-Origin * to open up access and see if that fixes this. Long term we would need to tighten it to just our core domains/subdomains.

Some reference material: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS https://enable-cors.org/server_nginx.html

[petecooper]

OK, I just added add_header Access-Control-Allow-Origin *; to the Nginx config for .com, please test. Will commit to repo next.

[philwareham]

OK, that works for now, thanks. I still need to get my head round all the CSP and CORS stuff so we can eventually tighten security more.

[petecooper]

Nice one.

Yep, I'm still finagling some of the finer points but we're making steady progress. I'm not 100% happy with wildcards like this, but it's an evolving process after all. I'll leave this open as a reminder.

[philwareham]

Just a reminder note (which we discussed previously but I can't seem to find the discussion) - we need to have overriding CSP rules within the textpattern directory that open up the CSP more than what is locked down in the root directory.

[petecooper]

Yep, agreed - I'll look for the discussion this end, see what turns up.

[philwareham]

From memory - basically we lock things down pretty tight in the root directory and then in the textpattern directory we have the Nginx equivalent of this subdirectory htaccess file: https://github.com/textpattern/textpattern-com-website/blob/master/src/docs/textpattern-htaccess.txt

[philwareham]

Hi. Can we target the textpattern directory using?...

location /textpattern/ {
    ... overriding CSP rules and suchlike ...
}

We need to tighten CSP in root directories and loosen in textpattern directories.

[petecooper]

Broadly, though the regex might need a bit of fine-tuning. I've got a full work-work day today but should have a bit of time later to investigate and do a first pass.

[philwareham]

OK thanks, no real hurry of course.

[petecooper]

Your patience is greatly appreciated!

[philwareham]

If we get https://github.com/textpattern/textpattern/issues/1142 under some sane control, we won't need to provide additional special directives for the textpattern directory.

Also, I think when we finish the move of the docs site to our server we can change the following (lax) header rule on .com site from:

add_header Access-Control-Allow-Origin *;

To:

add_header Access-Control-Allow-Origin https://textpattern.com/

Although we would have to make sure that doesn't affect the JSON file used for version checks by Textpattern installations.

[philwareham]

@petecooper if you could create a location block as mentioned in https://github.com/textpattern/server-config/issues/10#issuecomment-504921821 and then unset the CSP header entirely there. We can then:

1. Tighten the style-src and script-src on the root CSP.
2. Set the CSP header for the Textpattern admin-side directly in the Textpattern config file.

This then gives us granular control over the Textpattern admin side, and in future we can lock that down further using nonce values if we can get this working nicely in thew admin-side.

[petecooper]

Yep. Will take a look tonight. To be continued.

Edit: I'll set up a test Textpattern site with fresh eyes tomorrow AM so we can tweak the CSP away from .com and not clobber it.

[philwareham]

Just a NTS, this will be solved when we eventually upgrade to Textpattern 4.9, as that allows for a user-configurable CSP directly within the configuration file. Meaning we can lock down the root with better CSP. No need to declare location blocks that we previously discussed.

@petecooper The only other thing is the insecure Access-Control-Allow-Origin *; which I think we can solve by replacing with more specific:

location ~* \.(woff|woff2)$ {
    add_header Access-Control-Allow-Origin *;
}

[petecooper]

@philwareham - Devil's advocate: given we have a limited set of fonts to serve, could we forego DNS lookups and serve them from each domain? Given new architecture now means we're load balancing sites across multiple datacenters, this would save cross-continent round trips for fonts etc.

I'm happy to implement the location block for WOFFs as mentioned, I'm just weighing up the pros and cons of that (with centralised fonts) compared with the extra work involved with updating / adding fonts to domains from time to time.

[philwareham]

Maybe. The forum now uses the extended Latin font (because of user languages) whereas the other sites use the non extended version (which are a smaller file size).

Since the forum has its own CSS we can store its fonts on that domain - I’ll implement that today. However all other sites (docs, themes, etc.) get their CSS from the main .com site as well as fonts so storing fonts in each domain is not possible (or even desirable) because we are caching a single set of assets used across all these sites (it also makes my dev a lot easier).

So, regardless of the forum, we will still need the rule I mentioned above on the .com domain.

Hope that makes sense.

[petecooper]

(it also makes my dev a lot easier)

That's what I needed – let's do it.

[petecooper]

Appears done, tentatively closing.