Content Security Policy, commonly known as CSP, is a powerful browser level security mechanism that helps protect websites from attacks such as Cross Site Scripting XSS, clickjacking, and other code injection threats. By clearly defining which resources are allowed to load and execute, CSP reduces the risk of malicious scripts running in a user’s browser.
For modern websites that rely on multiple scripts, APIs, fonts, and third party integrations, implementing a properly configured Content Security Policy header is an essential step in strengthening overall web security.
What Content Security Policy Actually Does
Content Security Policy is delivered through an HTTP response header named Content Security Policy. When a browser receives this header, it reads the defined rules and enforces them before loading resources.
Instead of trusting all content by default, the browser checks whether each script, stylesheet, image, or connection matches the allowed sources defined in the policy. If a resource does not match the approved list, the browser blocks it.
This approach significantly reduces the attack surface for injected scripts and unauthorized external content.
Common CSP Directives Explained
A CSP policy is made up of directives. Each directive controls a specific type of resource. Below are some of the most widely used directives and how they work.
default src
The default src directive acts as a fallback. If a specific directive such as script src is not defined, the browser applies the rules from default src.
Example
Content Security Policy: default src 'self'
This allows content to load only from the same origin unless otherwise specified.
script src
Controls where JavaScript files can be loaded from.
Example
Content Security Policy: script src 'self'
https://apis.google.com
This allows scripts from the same domain and from Google APIs.
style src
Defines permitted sources for CSS styles.
Example
Content Security Policy: style src 'self'
https://fonts.googleapis.com
img src
Specifies allowed image sources.
Example
Content Security Policy: img src 'self' data:
https://images.example.com
connect src
Controls where the browser can send network requests using fetch, XMLHttpRequest, or WebSockets.
Example
Content Security Policy: connect src 'self'
https://api.example.com
font src
Defines trusted font sources.
Example
Content Security Policy: font src 'self'
https://fonts.gstatic.com
object src
Restricts plugins such as Flash or other embedded objects.
Example
Content Security Policy: object src 'none'
frame ancestors
Determines which websites can embed your site in an iframe. This helps prevent clickjacking.
Example
Content Security Policy: frame ancestors 'self'
report uri
Specifies an endpoint where CSP violation reports should be sent.
Example
Content Security Policy: default src 'self'; report uri /csp report endpoint/
upgrade insecure requests
Automatically upgrades HTTP requests to HTTPS.
Example
Content Security Policy: upgrade insecure requests
How CSP Is Enforced by Browsers
The process works in three stages.
Policy definition
The server sends the Content Security Policy header with defined rules.
Browser enforcement
The browser evaluates every requested resource against the policy. If the resource violates the policy, it is blocked.
Violation reporting
If report uri is configured, the browser sends details about blocked resources to the defined endpoint. This helps identify misconfigurations or attack attempts.
Why Implement Content Security Policy
Implementing a strong CSP provides several benefits.
Prevents XSS attacks
By restricting where scripts can load from, CSP blocks unauthorized inline scripts and injected payloads.
Improves data protection
CSP reduces the risk of malicious code stealing session tokens or sensitive user information.
Enhances website integrity
Only trusted sources are allowed to deliver executable content.
Strengthens overall security posture
CSP complements HTTPS, secure cookies, and other security headers.
For websites handling login systems, payment pages, or sensitive data, CSP is an important layer of defense.
Adding CSP to Your Web Server
To implement CSP, you must configure your server to send the Content Security Policy header.
Apache example
Add this to your Apache configuration or htaccess file
Header set Content Security Policy "default src 'self'; script src 'self'
https://apis.google.com
; style src 'self'
https://fonts.googleapis.com
; img src 'self' data:
https://images.example.com"
Nginx example
Inside your server block
add_header Content Security Policy "default src 'self'; script src 'self'
https://apis.google.com
; style src 'self'
https://fonts.googleapis.com
; img src 'self' data:
https://images.example.com
" always;
After applying changes, reload the server and verify the header in the browser network tab.
Enabling Content Security Policy in VergeCloud
If you are using VergeCloud CDN, enabling CSP is straightforward.
Log into the VergeCloud panel
Access your account and select the domain you want to configure.
Enable HTTPS by default
Navigate to
SSL or Edge Connection settings and enable Make HTTPS Default. This automatically applies secure connections and adds
upgrade insecure requests.
Add custom directives
Go to Page Rules and create or edit a rule.
Enable User Response Header
Add a header named Content Security Policy and define your directives.
Save changes
Once saved, VergeCloud propagates the configuration across its global edge network.
Testing Your CSP Configuration
After implementation, verify that the policy is active.
Using curl
Run
curl -I
https://yourdomain.com
Confirm that the response includes the Content Security Policy header.
Using browser developer tools
Open the Network tab, refresh the page, and inspect response headers.
Check for blocked resources
Look for errors in the console indicating blocked content due to CSP violations.
Managing Browser Caching of CSP
Browsers may cache CSP headers depending on caching rules. If you update or relax your policy, some users might still operate under the previous version until cache expiration.
Plan policy changes carefully. If you tighten restrictions, test in report only mode first to avoid breaking functionality.
Sample CSP Configurations
Basic configuration
Content Security Policy: default src 'self'
Allow trusted scripts and styles
Content Security Policy: default src 'self'; script src 'self'
https://apis.google.com
; style src 'self'
https://fonts.googleapis.com
Strict configuration with reporting
Content Security Policy: default src 'self'; script src 'self'
https://apis.google.com
; style src 'self'
https://fonts.googleapis.com
; img src 'self'
https://images.example.com
; connect src 'self'
https://api.example.com
; font src 'self'
https://fonts.gstatic.com
; object src 'none'; frame ancestors 'self'; report uri /csp report endpoint/
Recommended Approach for Deployment
Start in report only mode
Use Content Security Policy Report Only to detect issues without blocking resources.
Avoid wildcards
Do not use broad allowances such as asterisk unless absolutely necessary.
Use nonces or hashes
Instead of allowing all inline scripts, specify approved nonces or hashes for better control.
Review policies regularly
As your website evolves, update your CSP to include new trusted services.
Test across browsers
Ensure consistent enforcement across major browsers and platforms.
Conclusion
Content Security Policy is one of the most effective security headers available for modern web applications. When properly configured, it protects against script injection, data theft, and unauthorized content loading.
Whether you configure CSP at the server level or through VergeCloud CDN, regular testing and gradual refinement are essential. A carefully implemented CSP improves trust, strengthens compliance, and enhances the security foundation of your website.