Use Content Security Policy headers

[ekzyis]

In https://github.com/stackernews/stacker.news/pull/749#discussion_r1457813585, the planned usage of CSP was mentioned:

Regardless of these changes even, we should introduce really strict Content Security Policies to narrow the XSS attack surface. For browsers that don't support CSP we should consider preventing storing/using secrets clientside.

Created this separate ticket since it's not necessarily related to #749 since deploying CSP also makes sense on its own.

Also, this ticket can act as a dedicated place for discussion around CSP.

For example, I have read about Content-Security-Policy-Report-Only. This allows us to rollout CSP and monitor the app (via console or via actual reports sent to an endpoint) before we enforce the rules:

Testing your policy To ease deployment, CSP can be deployed in report-only mode. The policy is not enforced, but any violations are reported to a provided URI. Additionally, a report-only header can be used to test a future revision to a policy without actually deploying it.

---

References:

• https://nextjs.org/docs/pages/building-your-application/configuring/content-security-policy
• https://infosec.mozilla.org/guidelines/web_security#content-security-policy
• https://web.dev/articles/csp
• https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html
• https://github.com/vercel/next.js/discussions/54907
• https://reesmorris.co.uk/blog/implementing-proper-csp-nextjs-styled-components
• https://webpack.js.org/guides/csp/
• https://csp-evaluator.withgoogle.com/

[ekzyis]

There is also Strict-Transport-Security:

The HTTP Strict-Transport-Security response header (often abbreviated as HSTS) informs browsers that the site should only be accessed using HTTPS, and that any future attempts to access it using HTTP should automatically be converted to HTTPS.

There is even a site from Google to request inclusion in their HSTS preload list: https://hstspreload.org/

This form is used to submit domains for inclusion in Chrome's HTTP Strict Transport Security (HSTS) preload list. This is a list of sites that are hardcoded into Chrome as being HTTPS only.

Most major browsers (Chrome, Firefox, Opera, Safari, IE 11 and Edge) also have HSTS preload lists based on the Chrome list. (See the HSTS compatibility matrix.)

However, we shouldn't request inclusion without carefully thinking about it:

Preloading Should Be Opt-In If you maintain a project that provides HTTPS configuration advice or provides an option to enable HSTS, do not include the preload directive by default. We get regular emails from site operators who tried out HSTS this way, only to find themselves on the preload list by the time they find they need to remove HSTS to access certain subdomains. Removal tends to be slow and painful for those sites.

Projects that support or advise about HSTS and HSTS preloading should ensure that site operators understand the long-term consequences of preloading before they turn it on for a given domain. They should also be informed that they need to meet additional requirements and submit their site to hstspreload.org to ensure that it is successfully preloaded (i.e. to get the full protection of the intended configuration).

So this is more just a FYI. We can use HSTS without adding the preload flag.