content security policy about rack-tracker

[bumi]

thanks for raising this topic!
I think this is probably too complicated to automate - as we have many different integrations here and the CSP header can be rather complex (afaik). Also I don't think it is a good idea to automatically change a security header and users should do that intentionally.
Would be good to hear other thoughts on this.

Maybe an entry in the readme should be added?

[glaszig]

the CSP header can be rather complex

no, it's actually quite simple. the parsing instructions are 6 points.

https://w3c.github.io/webappsec-csp/2/#syntax-and-algorithms

don't think it is a good idea to automatically change a security header

well, could be controllabe. but you'll need it guaranteed if you're deploying a csp.

[bumi]

so your suggestion would be to automatically add domains of the included integrations?
we just need a general function (not just google), so each handler should know what domain(s) to add.

and maybe we can make this feature configurable.

[glaszig]

so your suggestion would be to automatically add domains of the included integrations?

either that or give a warning if a csp is set but missing the handler's sources. the warning maybe a sensible approach between modifying the header and doing nothing at all?

we just need a general function (not just google), so each handler should know what domain(s) to add.

yes

and maybe we can make this feature configurable.

yes. via an option.

[glaszig]

the nonce-src feature of csp just came to my mind. instead of adding each script url for each handler in use, rack-tracker could generate a nonce value, add that to each script tag and add that nonce to the csp. that's one single approach to white-list all rack-tracker-injected scripts independent from the tracker's actual script source.

https://w3c.github.io/webappsec-csp/2/#script-src-nonce-usage

[DonSchado]

yeah, I was also thinking about that topic for rack tracker a couple weeks ago.
CSP is maybe the best mechanism available against XSS.
But in my opinion it's not so easy to have a strong CSP and use tracking scripts at the same time.

Yes, one solution would definitely be a nonce based approach.
Rails 5.2+ has this out of the box. We would just need to pass it through, when initializing the handler in the controller and add it to the script tags.

But the problem is that some tracking scripts (at least the famous ones) require the insafe-inline option on src and style directives. And when I understood CSP correct, you can't have both... using unsafe-inline for some scripts, but also use a nonce. 🤷‍♂

Which makes the whole use of a CSP policy pointless in my opinion...
Working around this, would require a controller based decision, of enabling/disabling the CSP vs a nonce approach for others where you don't need tracking?
I don't know. The Rails Guides have only a short entry on that topic.

Please advise :)

[glaszig]

But the problem is that some tracking scripts (at least the famous ones) require the insafe-inline option on src and style directives. And when I understood CSP correct, you can't have both

crap, you're right. was a nice dream, though.

Please advise :)

🤔

may be relevant: https://ayesh.me/google-analytics-csp

TL;DR
? Move your inline Analytics script to a separate file
✅ Allow scripts from www.google-analytics.com with script-src directive.
✅ Allow images from www.google-analytics.com with img-src.
➡️ Content-Security-Policy: script-src www.google-analytics.com; img-src www.google-analytics.com
⚠️Take note that the above is not your final CSP.

[glaszig]

also relevant, specifically for google: https://developers.google.com/tag-manager/web/csp
tl;dr: it's a clusterfuck.

[DonSchado]

yeah CSP and tracking conflicts quite a lot :D

When there is no easy solution, I would recommend that we add a short general guidance on that topic to the readme.
Would you like to start something for this? :)

[DonSchado]

I close this for now. Let's reopen this, when the topic comes up again