Real-World CSP Implementation: Lessons From Client Sites

The Part That Changed My Mind

I used to think Content Security Policy was mostly a header-writing problem.

Then I started working with real client sites.

The hard part was not learning what script-src means. The hard part was figuring out which scripts were truly needed, which ones were leftovers from an old marketing campaign, which ones were being loaded by a tag manager, and which ones only appeared when a logged-out visitor submitted a form on mobile.

That is where CSP becomes less like a checklist and more like site assurance work. You are not just trying to make a scanner happy. You are trying to protect the site without breaking the parts that make money, collect leads, or help the client serve customers.

Report-Only Is Not Optional

If a site is already in production, I do not start by enforcing a strict CSP. I start with report-only mode.

Report-only lets the browser tell you what would have been blocked. That gives you a map of the site's real behavior before you start affecting visitors.

This is especially important for agencies. A client site may have dozens of templates, old landing pages, seasonal forms, tracking pixels, popup tools, embedded videos, and checkout states that are not obvious from the homepage. If you enforce first and investigate later, you can turn a security improvement into a support incident.

What I Inventory Before Tightening CSP

• Home page and primary landing pages
• Lead forms, quote forms, booking forms, and newsletter forms
• Login, account, cart, checkout, donation, and payment flows
• Google Tag Manager, analytics, ads, pixels, heatmaps, chat, reviews, cookie banners, and embedded media
• Fonts, image CDNs, script CDNs, API endpoints, and browser beacon endpoints
• Pages rendered by page builders or special campaign templates
• Mobile views, because the broken thing is often hiding behind a different menu, popup, or form state

Third-Party Scripts Are Product Decisions

Most CSP pain comes from third-party tools.

Analytics loads more analytics. Tag managers load tags you did not know were still active. Payment providers require frames and scripts from several domains. Chat widgets add connections, styles, images, and sometimes more scripts. A/B testing tools inject markup by design.

The wrong move is to approve every source that appears in the reports. Frequency does not equal trust. A source can show up a thousand times because it is important, or because a bad script is on every page.

The better move is to ask what business purpose the source serves. If nobody can explain why it is there, it should not automatically get a permanent place in the policy.

Where WordPress Makes CSP Harder

• Plugins add scripts and styles on pages you may not expect.
• Page builders and themes often rely on inline styles.
• Form plugins may call spam checks, CRM endpoints, payment providers, or analytics tools during submission.
• WooCommerce checkout can involve scripts, frames, redirects, and API connections from multiple vendors.
• Tag managers can change the site's runtime behavior without a code deployment.
• Plugin updates can introduce new domains after the CSP was already working.

The Inline Script Decision

Inline JavaScript is where a lot of CSP projects get stuck.

For new code, I try to move behavior into external JavaScript files and avoid inline event handlers. For existing applications, there is usually a transition period. You may need nonces for server-rendered inline scripts, hashes for stable inline snippets, or a temporary exception while old code is being cleaned up.

What I try not to do is leave unsafe-inline in script-src forever and call the job done. Sometimes you need a temporary compromise. The important part is to name it as temporary, monitor it, and keep reducing it over time.

A Rollout That Has Worked Better For Me

• Start with report-only on the whole site.
• Group violations by directive, blocked source, page, browser, and business flow.
• Mark sources as required, questionable, suspicious, or cleanup.
• Tighten low-risk directives first, such as object-src, base-uri, and frame-ancestors.
• Handle form-action and connect-src carefully because forms, checkout, CRMs, maps, and analytics often depend on them.
• Move script-src toward nonces or hashes instead of relying on unsafe-inline.
• Test the site like a visitor: submit forms, complete checkout, use search, open menus, accept cookies, and check mobile.
• Switch to enforcement only when the important paths have clean evidence.
• Keep monitoring after launch so plugin, tag, and vendor changes do not quietly invalidate the policy.

A Simple Before And After

# Early discovery
Content-Security-Policy-Report-Only:
  default-src 'self';
  script-src 'self' https: 'report-sample';
  style-src 'self' 'unsafe-inline' https:;
  img-src 'self' data: https:;
  connect-src 'self' https:;
  form-action 'self';
  report-uri https://example.com/csp-reports;

# Later enforcement
Content-Security-Policy:
  default-src 'self';
  script-src 'nonce-{RANDOM_PER_RESPONSE}' 'strict-dynamic';
  style-src 'self' 'unsafe-inline' https://fonts.googleapis.com;
  img-src 'self' data: https://cdn.example.com;
  font-src 'self' https://fonts.gstatic.com;
  connect-src 'self' https://analytics.example.com https://api.example.com;
  object-src 'none';
  base-uri 'none';
  frame-ancestors 'self';
  form-action 'self' https://payments.example.com;

A useful CSP usually becomes stricter in phases. The exact domains depend on the site, but the direction should look something like this.

What Good Monitoring Changes

Good monitoring changes the tone of the work.

Without monitoring, CSP feels like guesswork. You deploy a header, click around for a while, hope nothing important broke, and wait for someone to complain.

With monitoring, you can see whether the blocked behavior is browser-extension noise, an expected tool that needs a policy update, a broken client workflow, or something suspicious. You can also connect a new violation to a recent plugin update, theme change, tag manager edit, or deployment.

That is the difference between raw security data and actual agency assurance. The goal is not to stare at CSP reports all day. The goal is to know when the evidence points to a client-site problem that deserves action.

How I Explain CSP To Clients

• CSP helps the browser reject scripts and connections the site did not approve.
• Some plugins and marketing tools need policy changes before enforcement.
• Report-only mode lets us see what would break before visitors are affected.
• A blocked checkout script matters more than a one-off browser extension report.
• After the policy is enforced, monitoring needs to stay on because the site will keep changing.

The Lesson

Real-world CSP implementation is less about perfection and more about disciplined reduction of risk.

Start by learning what the site really does. Protect the highest-impact pages first. Be suspicious of mystery scripts. Treat report-only data as evidence, not noise. And once the policy is live, keep watching it like the site is going to change, because it absolutely will.