Content-Security-Policy

Content Security Policy

The Content Security Policy (CSP) is a web security standard introduced to help prevent Cross-Site Scripting (XSS), Clickjacking, and other code injection attacks resulting from execution of malicious content in the trusted web page context. CSP provides a standard way for web developers to declare approved sources of content that browsers should be allowed to load on that page.

History

Introduction: CSP was initially proposed by Mozilla in 2010 as part of their Firefox browser, aiming to combat XSS attacks by allowing developers to specify which sources of content should be considered trustworthy.
Standardization: It was later adopted by other major browsers, and the W3C published the first Candidate Recommendation for CSP Level 1 in 2012. CSP Level 2 followed in 2015, introducing more directives and options.
Evolution: The CSP standard has evolved with CSP Level 3, which is still in draft form as of the last update, introducing even more granular control over what resources can be loaded.

How CSP Works

CSP is implemented through HTTP headers or meta tags:

HTTP Header: The policy is delivered using the Content-Security-Policy HTTP header. This is the recommended method as it applies to the entire page and is less susceptible to tampering.
Meta Tag: For situations where headers cannot be used (e.g., dynamically generated content), CSP can be specified via the <meta> tag, but this has limitations, such as not being able to control <base> elements or plugins.

Directives

CSP policies consist of directives that define what sources are allowed for different types of content:

default-src: Defines loading policy for all resources not explicitly covered by other directives.
script-src: Controls which scripts are allowed to be executed.
style-src: Specifies valid sources for stylesheets.
img-src: Defines valid sources of images.
connect-src: Restricts the URLs which can be loaded using script interfaces (e.g., XHR, WebSockets).
frame-src: Indicates valid sources for nested browsing contexts (like <iframe>).
object-src: Specifies valid sources for the <object>, <embed>, and <applet> elements.
base-uri: Restricts the URLs that can be used in the base element.
form-action: Limits the URLs that can be used as the action of a form.

Security Benefits

XSS Protection: By limiting the sources from which scripts can be loaded, CSP makes it harder for attackers to inject malicious scripts.
Clickjacking Prevention: CSP can block loading of content into frames or iframes from untrusted sources.
Content Restriction: Developers can ensure that only content from known, trusted sources is loaded, reducing the attack surface.

Challenges and Considerations

Compatibility: Not all browsers support the latest CSP features or directives. Developers must consider this when implementing CSP.
Performance: Strict policies might cause additional network requests for policy violation reports.
Implementation: Setting up a robust CSP can be complex, especially for dynamic content or large websites with many third-party integrations.

Grok-Pedia

Content-Security-Policy