Use nonce-based Content Security Policy for inline JavaScript

Using nonce-based CSP rules may eliminate a significant number of XSS vulnerabilities we have on GitLab.com. We should consider prioritizing this because implementing this could save us a lot of money and headaches from all these HackerOne reports.

Right now we have some inline JavaScript left over:

$ git grep ":javascript"  app
app/views/layouts/_google_analytics.html.haml::javascript
app/views/layouts/_init_auto_complete.html.haml:  :javascript
app/views/layouts/_init_client_detection_flags.html.haml:  :javascript
app/views/layouts/_piwik.html.haml::javascript
app/views/layouts/errors.html.haml:    :javascript
app/views/layouts/group.html.haml:    :javascript
app/views/layouts/project.html.haml:    :javascript
app/views/layouts/snippets.html.haml:    :javascript
app/views/projects/merge_requests/show.html.haml:    :javascript

Because of this, our CSP rules allow inline JavaScript, but perhaps we can lock this down by using strict-dynamic and nonce-based CSP:

• https://engineering.gusto.com/nonce-based-content-security-policy-csp-in-rails/

Rails 5.2 and the secure_headers gem supports this. Right now our HAproxy config has these CSP rules, but we should consider pushing these down to the application. We should consider:

1. Allow configuration of CSP rules within GitLab application settings (maybe gitlab.yml would be better for version control?)
2. Add a HAML filter for :securejavascript or something of the sort: https://github.com/haml/haml/issues/934
3. Change all :javascript filters to :securejavascript
4. Remove CSP rules from HAproxy

Ideally we'd remove inline JavaScript entirely, but that may not be simple.

Previous references:

• https://gitlab.com/gitlab-org/gitlab-ce/issues/18231