Can a Content Security Policy (CSP) against cross-site scripting (XSS) be implemented at the Cloudron app level?

[marcusquinn]

• https://developer.chrome.com/docs/lighthouse/best-practices/csp-xss/
• https://web.dev/strict-csp/

Can a Content Security Policy (CSP) against cross-site scripting (XSS) be implemented at the Cloudron app level?

Perhaps as an option, in case it were to break anything for anyone using plugins and scripts that don't respect this.

Also helps in Google Pagespeed results and ranking:

• https://pagespeed.web.dev/

[girish]

CSP directives are meant for the browser. They include things like where to load images from, what scripts can be executed, is embedding allowed etc. This necessarily means that the CSP can only be defined by the author of the HTML which in Cloudron's case is the app itself. Only the app author knows the kind of content in the HTML.

So, yeah, afaik, it's not possible to put something generic that works across apps.

[girish]

We already set some headers following the Mozilla recommendations, OWASP and https://github.com/github/secure_headers:

map $upstream_http_referrer_policy $hrp {
    default $upstream_http_referrer_policy;
    "" "same-origin";
}
...

    add_header X-XSS-Protection "1; mode=block";
    proxy_hide_header X-XSS-Protection;
    add_header X-Download-Options "noopen";
    proxy_hide_header X-Download-Options;
    add_header X-Content-Type-Options "nosniff";
    proxy_hide_header X-Content-Type-Options;
    add_header X-Permitted-Cross-Domain-Policies "none";
    proxy_hide_header X-Permitted-Cross-Domain-Policies;

    # See header handling from upstream on top of this file
    add_header Referrer-Policy $hrp;
    proxy_hide_header Referrer-Policy;

[robi]

The 2nd link suggests one of two options:

Step 1: Decide if you need a nonce- or hash-based CSP

There are two types of strict CSPs, nonce- and hash-based. Here's how they work:

• Nonce-based CSP: You generate a random number at runtime, include it in your CSP, and associate it with every script tag in your page. An attacker can't include and run a malicious script in your page, because they would need to guess the correct random number for that script. This only works if the number is not guessable and newly generated at runtime for every response.
• Hash-based CSP: The hash of every inline script tag is added to the CSP. Note that each script has a different hash. An attacker can't include and run a malicious script in your page, because the hash of that script would need to be present in your CSP.

Criteria for choosing a strict CSP approach:

Nonce-based CSP	For HTML pages rendered on the server where you can create a new random token (nonce) for every response.
Hash-based CSP	For HTML pages served statically or those that need to be cached. For example, single-page web applications built with frameworks such as Angular, React or others, that are statically served without server-side rendering.

[marcusquinn]

Yeah, deep in the rabbit hold on research on this. There's nothing that distracts me more than something that has a score attached to it (not competitive all all )

Trying to get a clean sheet of green on this:

• https://inspectwp.com

Given WordPress is perhaps the most popular self-hosted app of all, be great to have the Cloudron setup as perfect as possible, particularly for WordPress. So many more expensive options out there charging per site. Lots of wins possible from being able to proclaim the best WP setup possible