Add Data Portal CSP and appropriate rules [after March 13]

[seve]

As a result of Enable HTTP Strict Transport Security and Content Security Policy (CSP) we have determined that our best route to deliver CSP is to insert a Lambda@Edge function in the flow from S3 -> CloudFront -> End User (Blog Post). This function should add any security headers that we need (CSP and HSTS).

Infra already has a cztack module for adding security headers, we can modify this to also include any CSP directives we need.

Pref impacts we can expect:

I suspect it shouldn’t be too bad if we do something in Go or a similar compiled language. My understanding of cold start times is that a lot of it is booting up the Lang runtime.
Logic itself should be simple enough that I doubt processing time will count for much latency
It’ll also be interesting to see what kind of caching CF can do with edge lambda responses

Steps:

• Determine all of our outside sources for styles, fonts, scripts, and the like
• Fork cztack, duplicate the aws-lambda-edge-add-security-headers module with a new name
• Tweak new module to handle CSP delivery when passed directives
• Add module to TF
• Customize CSP directives per env to be as strict as possible while allowing all current functionality
  • This will include generating hashes for all our inline scripts
    • Layout documentation to make future hash changes and CSP tweaks less of a headache
    • Create a util to help generate hashes for our inline scripts (cellxgene's approach) (Not a hard require as we don't have much churn but nice to have)

Example of cxg's CSP directives:

default-src 'self'; connect-src 'self' https://api.cellxgene.dev.single-cell.czi.technology sentry.prod.si.czi.technology; script-src 'self' 'unsafe-eval' 'sha256-/rmgOi/skq9MpiZxPv6lPb1PNSN+Uf4NaUHO/IjyfwM=' 'sha256-aFVmiBiEgb+j7fokN003RXrmU/RNz49S53HhxV5fz5k=' 'sha256-MNGq6g/W+e+I56VSp/4UlE6dco2np1gkQXt3QXmEZI4=' 'sha256-oLMCSQyznhZBx8IKrusN44c9jnJH0FtG6UK3yTK1a6M=' 'sha256-dV7DifXsTmaSy9g6Kz75qahvVKkX0cGwxfb6EfmwzUU=' 'sha256-MNGq6g/W+e+I56VSp/4UlE6dco2np1gkQXt3QXmEZI4=' 'sha256-oLMCSQyznhZBx8IKrusN44c9jnJH0FtG6UK3yTK1a6M=' 'sha256-dV7DifXsTmaSy9g6Kz75qahvVKkX0cGwxfb6EfmwzUU=' 'sha256-MNGq6g/W+e+I56VSp/4UlE6dco2np1gkQXt3QXmEZI4=' 'sha256-oLMCSQyznhZBx8IKrusN44c9jnJH0FtG6UK3yTK1a6M=' 'sha256-dV7DifXsTmaSy9g6Kz75qahvVKkX0cGwxfb6EfmwzUU=' www.google-analytics.com browser.sentry-cdn.com; style-src 'self' 'unsafe-inline'; img-src 'self' https://cellxgene.cziscience.com data: www.google-analytics.com; object-src 'none'; base-uri 'none'; frame-ancestors 'none'; upgrade-insecure-requests

---

Feel free to ping @seve for any clarification

TEAM COMMENTS

1. After deployment, check rating at: https://observatory.mozilla.org/analyze/cellxgene.cziscience.com

---

OUTDATED(12/10):

As a result of #626 we have determined that our best route to deliver CSP is to temporarily serve CSP directives via an HTML <meta> tag through Gatsby's gatsby-plugin-csp. Until we can serve via HTTP headers with our future platform that will be planned out in #765.

This work should be done before any features related to user input are no longer behind a feature flag

Steps:

1. Install and use gatsby-plugin-csp
2. Determine all of our outside sources for styles, fonts, scripts, and the like
3. Design util to generate hashes for unstable inline-scripts (cellxgene's approach)
4. Customize CSP directives per env to be as strict as possible while allowing all current functionality
5. Layout documentation to make future hash changes and CSP tweaks less of a headache

[seve]

Example of cxg's CSP directives:

default-src 'self'; connect-src 'self' https://api.cellxgene.dev.single-cell.czi.technology sentry.prod.si.czi.technology; script-src 'self' 'unsafe-eval' 'sha256-/rmgOi/skq9MpiZxPv6lPb1PNSN+Uf4NaUHO/IjyfwM=' 'sha256-aFVmiBiEgb+j7fokN003RXrmU/RNz49S53HhxV5fz5k=' 'sha256-MNGq6g/W+e+I56VSp/4UlE6dco2np1gkQXt3QXmEZI4=' 'sha256-oLMCSQyznhZBx8IKrusN44c9jnJH0FtG6UK3yTK1a6M=' 'sha256-dV7DifXsTmaSy9g6Kz75qahvVKkX0cGwxfb6EfmwzUU=' 'sha256-MNGq6g/W+e+I56VSp/4UlE6dco2np1gkQXt3QXmEZI4=' 'sha256-oLMCSQyznhZBx8IKrusN44c9jnJH0FtG6UK3yTK1a6M=' 'sha256-dV7DifXsTmaSy9g6Kz75qahvVKkX0cGwxfb6EfmwzUU=' 'sha256-MNGq6g/W+e+I56VSp/4UlE6dco2np1gkQXt3QXmEZI4=' 'sha256-oLMCSQyznhZBx8IKrusN44c9jnJH0FtG6UK3yTK1a6M=' 'sha256-dV7DifXsTmaSy9g6Kz75qahvVKkX0cGwxfb6EfmwzUU=' www.google-analytics.com browser.sentry-cdn.com; style-src 'self' 'unsafe-inline'; img-src 'self' https://cellxgene.cziscience.com data: www.google-analytics.com; object-src 'none'; base-uri 'none'; frame-ancestors 'none'; upgrade-insecure-requests

[ryanking]

I suspect it shouldn’t be too bad if we do something in Go or a similar compiled language. My understanding of cold start times is that a lot of it is booting up the Lang runtime.

The existing module uses javascript and is in production for along. I would suggest extending that (with javascript) for now. Once in production we can evaluate and see if performance is acceptable. If not we can manage a rewrite.

Fork cztack, duplicate the aws-lambda-edge-add-security-headers module with a new name

You don't need to fork, you should be able to push a branch to the cztack repo.

Add module to TF

If possible, I would prefer to add this as a new (optional) feature in the exiting module.

[tihuan]

Moving this back to the Product Backlog, since we need to work on Next.js migration this sprint first

If things go as planned, we can do this CSP ticket in the next sprint 😄💪

[tihuan]

Sync'd with @jgadling (Infra) on the timeline for deploying Nextjs to staging and prod, we're aiming for 3/13 for prod ECS cutover, so will only be able to merge this Nextjs branch into main after that.

In the meantime, I'll babysit this branch to sync with main and resolve conflicts accordingly!

[tihuan]

The Next.js migration PR is now merged! So we should be able to verify the CSP and HSTS are implemented correctly in staging 👍

[maniarathi]

Verified in prod, so closing!