5082 - Make content-security-policy more strict

[kennsippell]

Description

I believe this is our most tightly constrained CSP without breaking anything. It requires a few "unsafe" configurations:

1. imgSrc: data: - "developers SHOULD NOT include either 'unsafe-inline', or data: as valid sources in their policies. Both enable XSS attacks by allowing code to be included directly in the document itself; they are best avoided completely." https://www.w3.org/TR/CSP3/#csp-directives
2. scriptSrc: unsafe-eval - We use eval() about 88 times and use new Function() about 17 times in inbox.js. "AngularJS makes use of this in the $parse service to provide a 30% increase in the speed of evaluating AngularJS expressions." https://docs.angularjs.org/api/ng/directive/ngCsp
3. styleSrc: unsafe-inline - Our dependency, angular-ui-bootstrap injects about 8 inline style blocks. Here is an example issue where they fix one of them Angular-ui is throwing csp error on uib-popover angular-ui/bootstrap#5470. The risks from unsafe css are reduced by fully constraining imgSrc (not done here) and by avoiding unsafe-eval (not done here).

#5082

Questions for Reviewer

1. I'm explicitly allowing the inline script for telemetry window.startupTimes - through a whitelisted hash. Another option would be to move that script into its own file and appcache it. As-is, if the content of this script ever changes, the corresponding hash will need to be updated. If we keep it as a hash, I'm unsure of the best method to keep the hash and script in sync (new test, calculate the hash in api, just pray, etc.).
2. We may want to whitelist a hash for each of the eight style blocks from angular-ui-bootstrap instead of usingunsafe-inline - I didn't do it because I'm not sure they are always the same for all browsers but they probably are and can follow-up if we close on that direction.

Additional considerations

This change also makes the header larger. Including it on all resources (js, css, application/json, etc.) isn't required so one minor performance tweak we might consider here is setting it for Accept: html requests only.

CSP also supports report-uri which can alert us when the security policy is violated (due to bugs or successful attacks). Might be worth opening an issue to enable this down the road.

Testing

I went through some basic workflows in webapp + tried each actions in admin pages. In general though, this has risks of breaking edge-case functionalities or workflows I don't know about. Best to AT across all browsers as there are apparently some differences.

Review checklist

• Readable: Concise, well named, follows the style guide, documented if necessary.
• Documented: Announced in Changes.md in plain English. Configuration and user documentation on medic-docs
• Tested: Unit and/or e2e where appropriate
• Internationalised: All user facing text
• Backwards compatible: Works with existing data and configuration or includes a migration. Any breaking changes documented in Changes.md.

License

The software is provided under AGPL-3.0. Contributions to this project are accepted under the same license.

[garethbowen]

Great work!