Make autoCSP configurable

[sherlock1982]

Command

build

Description

Great to see autoCSP property cause looks like it's the only way to go with PWA.
Please could you make possible to add extra options to generated CSP ? I'd love to specify for example default-src, img-src e.t.c.

Describe the solution you'd like

Make it somehow configurable:

 "autoCsp": {
         "default-src":  "'self'",
         "img-src":  "* data: blob:",
         "media-src": "'self' data:"
 }

Describe alternatives you've considered

A header still will be needed for frame-ancestors to add (for example in nginx):

   add_header Content-Security-Policy "frame-ancestors 'none'";

It works nicely in conjuction with autoCSP and I can even specify

   add_header Content-Security-Policy "frame-ancestors 'none'; media-src 'self' data:";

The issue here is that if I add default-src

   add_header Content-Security-Policy "default-src 'self'; frame-ancestors 'none'; media-src 'self' data:";

Angular app will be broken because the least permissive policy (this one) wins.
To workaround it I will have to specify each case separately here worker-src; frame-src e.t.c but do not specify script-src which will make it enormous and hard to maintain.
I would love to specify them in index.html directly

[dgp1130]

/cc @aaronshim

We talked a bit about configurability here and IIRC, the current goal is to keep things as simple and constrained as we can since the goal is to automate CSP generation, not just plumb through user-provided directives, which shifts the burden to the developer.

I suspect directly managing something like img-src is just not worth the security benefit it actually buys you, but Aaron would probably have a better sense of which directives are impactful enough to support here.

[sherlock1982]

strict-dynamic protects you from markup injections of scripts. You can still have injections of other things via blessed code.
Any 3rdParty library you include can be hacked or intentionally changed to become spyware.

• style-src (not yet covered by autoCSP, I guess this needs to be 'self' 'unsafe-inline' or just 'self' because you do not incorporate nonce-based CSP)
• img-src
• media-src
• font-src
• frame-src (for example Google ReCAPTCHA will include an iframe and I control it to be only specific one)
• connect-src
• worker-src

Since you don't specify default-src all these are not-restricted anyhow.

Anyway I think in the end I will add an extra logic that will grab tag from index.html, enrich it with extra options (specifically default-src 'none' for example ) and provide it via header. As multiple CSP policies might be confusing and absence of CSP header will be very annoying for auditors

P.S. You implement a feature and unskilled developer will think it works out of the box and no additional actions required. While yes additional actions required.

[dgp1130]

Had a brief discussion on this today and one option which came up was using multiple CSP headers. We can auto-generate script-src, but then it should be possible for users for create their own additional Content-Security-Policy to configure directives like img-src without needing to go through Angular: https://content-security-policy.com/examples/multiple-csp-headers/

One potential issue with that is default-src, which doesn't compose well in this model. Maybe it's worth having special capabilities to configure that?