In one paragraph
CSP base-uri missing means the enforcing policy does not provide the document-base restriction this check expects. An injected base element can change how relative URLs resolve, potentially redirecting trusted loads or form destinations. Add base-uri 'none' when no base element is required, or a justified source list when it is. default-src does not supply this protection.
Why it matters
The HTML base element changes the document's base URL. Relative links, resource references, and form actions may then resolve somewhere different from the page's own address. If an attacker can inject such an element, the application's otherwise trusted relative URLs may become part of an attack.
This is especially relevant to nonce-authorised scripts with relative src values: the nonce may authorise the script element even when an injected base changes its destination. Exploitability depends on the injection opportunity, element placement, effective policy, and other controls. A missing directive alone does not prove a working exploit.
base-uri is not a fetch fallback inherited from default-src. A strict-looking policy can still leave it unspecified. It also differs from form-action, which directly restricts form destinations, and frame-ancestors, which governs who embeds the document.
How WebAuditOS evaluates this finding
The supplied rule inspects enforcing CSP headers on HTML. At least one policy with base-uri and no wildcard satisfies the described check. If none supplies that condition, it warns. No enforcing header or a non-HTML response is not graded.
It reads directive names rather than incidental strings in a reporting URL. Report-only and meta policies are outside this check's input. A broad scheme source such as https: can pass even though it permits many hosts. Presence without a literal wildcard is not proof of a well-restricted base URL.
How to fix it
- Inspect the final document's enforcing CSP and any additional policies. A CDN and application can each supply one. Determine whether the warning reflects a genuinely absent restriction or a scanner limitation.
- Search templates and rendered markup for base elements. Check public pages, documentation builds, and single-page applications served from a subpath. Understand whether any required element defines href, target, or both; base-uri specifically restricts base URLs.
- If no base href is required, add the restrictive directive to your existing policy:
Content-Security-Policy: base-uri 'none'This line illustrates the directive, not a replacement for a complete policy. Keep your existing script restrictions, resource directives, and reporting configuration intact.
- If same-origin base URLs are legitimate, consider base-uri 'self'. A base href such as /app/ remains same-origin and can be allowed by that policy. Add an external origin only when it is actually necessary and trusted.
- Test the complete candidate in report-only mode before changing enforcement on an existing application. Verify that legitimate relative navigation, scripts, styles, and form submissions still resolve correctly. Do not replace a real application requirement with a broad scheme permission merely to silence a warning.
- Publish the directive in the enforcing response header. Multiple policies remain cumulative; a second permissive policy cannot loosen another's restriction. Meta-delivered enforcement may work in browsers for this directive but will not satisfy the documented header-only check.
- Inspect the browser Console and effective document.baseURI in representative routes. Where authorised, test a deliberately disallowed base in staging and confirm its href is rejected. A rejected base does not mean the document's other injection paths are secure.
- Rescan and retain a regression check around the policy. Re-evaluate the directive when changing deployment paths or introducing a theme that adds a base element.
What the fix can break
A blocked base href is ignored, so relative URLs can resolve against the document URL instead. Subpath applications may therefore load incorrect assets or navigate to unexpected routes if their required base is disallowed.
Using 'none' can be appropriate for most ordinary documents, but it must not be copied over a legitimate application requirement without testing. Conversely, 'self' does not express every possible path-level intention just because it keeps the origin fixed.
This change does not sanitise injected HTML. Keep the code-level injection fix and other relevant CSP directives in place even after the warning clears.
Questions
Does default-src 'self' restrict base-uri?
No. base-uri requires its own directive. The fetch fallback is not a default for every CSP control.
Should I choose self or none?
Use 'none' if no base href is needed. Use a justified source list, often 'self', when a legitimate base URL is required.
Why did base-uri https: pass?
The supplied check rejects a literal wildcard but does not fully assess source tightness. Scheme-wide permission is much broader than a specific origin.
What related pages should I review?
Review missing default-src, object-src, and the security headers guide.