Set the form-action directive in the report-only CSP

[robhudson]

Summary

This PR introduces the form-action directive to the report-only Content Security Policy (CSP) header. The goal is to test and evaluate its compatibility before eventually applying it to the enforced CSP header. The form-action directive restricts where forms on the site can send their data upon submission, adding an additional layer of security to prevent potential vulnerabilities.

Why form-action is Important for Security

The form-action directive is a key security measure designed to mitigate attacks that exploit form submissions, such as:

• Phishing and data exfiltration attacks: Prevents malicious actors from redirecting form submissions to unauthorized or external servers.
• Clickjacking: Works in tandem with other CSP directives to ensure that embedded forms are protected.
• Cross-site scripting (XSS) risks: Reduces the attack surface by limiting submission endpoints, even if an attacker manages to inject a form.

By specifying trusted domains or paths for form submissions, form-action ensures that forms behave only as intended and cannot be abused for unauthorized data capture.

Next Steps

1. Deploy the change and monitor CSP violation reports for any issues related to form-action.
2. Refine the directive based on findings from the report-only stage.
3. Once confident, apply the directive to the enforced CSP header to fully benefit from its security enhancements.

References

• MDN Documentation on form-action

• I used an AI to write some of this code.

Issue / Bugzilla link

#15553 (from #11943)

Testing

• Verify the addition of the form-action directive in the report-only CSP header locally.
  • To do this we need to set a couple local env vars:
    • DEBUG=False - CSP headers aren't added while in DEBUG mode
    • CSP_RO_REPORT_URI=/csp-violation - the report-only header will only be added if this is set.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 78.96%. Comparing base (33115aa) to head (572113c).

Additional details and impacted files

@@           Coverage Diff           @@
##             main   #15554   +/-   ##
=======================================
  Coverage   78.95%   78.96%           
=======================================
  Files         158      158           
  Lines        8293     8294    +1     
=======================================
+ Hits         6548     6549    +1     
  Misses       1745     1745           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

---

🚨 Try these New Features:

• Flaky Tests Detection - Detect and resolve failed and flaky tests
• JS Bundle Analysis - Avoid shipping oversized bundles

[stevejalim]

question: FXA_ENDPOINT has a trailing slash and BASKET_URL does not. Is that gonna cause any wrinkles or is CSP smart enough to strip trailing slashes?

[robhudson]

Thanks for noticing that. The browser, from what I've read, doesn't really differentiate, so this should be fine. But I'm a fan of consistency so perhaps I'll add some trailing slash stripping.

[janbrasna]

NB: The slash has a function in CSP wrt to being a path component (i.e. an implicit wildcard after it) or not.

[janbrasna]

ref: https://w3c.github.io/webappsec-csp/#path-part-match
see: https://bugzilla.mozilla.org/show_bug.cgi?id=741019#c25

[robhudson]

Looking at the CSP path-part-match rules more closely...

1. With https://example.com/ in our CSP, a form submit to https://example.com/ matches.
2. With https://example.com in our CSP (no path), a form submit to https://example.com/ matches, since when split on '/', the path is empty string.

And vice-versa for the form submit to the non-slash URL.

Focusing on the BASKET_URL, however, reading the path-part-match rules @janbrasna mentioned, we would want the trailing slash for the basket URL. Without the trailing slash it is in "exact match" mode and a form submit to an actual path would fail. In the comment above I was just looking at the FXA_ENDPOINT in our code where we don't use any path.

So the slash is important, just not necessarily if we're submitting to "" vs /.

@janbrasna - does that "match" your understanding of it?

[janbrasna]

Yup… and I was only looking at FXA_ENDPOINT and CJMS_AFFILIATE_ENDPOINT for another rule, which is either a wildcard, or a particular endpoint only.

OTOH for Basket the easy way might be setting the form action CSP rule as f"{BASKET_URL}/news/" to match the existing code? (And make it even more specific? Or are there even more endpoints that I'm not aware of?)

[robhudson]

I'm working on adding some more basket APIs under /api/. So I'd probably keep that one at the root level for now. Then again, the ones under /api/ are more for javascript, not form submits.

[stevejalim]

r+wc