Content Security Policy (CSP): configuring it properly
CSP is an essential protection for web applications: by defining strict rules on the resources a browser may load, it limits many attack vectors. But it still has to be configured correctly.
What is a Content Security Policy?
A Content Security Policy (CSP) is an additional safeguard that helps detect and limit certain client-side attacks: Cross-Site Scripting (XSS), clickjacking, content injection. It is configured at server level: the administrator defines the rules that the browser must follow when loading a page, for example which sources are authorized for scripts, images or other resources.
It is implemented through a Content-Security-Policy header in server responses (recommended method) or, more rarely, through a tag in pages. It is a natural building block in an application security and website security.
The most common configuration mistakes
Allow “inline” script
The unsafe-inline directive allows scripts inserted directly in the page to run: it removes much of the CSP's value against XSS.
Tolerate dynamic evaluation
The unsafe-eval directive allows code to be evaluated on the fly, expanding the attack surface that an injected script can exploit.
Use a wildcard (*)
A wildcard in script-src allows sources that are too broad: an attacker can then load their own scripts from an accepted domain.
Forget key directives
The absence of default-src or object-src, or an authorized JSONP endpoint, leaves blind spots that can be used to bypass the policy.
A poorly tuned CSP creates false security
The trap is this: a CSP that exists but is misconfigured provides a misleading sense of protection. As long as it allows inline script, overly broad sources or endpoints that can be abused, it can be bypassed, and the application remains vulnerable to XSS, one of the classic entry points toward account theft. CSP is a valuable reinforcement, never a substitute for secure code.
Test the policy's real effectiveness
A CSP is not declared “good” on paper: it must be tested. The goal is to verify, directive by directive, that it actually blocks the loading and execution of unexpected resources, and that no bypass is possible (inline, eval, wildcard, JSONP endpoint, bypass through file upload). This control naturally fits into an penetration test application.
Strengthen a CSP, step by step
Define a restrictive baseline
Start from a closed policy (strict default-src) and open only what is strictly necessary, rather than the opposite.
Ban inline and eval
Avoid unsafe-inline and unsafe-eval; use nonces or fingerprints (hash) for legitimate scripts.
Specify each source
Explicitly list authorized domains, without wildcards, and cover the key directives (script-src, object-src…).
Enable reporting
Start in report mode to observe potential blocking before enforcing the policy in production.
Test bypasses
Challenge the policy against known bypass techniques to validate its real effectiveness, through a pentest.
Why get support from BCIT?
A tailored policy
We calibrate the CSP according to your real use cases, for strong protection without breaking site functionality.
Verified effectiveness
We test possible bypasses to confirm that the policy truly protects you.
A global view
CSP fits into a complete application security approach that we manage with you.
Not ready to talk yet? Discover our cybersecurity assessment →
Does your CSP really protect you?
Let's take 15 minutes to review your Content Security Policy and identify the adjustments that will make it truly effective.
Content Security Policy (CSP): configuring it properly
CSP is an essential protection for web applications: by defining strict rules on the resources a browser may load, it limits many attack vectors. But it still has to be configured correctly.
What is a Content Security Policy?
A Content Security Policy (CSP) is an additional safeguard that helps detect and limit certain client-side attacks: Cross-Site Scripting (XSS), clickjacking, content injection. It is configured at server level: the administrator defines the rules that the browser must follow when loading a page, for example which sources are authorized for scripts, images or other resources.
It is implemented through a Content-Security-Policy header in server responses (recommended method) or, more rarely, through a <meta> tag in pages. It is a natural building block in an application security and website security.
The most common configuration mistakes
Allow “inline” script
The unsafe-inline directive allows scripts inserted directly in the page to run: it removes much of the CSP's value against XSS.
Tolerate dynamic evaluation
The unsafe-eval directive allows code to be evaluated on the fly, expanding the attack surface that an injected script can exploit.
Use a wildcard (*)
A wildcard in script-src allows sources that are too broad: an attacker can then load their own scripts from an accepted domain.
Forget key directives
The absence of default-src or object-src, or an authorized JSONP endpoint, leaves blind spots that can be used to bypass the policy.
A poorly tuned CSP creates false security
The trap is this: a CSP that exists but is misconfigured provides a misleading sense of protection. As long as it allows inline script, overly broad sources or endpoints that can be abused, it can be bypassed, and the application remains vulnerable to XSS, one of the classic entry points toward account theft. CSP is a valuable reinforcement, never a substitute for secure code.
Test the policy's real effectiveness
A CSP is not declared “good” on paper: it must be tested. The goal is to verify, directive by directive, that it actually blocks the loading and execution of unexpected resources, and that no bypass is possible (inline, eval, wildcard, JSONP endpoint, bypass through file upload). This control naturally fits into an penetration test application.
Strengthen a CSP, step by step
Define a restrictive baseline
Start from a closed policy (strict default-src) and open only what is strictly necessary, rather than the opposite.
Ban inline and eval
Avoid unsafe-inline and unsafe-eval; use nonces or fingerprints (hash) for legitimate scripts.
Specify each source
Explicitly list authorized domains, without wildcards, and cover the key directives (script-src, object-src…).
Enable reporting
Start in report mode to observe potential blocking before enforcing the policy in production.
Test bypasses
Challenge the policy against known bypass techniques to validate its real effectiveness, through a pentest.
Why get support from BCIT?
A tailored policy
We calibrate the CSP according to your real use cases, for strong protection without breaking site functionality.
Verified effectiveness
We test possible bypasses to confirm that the policy truly protects you.
A global view
CSP fits into a complete application security approach that we manage with you.
Not ready to talk yet? Discover our cybersecurity assessment →
Does your CSP really protect you?
Let's take 15 minutes to review your Content Security Policy and identify the adjustments that will make it truly effective.