Csper's Content Security Policy Journey

Csper is both a website and a Content Security Policy report-uri service. That means we get to dogfood our own product!

This blog covers how Csper rolled out and now manages Content Security Policy on csper.io.

Building a policy

Csper built its original content security policy before the generator extensions existed. Otherwise we would have the extensions for generating a baseline content security policy.

Instead Csper used the "Policy Builder" feature within Csper to generate a policy. Under the hood the "Policy Builder" tool uses the same technology as the generator extensions.

The policy builder takes CSP violation reports for a website and automatically builds a new policy. It uses best practices to keep the policy secure (e.g. use full paths on javascript/object sources, no unsafe directives, etc).

After this the policy was built, almost no work.

Inline content

Thankfully Angular and other SPA (single page app) frameworks are very CSP friendly! So there wasn't much work to move all inline scripts to their own files. I had to move google analytics to its own file, but that was about it.

At this point I had accumulated about 220 instances of inline styles in my HTML. I spent an afternoon moving all the inline styles to angular style sheets, but later found out that angular components pretty much require 'unsafe-inline' on the style src. If this was script-src obviously that would have been unacceptable, but with style-src it's not ideal, but not the end of the world. In the future I'd like to look more into this.

Content Security Policy:

Deploying

Csper's API server is written in GoLang. I set all my security headers together in the same HTTP middleware:

func SecurityHeaders(next http.Handler) http.Handler {
  cspReportURI := config.GetConfig("CSP_ENDPOINT")
  return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
    w.Header().Add("Strict-Transport-Security", "max-age=31536000; includeSubDomains; preload")
    w.Header().Add("X-Content-Type-Options", "nosniff")
    w.Header().Add("X-Frame-Options", "DENY")
    w.Header().Add("X-XSS-Protection", "1; mode=block")
    w.Header().Add("Content-Security-Policy", "default-src 'self'; connect-src 'self' https://clouderrorreporting.googleapis.com wss://csper.io https://rs.fullstory.com https://stats.g.doubleclick.net https://www.google-analytics.com; font-src 'self' data: https://fonts.gstatic.com; frame-src 'self' https://charts.mongodb.com https://js.stripe.com https://www.youtube.com; img-src 'self' data: https:; object-src 'none'; script-src 'report-sample' 'self' https://edge.fullstory.com/s/fs.js https://js.stripe.com/v3/ https://www.google-analytics.com/analytics.js https://www.googletagmanager.com/gtag/js; style-src 'report-sample' 'self' 'unsafe-inline'; base-uri 'self'; report-uri "+cspReportURI+";")
    next.ServeHTTP(w, r)
  })
}

Dev, Stage, Production

Content Security Policy is really good at blocking things. Unfortunately it seems most of the time it blocks content you don't want it to block.

For this reason it's super important to keep Content Security Policy installed on all development environments (dev, stage, qa, prod), and keep all policies as closely related to production. As you might have noticed in the code above, I pull out the CSP_ENDPOINT from configuration, and it's the only thing that changes between environments.

This way I don't get any surprises as I deploy code to production. Issues are detected in development/staging.

I also check the organization dashboard to see how all the environments look before doing a deploy. I make sure there aren't any new reports in dev/stage.

(There is one slight lie, I use angular's ng serve on development instead of the golang server, and it's a little tricky to set headers, so I actually use a chrome extension to pin my policy locally instead of the golang server. I just use this CSP extension I wrote like 5 years ago.)

Alerts

To double ensure that issues don't happen when I push a commit to production, I use Csper's alerting functionality.

Csper has a feature where it'll check for both (1) reports that have never been seen before (2) a spike of alerts.

I keep these alerts on for all my environments (dev, staging and prod). This helps ensure that I don't miss anything before deploying new features to production.

Inspecting Reports

Sometimes I poke through the reports I get, and Csper's dashboard makes this very easy. Browsers can sometimes report some very interesting reports.

The dashboard can zoom on a specific report. This is useful because sometimes a report is only fired by one specific browser, or at a specific path in the application:

And if it's really necessary, Csper stores all the raw reports (without any modifications), so they can be inspected / downloaded at any time:

XSS Detection

We also take advantage of Csper's XSS alerting. I sadly haven't seen any real attempts on Csper (although I inject two fake XSS's in Csper on every page load, if you open up your browser's dev console you'll see the alerts. This is just so I can see how different browsers report inline content).

And that's not to say people don't try injecting XSS's into Csper. Csper is listed on https://www.openbugbounty.org/bugbounty/csper_io/, and I think I spend 30 minutes a day cleaning up fake XSS accounts so my user count / DAU numbers aren't skewed.

But in the event an XSS is attempted, a csp report violation will be fired, and an email sent. The XSS alert only fires on reports that have a classification of "inline, eval, or injected", with a directive of "script-src" or "object-src" and only on browsers that were released in the last year. This significantly) cuts back on false positives.

Conclusion

I hope this was useful. We try to keep things simple, and let our tools do the work for us.

If you have any questions or comments feel free to reach out! stuart at csper.io

Stuart