Add content security policy to web app headers

[exalate-issue-sync]

See https://guides.18f.gov/engineering/security/content-security-policy/

QA Notes

null

DEV Notes

The [Angular security best practices documentation|https://angular.dev/best-practices/security#content-security-policy] recommends adding {{ngCspNonce}} to our index.html with a unique nonce per load and sending the corresponding header (their alternative approach is for applications that plan to cache index.html which we do not currently do, but can be considered if we ever start doing this).

[This Medium article|https://medium.com/@dinesh_here/dont-let-your-angular-app-be-a-target-secure-it-with-csp-angular-16-aaec22645a4c] suggests a basic approach for implementing this via nginx when the web-app is served. Namely, the following lines are added to replace the random_nonce_value in the web-app with the generated value:

{{sub_filter_once off;}}
{{sub_filter random_nonce_value ;}}

In addition, we will need to send this down in the CSP header per Angular’s best practice :

{noformat}default-src 'self'; style-src 'self' 'nonce-randomNonceGoesHere'; script-src 'self' 'nonce-randomNonceGoesHere';{noformat}

This will require verification of the nonce for any scripts and styles loaded that are not served from our nginx domain.

Additionally, we may want to add the following CSP entries:

{{frame-ancestors ‘none';}}([protects against clickjacking attacks|https://owasp.org/www-community/attacks/Clickjacking#defending-against-clickjacking])

{{object-src 'none';}} (per [MDN recommendation|https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/object-src])

!image-20250116-175540.png|width=727,height=162,alt="image-20250116-175540.png"!

{{base-uri ‘none';}} (per [MDN 'strict csp’ recommendation|https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP#strict_csp] to prevent elements from setting the base URI)

This ticket should also include work to add a reporting endpoint in the API for logging CSP failures within both the app and api.

This ticket will also include significant development testing including:

• smoke testing app/api locally and add local csp headers as needed
• manually breaking CSP locally and testing to document failure behavior.
• manually breaking CSP and running e2e tests to verify e2e tests fail
• testing app/api CSP in dev and with cloud.gov via manual deploy
• verify e2e tests passing

Design

null

See full ticket and images here: FECFILE-1908

[exalate-issue-sync]

akhorsand commented: [~accountid:712020:2a1493e5-adee-45bd-b27e-868a5c8d3f62] [~accountid:5b92c509d0b4022bdc51bdf4] if this is adding something to the headers, then can we get BAs and design involved? Or is this something more technical? What is the link for?

[exalate-issue-sync]

Todd Lees commented: [~accountid:61b0b42cd5986c006a9e1c94] I can work on updating this ticket. “headers” here refers to HTTP headers and not the ui page layout “header”. The ticket is to implement a security measure for the requests between the frontend app and the server. The link explains what the measure is and how to use it.

[exalate-issue-sync]

David Heitzer commented: When testing the recommended CSP in dev, we can into [this known requirement with the AJV library|https://ajv.js.org/security.html#content-security-policy]

Since our json validation relies on the AJV library, we will need to implement their recommendation to [compile json schemas during build rather than at runtime approach|https://ajv.js.org/standalone.html]. This will require a change to our validation mechanism in the app.