Improving Web Security with the Content Security Policy

Content Security Policy (CSP): A Comprehensive Guide to Web Security

Content Security Policy (CSP) is a crucial security mechanism safeguarding websites against content injection attacks, primarily Cross-Site Scripting (XSS). This declarative policy empowers developers to create a whitelist of trusted resource origins, controlling how the browser loads resources, uses inline styles and scripts, and handles dynamic JavaScript evaluation (e.g., using eval()). Any attempt to load resources from outside this whitelist is blocked.

Key Concepts:

• Whitelist Approach: CSP operates by defining allowed sources, blocking everything else.
• HTTP Header Delivery: The policy is implemented via the Content-Security-Policy HTTP header.
• Directive-Based Control: The header contains directives specifying allowed domains and restricting JavaScript execution to prevent injection attacks.
• Violation Reporting: The report-uri directive logs CSP violations, invaluable for production environments. This sends a JSON report detailing the violation to a specified URL.

How CSP Works:

CSP, a W3C Candidate Recommendation, uses the Content-Security-Policy header to deliver directives. Key directives include: default-src, script-src, object-src, style-src, img-src, media-src, frame-src, font-src, and connect-src. default-src acts as a fallback for unspecified directives.

Directives follow a consistent pattern:

• self: Refers to the current domain.
• URL List: Space-separated URLs specifying allowed origins.
• none: Prohibits loading resources for a given directive (e.g., object-src 'none' blocks plugins).

A basic CSP allowing resources only from the current domain:

<code>Content-Security-Policy: default-src 'self';</code>

Any attempt to load from another domain is blocked, with a console message. CSP inherently restricts inline scripts and dynamic code evaluation, significantly mitigating injection risks.

While domains are specified, paths are not currently supported. Wildcards (), however, allow for subdomain inclusion (e.g., `.mycdn.com`). Each directive requires explicit domain/subdomain listing; they don't inherit from previous directives.

For data URLs, include data: in the directive (e.g., img-src 'data:'). unsafe-inline (for script-src and style-src) allows inline <script></script> and <style></style> tags, and unsafe-eval (for script-src) enables dynamic code evaluation. Both use opt-in policies; omitting them enforces restrictions.

Browser Compatibility:

CSP 1.0 enjoys broad browser support, with older Internet Explorer versions having limited compatibility.

Monitoring Violations with report-uri:

While development uses browser console logging, production environments benefit from report-uri. This sends HTTP POST requests containing violation details (in JSON format) to a specified URL.

Example:

<code>Content-Security-Policy: default-src 'self';</code>

A violation (e.g., loading from www.google-analytics.com) generates a JSON report sent to the report-uri.

Content-Security-Policy-Report-Only Header:

For testing, use Content-Security-Policy-Report-Only. This reports violations without blocking resources, allowing policy refinement without site disruption. Both headers can be used concurrently.

Implementing CSP:

CSP is set via the HTTP header. Server configuration (Apache, IIS, Nginx) or programmatic methods (PHP's header(), Node.js's setHeader()) can be used.

Real-World Examples:

Facebook and Twitter demonstrate diverse CSP implementations, utilizing wildcards and specific domain allowances.

CSP Level 2 Enhancements:

CSP Level 2 introduces new directives (base-uri, child-src, form-action, frame-ancestors, plugin-types), improved reporting, and nonce/hash-based protection for inline scripts and styles.

Nonce-Based Protection:

A randomly generated nonce is included in both the CSP header and the inline script tag.

Hash-Based Protection:

The server computes the hash of the script/style block, included in the CSP header. The browser verifies this hash before execution.

Conclusion:

CSP significantly enhances web security by controlling resource loading. report-uri facilitates monitoring, and Level 2 introduces further refinements. Implementing CSP is a vital step in building robust and secure web applications.

(Note: The image placeholders remain unchanged as requested.)

The above is the detailed content of Improving Web Security with the Content Security Policy. For more information, please follow other related articles on the PHP Chinese website!