1. Introduction
Missing Content Security Policy is a web security issue where a website does not define rules for what content browsers are allowed to load. This can allow attackers to inject malicious scripts into your site, leading to cross-site scripting (XSS) attacks or other compromises. Websites of all sizes are affected, especially those that accept user input. A missing CSP header impacts confidentiality, integrity and availability if exploited.
2. Technical Explanation
Content Security Policy (CSP) is implemented via an HTTP response header. Without this header, browsers default to allowing content from any source. An attacker can exploit this by injecting malicious JavaScript into a vulnerable page, which then executes in the user’s browser with the website’s permissions. This requires the attacker to find a way to inject code, such as through stored XSS or a similar vulnerability.
- Root cause: Absence of the ‘Content-Security-Policy’ HTTP header.
- Exploit mechanism: An attacker injects malicious script into a web page that is then executed by the user’s browser. For example, an attacker could insert a <script> tag with harmful code into a comment field if input isn’t properly sanitised.
- Scope: All websites and web applications served over HTTP are affected.
3. Detection and Assessment
You can check for the presence of a CSP header using browser developer tools or command-line utilities. A thorough assessment involves testing various injection points to confirm that CSP is effective.
- Quick checks: Use your browser’s developer tools (Network tab) and inspect the HTTP response headers for ‘Content-Security-Policy’.
- Scanning: Burp Suite or OWASP ZAP can be configured to scan for missing CSP headers. These are examples only, as scanner accuracy varies.
- Logs and evidence: Web server access logs will show if a ‘Content-Security-Policy’ header is being sent with responses.
curl -I https://example.com | grep Content-Security-Policy4. Solution / Remediation Steps
Configure Content Security Policy on your website by adding the ‘Content-Security-Policy’ HTTP header or meta tag. This restricts the sources from which the browser will load content.
4.1 Preparation
- Change windows may be needed for larger sites, requiring approval from security teams.
4.2 Implementation
- Step 1: Add the ‘Content-Security-Policy’ HTTP header to your web server configuration file (e.g., Apache .htaccess, Nginx config). Start with a restrictive policy and gradually loosen it as needed.
- Step 2: Alternatively, add a <meta http-equiv=”Content-Security-Policy” content=”…”> tag to the <head> section of your HTML pages.
4.3 Config or Code Example
Before
# No Content-Security-Policy header present in Apache configAfter
Header always set Content-Security-Policy "default-src 'self'"4.4 Security Practices Relevant to This Vulnerability
Several security practices help prevent this issue. Least privilege reduces the impact of successful attacks, while input validation prevents malicious code injection. Secure headers provide an additional layer of defence.
- Practice 1: Input validation helps block malicious scripts from being injected into your website in the first place.
- Practice 2: Implementing secure headers like X-Frame-Options and Strict-Transport-Security adds extra protection against related attacks.
4.5 Automation (Optional)
If using a configuration management tool, you can automate the deployment of CSP policies across your web servers.
# Example Ansible task to set Content-Security-Policy header
- name: Set Content-Security-Policy header in Nginx config
lineinfile:
path: /etc/nginx/nginx.conf
regexp: '^add_header'
insertbefore: 'listen 80;'
line: 'add_header Content-Security-Policy "default-src 'self'";'5. Verification / Validation
Confirm the fix by checking for the presence of the CSP header in your browser’s developer tools and verifying that it is blocking unauthorized content.
- Post-fix check: Use `curl -I https://example.com | grep Content-Security-Policy` to confirm the header is present. Expected output should show ‘Content-Security-Policy: default-src ‘self”.
- Re-test: Re-run the earlier detection method (browser developer tools) to ensure the header is now being sent.
- Monitoring: Monitor web server logs for any errors related to CSP violations.
curl -I https://example.com | grep Content-Security-Policy6. Preventive Measures and Monitoring
Update your security baselines to include a minimum CSP policy. Incorporate checks in your CI/CD pipelines to ensure that CSP policies are correctly configured during deployment. Regular patch reviews help identify and address potential vulnerabilities.
- Baselines: Update your web server baseline configuration to require a ‘Content-Security-Policy’ header with a default restrictive policy.
- Pipelines: Add SAST or DAST tools to your CI/CD pipeline to scan for missing CSP headers and other security issues.
- Asset and patch process: Review web server configurations regularly as part of your asset management process.
7. Risks, Side Effects, and Roll Back
Implementing a too-restrictive CSP policy can break website functionality. If this happens, you need to loosen the policy gradually until it works correctly. The roll back steps are to remove the header or meta tag from your configuration.
- Risk or side effect 1: A restrictive CSP policy may block legitimate resources, causing website features to malfunction. Mitigation is to carefully test and adjust the policy.
- Roll back: Step 1: Remove the ‘Content-Security-Policy’ header from your web server configuration file. Step 2: Restart your web server to apply the changes.
8. References and Resources
- Vendor advisory or bulletin: Not applicable in this case, as CSP is a standard.
- NVD or CVE entry: Not applicable, as it’s a configuration issue rather than a specific vulnerability.
- Product or platform documentation relevant to the fix: https://content-security-policy.com/