> That looks highly locked down, possibly copy-pasted from a guide with
> example security headers to set.

The header is based on the recommendations of those online services that
check a given URL. Here's one service: https://securityheaders.com/
There are many others. I can't remember which ones we used.

>> There are also errors form embedded fonts, so it already backfired.

> Sure, the configuration needs to be adjusted to the contents, ideally
> every time a significant change happens. CSP has the report-uri feature
> to automatically notify website administrators if that happens.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/report-uri
claims the feature is deprecated.

>> Yes, I know what CSP is for, but why you need for a website that only have
>> static html files and don't allow to add user content? It doesn't make much
>> sense to me.

> I agree that it's of limited value in this case, but static contents do
> not necessarily mean that the website is automatically immune. It's
> still possible to have DOM XSS (client-side only) in a JavaScript
> application.

Yes, we adopted the strictest headers that worked for our use case.

> Another thing to consider is whether the CSP configuration applies to
> every scheme.org subdomain. Some of them may violate the assumption of
> static pages without user content, for example wiki.scheme.org.

Indeed different subdomains can (and in some cases, clearly should) have
different headers. E.g.
https://github.com/schemeorg/linux-configurations/blob/a6d132ad114160171f0d281d64ed787069b703e9/nginx.scm#L340

For Jakub's use case (hosting static files such as JS, CSS, fonts) could
we make a subdomain like "assets.scheme.org", and set the CSP for all
the other scheme.org subdomains so that they can read from "assets"?