While teams deploying FOLIO at various vendors and institutions are presumably making some use of this mechanism already, it's able to be quite fine grained and to make full use of it you need to understand the web application you're deploying in depth:
- one might choose to disallow all connections to anything other than Okapi so that, for example, a malicious script can't exfiltrate user data it has captured. But perhaps some apps connect to other services?
- we could disallow the execution of scripts from the Okapi host so that a compromised Okapi service couldn't have malicious scripts executed by the browser. However, I couldn't say for sure that we never do anything with an Okapi response that constitutes execution by the way browsers interpret CSP and it may be something an app in future has a use case for.
It's touched on in this colourful and engaging (though long) article on web application security I occasionally link to: https://medium.com/hackernoon/part-2-how-to-stop-me-harvesting-credit-card-numbers-and-passwords-from-your-site-844f739659b9
I've mentioned this a few times, even as far back as
STRIPES-236. But, so far as I know, not much has happened with it. So I'm creating this Draft issue on the the FOLIO project in hopes of catalysing something as this seems to necessarily involve several teams: stripes, documentation, security, devops:
- someone familiar with Stripes needs a spike to become familiar with CSP and develop a core set of recommendations
- this needs to fit with devops' experience of how FOLIO is deployed in practice
- we need good documentation both to disseminate this best practice and come up with a way for individual apps in the ecosystem to indicate which policy exceptions they require
- security should be aware of this