Skip to content
This repository has been archived by the owner on Dec 23, 2020. It is now read-only.

Memo for developing a content security policy #336

Open
LarryBafundo opened this issue Nov 30, 2017 · 4 comments
Open

Memo for developing a content security policy #336

LarryBafundo opened this issue Nov 30, 2017 · 4 comments
Assignees

Comments

@LarryBafundo
Copy link
Contributor

LarryBafundo commented Nov 30, 2017

Mike asked us to develop a memo (bullet points are fine) that explain what a content security policy is (CSP), why its important, and high-level recommendations for developing one.

I'm not sure what the timeline is, but he said it would help inform their ATO process.

@jeremiak let me know if we need more specifics, or if you would like to reach out to Mike directly.

@jeremiak
Copy link
Contributor

jeremiak commented Dec 1, 2017

Lifted from the 18F front end guide regarding CSPs:

What is Content Security Policy?

Content Security Policy (referred to as CSP in the rest of this guide) is a security measure designed by the W3C (World Wide Web Consortium) to mitigate the likelihood of Cross-Site Scripting (XSS) attacks and data injection. It is designed to be used in conjunction with other security practices currently recommended for web development.

It can be enabled on either client- or server-side, and is unobtrusive in unsupported browsers — that is, browsers that don't support CSP will ignore its directives and load the page as normal.

CSP is supported by the current versions of all modern desktop browsers: Safari, Chrome, Firefox, and IE Edge. It is also supported in recent versions iOS Safari and Chrome for Android.

Unfortunately, support for numbered versions of IE is essentially zero, with no support for IE < 10 and only two directives supported in IE 10+.

We should implement this, at least in the front end application. It is a relatively straightforward task and should be quick. Essentially, we want to tell the browser which URLs it is OK to load content on the Crime Data Explorer from. Currently, we get almost all of the assets and data from the same host as the application (crime-data-explorer.fr.cloud.gov) which is easy to restrict.

There are a few resources that come from different URLs, all of which we can add to our whitelist:

  • "google-analytics.com" because of DAP
  • "crime-data-api.fr.cloud.gov" to get the swagger.json used for generating the API documentation

I am unsure if the downloads from S3 will continue to work with a CSP, but if not, we can also add that host to our whitelist.

The API application doesn't have any HTML that is returned but we should still use a CSP to restrict the content a browser might load at the URL. I can open the relevant issues for these two tasks in the respective repos.

@LarryBafundo
Copy link
Contributor Author

thanks @jeremiak

@jeremiak
Copy link
Contributor

jeremiak commented Dec 19, 2017

Both of the technical fixes have been done and merged but they still need to be released. @LarryBafundo maybe we can push for a release at the end of this sprint and have Cindy review everything? We can always push it out earlier than the end of the sprint if desired.

Was there any feedback from Mike about how this might affect the ATO timeline?

@LarryBafundo
Copy link
Contributor Author

sounds good, let's aim for the end of this sprint

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants