[MAGNOLIA-8141] Facilitate CSP headers configuration for projects Created: 27/Dec/19  Updated: 02/Jan/23

Status: Accepted
Project: Magnolia
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Neutral
Reporter: Mikaël Geljić Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: security
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
duplicate
relation
Template:
Acceptance criteria:
Empty
Date of First Response:
Epic Link: Product improvements for Cloud project features

 Description   

Currently, projects are on their own setting Content-Security-Policy header (and adjacent -Report-Only), by manipulating the filter-chain, and adding a AddHeadersFilter, as shown in the docs.

This is error-prone, global to all sites, and supports only static behaviors with pre-configured fixed values. And is way too far from project (light) development.

We should do the same as we did for CORS (MAGNOLIA-7215 and MGNLSITE-101):

  • Add a domain-specific CspFilter implementation in core (impl-detail), capable of adding CSP (and CSPRO) headers based on filter self-config.
  • Extend it with a SiteAwareCspFilter in site-module, reading CspConfiguration from the Site definition (clone ticket when doing so).

This will allow projects to set it in YAML site-defs (still done via site module-config decoration to this date).

Out of scope:

  • for editors to fill-in the values (too technical for them anyway)
  • HSTS (may clone ticket at convenience)

Original description (cloud-specific) from dlopez

The default CSP header value coming from magnolia-now-configuration (cloud bundle) doesn't work out for projects out of the box. As a matter of fact, the tendency is to switch it off.

The topic is recurrent for any project doing penetration tests.



 Comments   
Comment by Espen Jervidalo [ 11/Mar/20 ]

IMO, this ticket should be about enabling CSP header configurations outside of the FilterChain. Could we move the actual configuration to a module's config node and inject it into the Filter? This would allow light-development on a project basis. And this is something that needs to be adapted per project.

And for suggestions. That's a nice to have, but not a necessity..

Generated at Mon Feb 12 04:30:01 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.