Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add base-uri Directive to Content Security Policy #15555

Open
Tracked by #11943
robhudson opened this issue Nov 22, 2024 · 5 comments
Open
Tracked by #11943

Add base-uri Directive to Content Security Policy #15555

robhudson opened this issue Nov 22, 2024 · 5 comments

Comments

@robhudson
Copy link
Member

robhudson commented Nov 22, 2024

Description

This issue proposes adding the base-uri directive to our Content Security Policy (CSP) to enhance security by controlling the base URL used for resolving relative URLs in our web application. The base-uri directive restricts where <base> elements can point, helping mitigate certain types of injection attacks and preventing the unintended manipulation of relative URL resolution.

Why Add base-uri?

  1. Mitigates Injection Attacks:

    • Attackers may attempt to inject a malicious <base> element into the HTML document, redirecting relative URLs (e.g., links, resources) to an unauthorized or malicious domain.
  2. Improves Application Integrity:

    • Ensures that all relative URLs resolve to trusted origins, maintaining control over URL resolution behavior.
    • Protects user experience and data by preventing exploitation of relative links.
  3. Aligns with Security Best Practices:

    • Adding base-uri to CSP strengthens the policy against attacks targeting URL resolution, complementing other directives like script-src and form-action.
@robhudson robhudson changed the title Investigate adding base-uri Add base-uri Directive to Content Security Policy Nov 22, 2024
@janbrasna
Copy link
Contributor

There don't seem to be any <base> elements set visibly from a quick search, and I also don't recall any env settings to inject it for some deployments (e.g. don't see it being used even in test.bedrock.nonprod.webservices.*) so the goal is perhaps to set it to 'none', right?

The public facing site should be fine, question is whether Wagtail doesn't need that for anything, but the only base use I can spot is in targets for opening new windows, so a RO test-drive should surface any violations, but hopefully there would be none. 🤞

@stevejalim
Copy link
Collaborator

Just an FYI but <base> appears to be used in Wagtail's internal live preview panel (see this image as an example)

wagtail/wagtail@54597bb

So if we do add it, please can we double-check that in-CMS previews still work fine.

@janbrasna
Copy link
Contributor

Noticed this exact use before and it should have no impact: <base target> is not affected by restricting base href, and its possible vectors were decided to be addressed elsewhere so it seems like no target changes are planned in CSP for the foreseeable future.

@robhudson
Copy link
Member Author

There don't seem to be any elements set visibly from a quick search

There aren't but this also protects if a malicious script were to dynamically add a <base> target to the page affecting any forms or other elements on the page that may use relative addressing.

@janbrasna
Copy link
Contributor

There don't seem to be any elements set visibly from a quick search

There aren't but this also protects if a malicious script were to dynamically add a <base>

Right, I meant it as if we need to support any pre-existing values, or a wholesale NONE would suffice.

I went with 'none' in #15580 for now.

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

No branches or pull requests

3 participants