Keywords: Content Security Policy | CSP Configuration | XSS Protection | Web Security | HTTP Headers
Abstract: This technical paper provides an in-depth exploration of Content Security Policy (CSP) mechanisms, covering multi-source configuration, directive usage, port and protocol handling, and inline script permissions. Through systematic analysis of CSP's role in preventing XSS attacks and detailed code examples, it offers comprehensive guidance for web developers on implementing security policies via HTTP headers and meta tags.
Fundamental Concepts of Content Security Policy
Content Security Policy (CSP) serves as a critical web security mechanism that mitigates cross-site scripting (XSS) attacks by defining resource loading policies. When browsers detect violations of CSP directives, they generate console errors such as "Refused to evaluate a string" or "Refused to execute inline script" to alert developers.
Multi-Source Configuration and Directives
CSP permits specifying multiple resource sources using space-separated lists. When configuring the default-src directive, both 'self' and specific domains can be included:
<meta http-equiv="Content-Security-Policy" content="default-src 'self' https://example.com/js/">This configuration allows loading same-origin resources and all files under the https://example.com/js/ path, while rejecting requests with different protocols or outside the specified path.
Core Directive Functionality Analysis
CSP provides specialized directives for controlling different resource types:
default-src: Sets default loading policies for JavaScript, images, CSS, and other resourcesscript-src: Specifically controls JavaScript file sourcesstyle-src: Manages CSS stylesheet loading sourcesimg-src: Restricts image resource loading locationsconnect-src: Controls connection targets for XMLHttpRequest, WebSocket, etc.
Multi-Directive Combination Configuration
Multiple directives can be defined in a single policy using semicolon separation:
content="default-src 'self' https://example.com/js/; style-src 'self'"This approach enables granular security control for different resource types.
Port and Protocol Handling Mechanisms
CSP imposes strict requirements for ports and protocols. Non-default ports must be explicitly declared:
content="default-src 'self' https://ajax.googleapis.com http://example.com:123/free/stuff/"Using an asterisk allows all ports: content="default-src example.com:*". For non-standard protocols like WebSocket, explicit authorization is required: content="default-src 'self'; connect-src ws:; style-src 'self'".
File Protocol and Inline Content Handling
The file:// protocol requires activation via the filesystem parameter: content="default-src filesystem". Inline scripts and styles are prohibited by default and must be explicitly allowed using the 'unsafe-inline' keyword:
content="script-src 'unsafe-inline'; style-src 'unsafe-inline'"Base64-encoded inline images require separate authorization: content="img-src data:".
Eval Function Permission Control
Although the eval() function poses security risks, it has legitimate use cases in specific scenarios. The 'unsafe-eval' keyword enables this functionality:
content="script-src 'unsafe-eval'"Developers should carefully evaluate the necessity of using eval() and ensure input data reliability.
Precise Meaning of the Self Keyword
The 'self' keyword denotes resource sources that share the same protocol, host, and port as the current document. This means if a website uses HTTP protocol, 'self' won't include HTTPS resources without additional configuration.
Security Best Practices and Considerations
While using default-src * appears simple, this configuration contains serious security vulnerabilities and cannot permit inline scripts. Adopting the principle of least privilege is recommended, authorizing only necessary resource sources. Combining nonce and hash mechanisms enables building more secure strict CSP policies that effectively prevent XSS attacks.