Hello Jakub,

> Feature-Policy: accelerometer 'none'; ambient-light-sensor 'none'; autoplay
> 'none'; camera 'none'; display-capture 'none'; document-domain 'none';
> encrypted-media 'none'; fullscreen 'none'; geolocation 'none'; gyroscope
> 'none'; layout-animations 'none'; magnetometer 'none'; microphone 'none';
> midi 'none'; payment 'none'; picture-in-picture 'none'; speaker 'none'; usb
> 'none'; vibrate 'none'; vr 'none'

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

> At https://www.staging.scheme.org/ ?

Thanks, I was lacking that information from your previous email.

> 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.

> 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.

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.

Vasilij