Fix librarySecurity

Security

Close the gaps in the policy you already send

You send an enforcing Content-Security-Policy, but it leaves out directives that matter, so parts of the protection you think you have are not in force.

Why it matters

A content policy earns credit clause by clause: a switch-off for plugins and embeds, a rule for the base address, no blanket permission for inline scripts, and a bounded fallback for anything the policy does not name. Each missing clause leaves the matching door open, which is why a scan treats a partially hardened policy as unfinished rather than as done.

How you would notice it

  • A security scan describes your policy as present but incomplete.
  • The recommendation names directives such as object-src or base-uri.
  • A compliance review asks why the policy is missing specific clauses.

What to do

Stage 1Steps 1–2 · includes the code for this stage

  1. Read the recommendation text before touching anything: it names exactly which clauses your policy is missing, and each named clause maps to one directive in the policy value.
  2. Add the missing directives to the policy value. This example carries all four clauses.

    object-src none switches off plugins and legacy embeds. base-uri self stops injected markup from rewriting where links point. If your policy already carries a nonce, a hash, or strict-dynamic on the script directive, the inline-script clause is already satisfied and only the others need adding.

Code for this stage
# Cloudflare Pages or Netlify: put this in your headers file
/*
  Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'

# nginx, on a server you manage:
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'" always;

Stage 2Steps 3–4

  1. Send the updated policy from the same place as the old one: your host headers file, or your server configuration if you run one. Two policies sent from two places are both enforced, and the browser applies the stricter of each pair, which blocks more than either policy alone.
  2. Reload a few pages with the developer tools console open and confirm the policy is not now blocking something your site needs.

How to check it worked

Confirm it worked

Request an ordinary page and read the response headers; confirm the new directives arrived. Then check that styling and interactive elements still work, with no new blocked-resource messages in the console. Re-run the Siege Test and confirm the policy recommendation is gone.

Want this handled for you?

Bring your report to The Council and we will scope the repairs, the rebuild, or the full stronghold.