Content Security Policy for Non-Developers: A Plain-English Guide

# Content Security Policy for Non-Developers: A Plain-English Guide

If you run a small business website and you've heard the phrase "Content Security Policy" tossed around by a developer, a security scanner, or your hosting provider, you probably nodded politely and hoped it would go away. It won't. CSP is one of the most effective ways to stop a hacked site from stealing your customers' credit card numbers, hijacking your contact forms, or showing visitors fake login pages.

This guide is written for the person who owns the site, not the person who codes it. By the end, you'll know what CSP does, when you actually need it, how to add a basic one without breaking your site, and what to do when something does break.

What CSP Actually Does (in One Paragraph)

Your website loads stuff from lots of places. Your own server hosts the main pages, but Google Analytics tracks visitors, Stripe handles payments, a chat widget chats, Mailchimp captures emails, and maybe a Facebook pixel runs in the background. Each of those is a "source." A Content Security Policy is a short list of approved sources you give the browser. The browser then refuses to load anything that isn't on the list. If an attacker manages to inject a sneaky script tag onto your contact page, the browser sees the script came from a domain you never approved, and blocks it. That's the entire point.

Why a Small Business Site Needs This

You might think CSP is for banks and enterprise platforms. It isn't. The most common targets of script injection are not big companies with security teams. They are small business sites running outdated WordPress plugins, abandoned Shopify themes, or custom code written by a contractor three years ago. Attackers scan the web automatically. If your site has a known vulnerability, you will be found.

Without CSP, an attacker who finds even a tiny opening can:

• Inject a fake checkout form that captures credit card details
• Load a cryptocurrency miner that runs while customers browse
• Redirect mobile visitors to a phishing page
• Steal session cookies and impersonate logged-in users
• Replace your contact form with one that emails leads to a competitor

With a properly configured CSP, most of those attacks fail silently in the browser. The injected script tries to load, the browser checks the policy, and the load is refused.

The Two Ways CSP Gets Delivered

There are two technical ways a CSP reaches the browser, and you should know the names because your hosting support team will use them.

HTTP header: The server sends a Content-Security-Policy header with every page response. This is the preferred method.

Meta tag: A tag is added in the page's HTML head. This works for static sites or platforms where you can't easily edit headers, but it's slightly less powerful (some directives like frame-ancestors are ignored) and slightly slower, because the browser has already started parsing before it sees the rule.

Most managed platforms — Shopify, Squarespace, Webflow, modern WordPress hosts — let you set headers either through a settings panel or through a plugin. If yours doesn't, the meta-tag approach still works.

The Anatomy of a CSP, Without the Jargon

A CSP is a single line of text made up of "directives." Each directive tells the browser what's allowed for one type of resource.

Here is a beginner-friendly example for a typical small business site that uses Google Analytics, Stripe, and a Mailchimp form:

default-src 'self';

script-src 'self' https://www.googletagmanager.com https://js.stripe.com;

style-src 'self' 'unsafe-inline';

img-src 'self' https: data:;

connect-src 'self' https://www.google-analytics.com https://api.stripe.com;

frame-src https://js.stripe.com;

font-src 'self' https://fonts.gstatic.com;

Translated line by line:

• default-src 'self' — By default, only allow stuff from my own domain.
• script-src — Allow scripts from my domain, Google Tag Manager, and Stripe.
• style-src — Allow stylesheets from my domain and inline