A content security policy (CSP) is a security mechanism by which a website uses an HTTP header to tell the browser which sources scripts, styles, images and other resources may be loaded from. It primarily makes cross-site scripting (XSS) attacks and the injection of third-party content more difficult.
A CSP is like a guest list at the entrance of your website: the browser only lets in content that is explicitly on the list. If an attacker tries to smuggle in foreign code, it is usually turned away at the door.
Why do I need a content security policy?
Cross-site scripting (XSS) has been one of the most widespread types of attack on websites for years: attackers inject third-party JavaScript code that is executed in visitors' browsers – for example to skim form input or payment data. A content security policy forms a second line of defence: even if malicious code makes it onto the page, the browser can prevent its execution because the source is not approved in the policy.
Technically, the CSP is delivered as an HTTP header and consists of directives such as script-src, style-src or img-src, which define the permitted sources per resource type. Modern policies work with nonces or hashes to approve individual inline scripts specifically instead of allowing inline code across the board. Browsers have supported the mechanism comprehensively for many years; in practice, adoption rarely fails because of the technology, but because of a missing overview of which sources a grown website actually uses. An inventory of all embedded services is therefore the sensible first step.
Practical relevance for shop and website owners
Online shops typically embed many third-party sources: payment providers, analytics, tag managers, fonts, chat widgets. It is precisely this variety that makes them a target for attacks such as web skimming, in which manipulated third-party scripts skim card data in the checkout. A well-maintained CSP can significantly limit such risks and is one component of a multi-layered security strategy, as described in our article on IT security in e-commerce. Zero-trust approaches follow the same basic idea: never trust any source by default.
Common mistakes
- unsafe-inline as a permanent solution: Allowing inline scripts across the board considerably weakens XSS protection – nonces or hashes are the cleaner approach.
- Enforcing a CSP without a test phase: An overly strict policy quickly blocks payment or tracking scripts; report-only mode initially just reports violations without blocking.
- Ignoring third-party changes: External services occasionally change their domains – without ongoing maintenance, functionality then silently breaks.
- Overly generous wildcards: Very broad approvals effectively allow arbitrary sources and largely devalue the policy.
What to look for
Introduce a CSP step by step: start in report-only mode, evaluate the reported violations, then tighten the policy gradually. Every approved source should be justifiable; inline code is ideally legitimised via nonces or hashes. Changes to the header are best tested on a staging environment before going live – otherwise a faulty entry can bring the checkout to a standstill. We support you with the configuration of security headers as part of our hosting & maintenance and custom development services.
A content security policy complements secure coding, updates and further security headers (such as HSTS and X-Content-Type-Options) – it does not replace these measures. With managed hosting, header maintenance is ideally part of the operating concept.