[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: |
|
||||||||||||
| 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 (
This will allow projects to set it in YAML site-defs (still done via site module-config decoration to this date). Out of scope:
Original description (cloud-specific) from dlopezThe 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.. |