In one paragraph
A missing CSP default-src directive means resource types without another applicable fetch directive may have no CSP source restriction. Existing specific directives still work, so this is not automatically a broken policy. Add a deliberate fallback, test the resource types it will affect, and explicitly configure directives such as base-uri and frame-ancestors that do not inherit from default-src.
Why it matters
Content Security Policy defines source restrictions for different resource categories. script-src governs scripts, img-src images, and connect-src connections such as fetch and WebSockets. default-src provides a fallback for fetch directives when a more specific applicable rule is absent.
Without that fallback, omitted resource categories can remain unrestricted by CSP even when scripts are tightly controlled. For example, a policy focused only on script-src may leave connections, frames, media, and fonts without relevant source restrictions. Other browser rules still apply: unrestricted by CSP does not mean unrestricted by the browser in every respect.
Fallbacks are not merged source lists. If img-src is declared, its list replaces the default-src fallback for images; permitted sources do not automatically combine. Some categories also have intermediate fallback rules, such as workers, so evaluate the effective directive rather than searching for one string.
Most importantly, default-src does not configure every security decision. frame-ancestors, base-uri, and form-action require explicit directives. Adding default-src 'none' does not by itself stop other sites framing the page or restrict form submission destinations.
How WebAuditOS evaluates this finding
The supplied check passes a policy containing default-src and warns when it is missing. A page without an enforcing CSP is not graded here. With several enforced policies, the documented check expects the directive in each policy, even though one restrictive policy can already impose a browser-enforced fallback. A warning in that situation does not prove the effective restrictions are absent.
How to fix it
- Read every enforcing CSP on the final HTML response. Identify explicit fetch directives and the resource types currently relying on fallbacks. Policies configured at the CDN and application can coexist and all be enforced.
- Inventory real dependencies. Include API requests, WebSockets, fonts, images, video, workers, and embedded providers across page types. The browser Network panel and CSP violation reports are useful evidence.
- Choose a baseline. default-src 'self' restricts inherited fetch categories to the document's own origin. default-src 'none' blocks inherited categories until you explicitly permit them. Neither value is automatically suitable for an existing site without testing.
- Add explicit exceptions only where required. This illustrative policy is for an application that loads its scripts and styles from the same origin and does not need framing, objects, or cross-origin resources:
Content-Security-Policy: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'; form-action 'self'It is not a universal production policy or a complete strict-script policy. Inline scripts, inline styles, external services, and other application features may require a different design. Preserve existing nonce or hash protections rather than replacing the full policy with this example.
- Deploy the complete candidate as Content-Security-Policy-Report-Only alongside the current enforced policy. Configure reports, test legitimate journeys, and distinguish real dependency violations from irrelevant extension activity. A quiet endpoint is not proof of safety unless you know reporting works.
- Update the enforced policy after resolving required resources. Check the Console and Network panel, repeat tests on infrequent page types, and then rescan the affected URLs.
- Verify non-inheriting directives separately. Use the intended frame-ancestors, base-uri, and form-action restrictions explicitly; do not assume the newly added fallback covers them.
What the fix can break
The fallback affects previously omitted resource categories. A blocked connect-src can stop API calls or WebSockets; a blocked frame-src can remove a checkout embed; fonts and media can disappear. These failures occur in the browser and may leave server monitoring green.
Adding default-src 'self' can also restrict inline scripts or styles when their applicable directives were previously absent. That can be a much broader change than the team expected from a fallback cleanup.
Avoid fixing violations by adding an unrestricted wildcard globally. Add required sources to the appropriate directive and keep the rest constrained. Check that rollback changes the enforcing header at the actual delivery layer, not merely an unused origin setting.
Questions
Does default-src 'self' mean all subdomains are allowed?
No. 'self' refers to the document's own origin, not every host owned by the same organisation. An asset or API subdomain may require an explicit source.
Does default-src override an explicit img-src?
No. The specific directive provides the source list for that category. It does not automatically add the fallback's sources to its own list.
Should I choose self or none?
Choose a policy you can implement and maintain. 'none' is a restrictive starting point that requires explicit permissions; 'self' can be practical for an existing same-origin application. Test either before enforcement.
Where should I go next?
Review missing base-uri, missing object-src, and the security headers guide. These explain related controls rather than duplicating the fallback finding.