Use nonce-based Content Security Policy for inline JavaScript (#65330) · Issues · GitLab.org / GitLab FOSS · GitLab (original) (raw)

Skip to content

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:

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:

Edited Jul 30, 2019 by Stan Hu