Content Security Policy Review & Fixes
A Content Security Policy tells the browser which scripts are allowed to run on your site. Get it right and an injected script simply does not execute. We review what you have today, then write and deploy a policy that holds — without breaking your app.
The Challenge
Most fast-built SaaS applications ship with no Content Security Policy at all, or one copied from a blog post and loosened until the app stopped complaining. Either way it blocks nothing. That matters because a single injected script — from a compromised dependency, an ad tag, or a cross-site scripting flaw — can quietly read your customers' data and session tokens from inside the page. Teams avoid fixing it because a badly written policy breaks live payment widgets, chat, and analytics.
What a Content Security Policy Actually Does
A Content Security Policy is a single line your server sends with every page. It lists the places the browser is allowed to load scripts, styles, fonts and images from. Anything from anywhere else is refused before it runs.
That matters because most attacks on a web application end the same way: somebody gets a script onto your page. It might come through a comment box, a compromised npm package, or a marketing tag somebody added last year. Without a policy, the browser runs it and it can read whatever the logged-in customer can see. With a policy, the browser simply refuses.
It sits alongside a handful of other security response headers — HSTS, X-Frame-Options, Referrer-Policy and Permissions-Policy — that together make up what a scanner means when it grades your site's headers.
Check Your Security Headers
Before any work starts, we run a free check on your live site and tell you plainly what is set and what is missing. Here is what we look at and what good looks like.
Content-Security-Policy
Pass: Names specific sources for scripts and styles, and uses a nonce or hash for anything inline.
Fail: Missing entirely, or present but with unsafe-inline, unsafe-eval or a wildcard that switches the protection off.
Strict-Transport-Security
Pass: Long max-age with subdomains included, so browsers refuse to talk to your site over plain HTTP.
Fail: Absent, or set so short that a first visit is still exposed.
X-Frame-Options / frame-ancestors
Pass: Your pages cannot be embedded in someone else's site to trick your customers into clicking.
Fail: Nothing set, so any site can frame your app.
Referrer-Policy
Pass: Limits what of your URLs leaks to third parties — which matters if your URLs contain identifiers.
Fail: Default behaviour, sending full URLs to anywhere your page links or loads from.
Permissions-Policy
Pass: Camera, microphone, geolocation and payment access switched off unless your app genuinely uses them.
Fail: Unset, so any embedded third-party script can ask for them.
Our Solution
We do the careful part for you: work out exactly what your application legitimately loads, write a policy around it, prove it in report-only mode, then switch it on.
Header & Policy Audit
We scan your live site and report what is actually being sent today — your Content Security Policy if you have one, plus HSTS, X-Frame-Options, Referrer-Policy and Permissions-Policy — and explain in plain English what each one is and is not protecting you from.
A Policy Built Around Your App
We map every legitimate script, style, font, image and third-party service your application depends on — payment providers, booking widgets, live chat, analytics — and build a policy that permits precisely those and nothing else.
Report-Only, Then Enforce
We deploy the policy in report-only mode first and watch real traffic, so anything we missed shows up as a violation report rather than a broken page for a customer. Once it is clean, we switch to enforcement and retest.
What We'll Review
What You Gain
Injected Scripts Fail
An attacker who manages to inject a script still gets nothing, because the browser refuses to run it.
Third-Party Risk Contained
If one of your dependencies or ad tags is compromised, the blast radius stops at the policy.
Questionnaire-Ready
Security headers are an easy tick on Cyber Essentials, SOC 2 and enterprise customer security questionnaires.
Nothing Breaks
Report-only rollout means your checkout, chat and analytics keep working while we tighten the policy.
Why Start with Us?
We have done this on live products
We have taken production applications from no policy to full enforcement without downtime, and written up exactly how.
The scan is free
We will look at your live headers and send you a short, readable report whether or not you go any further.
Over two decades of engineering experience
We fix the cause rather than handing you a list. You get a working policy, not a recommendation to write one.
Common Questions
Where this fits
A Content Security Policy limits what an attacker can do once they find a way in. These services find the ways in, and fix them at the source.
OWASP-aligned exploit-led testing of your live application, with a free retest and a letter of attestation.
We build an automated process that fixes vulnerabilities safely in your stack, so findings stop piling up.
Manual and automated review of your source code to find the flaws a policy can only contain.
Our write-up of taking a production application from no policy to full enforcement, step by step.
Our Expertise
AWS Partner
Certified cloud expertise you can trust
Solutions Architect Associate
DevOps Engineer Professional
Solutions Architect Professional
Security Specialty