A Content Security Policy lacks object or base-address restrictions

Why it matters

web.dev's guide to a strict policy restricts object-src to disable dangerous plugins and base-uri to block the injection of <base> tags, and its example policy ends with object-src 'none'; base-uri 'none'.

What to do

1. Look at the finding: it shows the policy, which of the two is missing and up to ten pages that send it.
2. Add object-src 'none' if the pages use no plugins, and base-uri 'none', or base-uri 'self' if a page relies on its own <base> tag.

When to leave it as it is: if another enforcing policy on the same pages already sets these directives, you can leave it; the check reads each policy on its own.

What we read

We read the enforcing policies of each crawled page with our own user agent: each policy in a Content-Security-Policy response header, and a CSP <meta> tag inside <head>. Report-only headers are not read. Each policy is judged on its own, as it is written, not combined with the page's other policies the way a browser applies them.

A policy is reported when it has no object-src and no default-src, or when it has no base-uri, which has no fallback. Only the presence of the directives is checked, not their values, so default-src * counts as present. A page with no enforcing policy at all is outside this rule; the separate missing-policy check is deferred in the current audit.

Pages that send the same policy text are reported together, one finding per exact text; a policy that carries a new nonce on every response gives each page a finding of its own. Pages whose headers or HTML were not captured in full are not judged.

Example & evidence

Illustrative example — one policy, not a live audit.

https://bakery.example/ sends:

Content-Security-Policy: script-src 'self'

The policy has no object-src, no default-src and no base-uri, so it is reported with both gaps.

Content-Security-Policy: script-src 'self'; object-src 'none'; base-uri 'none'

A possible correction: the same policy with both directives added.

Confirm & check again

Check for yourself: open the page's response headers and look for object-src, default-src and base-uri in Content-Security-Policy.

Check again: Full audit — run a new full audit. With complete coverage, this policy-text finding closes only when no currently crawled page sends the same flagged policy text; a new page using the old text keeps it open. Adding the directives creates a new policy text to evaluate. Removing the policy can also remove this policy text; the separate missing-policy check is currently deferred, so this does not establish adequate protection.

Limits & sources

The check sees whether the directives exist, not how strict they are. Each policy is judged alone, so a directive in a second enforcing policy does not clear it, and browser behaviour is not measured.

Confidence: High because the policy text is read directly.

Sources

• web.dev, Mitigate cross-site scripting (XSS) with a strict Content Security Policy (CSP) — restricts object-src to disable dangerous plugins and base-uri to block the injection of <base> tags. Checked 28 September 2026.

Editorial review: 2 November 2026

Related

• A Content Security Policy lists broad script or object sources — the directives exist but allow whole schemes or any host.
• Pages have no Content Security Policy — the separate check for no enforcing policy at all; currently deferred in the audit.