What is CSP?
CSP works like a security guard with a strict guest list for your website. It tells browsers exactly which content is allowed to run and where it can come from. Just like a bouncer checking IDs at a club, CSP blocks any content that isn't explicitly approved.
Why It Matters
Without CSP protection, your website is vulnerable to:
Malicious code injection through cross-site scripting (XSS)
Data theft through unauthorized scripts
Clickjacking attacks that trick users
Loading of resources from untrusted sources
Interference from malicious plugins
Security Checks
We monitor these aspects of your CSP configuration:
Is a CSP header present for the domain?
A Content Security Policy (CSP) controls which resources can load and execute on the domain's pages. Without a CSP, there are no restrictions on what content can run on pages, leaving them vulnerable to cross-site scripting and other injection attacks.
Are inline scripts restricted in the CSP?
The domain's CSP includes 'unsafe-inline' in the script-src directive. This allows any inline scripts to run, potentially enabling attackers to inject malicious code directly into pages.
Is dynamic code evaluation restricted?
The domain's CSP includes 'unsafe-eval' in the script-src directive. This allows potentially dangerous runtime code evaluation, which attackers could exploit to run malicious scripts.
Is a default source policy specified?
The domain's CSP lacks a default-src or fallback directive. Without this baseline policy, some resource types may have no loading restrictions by default.
Are wildcard sources avoided in critical directives?
The domain's CSP uses '*' wildcards in critical directives. This allows resources to be loaded from any source, defeating the purpose of content restrictions.
Is frame protection configured?
The domain's CSP lacks a frame-ancestors directive. This leaves the site vulnerable to clickjacking attacks where it could be embedded in malicious frames.
Are all source schemes secure?
The domain's CSP allows resources to load over insecure HTTP connections. This could allow attackers to intercept or modify content before it reaches users.
Is CSP violation reporting configured?
The domain's CSP has no reporting configuration. This means security violations won't be reported, making it harder to detect and respond to attacks.
Is mixed content blocked?
The domain's CSP allows mixed active content. This means secure HTTPS pages can load active content over insecure HTTP connections, creating security vulnerabilities.
Are external sources appropriately restricted?
The domain's CSP allows too many external domains as valid sources. This broad allowlist makes it harder to prevent malicious content from loading.
Is automatic HTTPS upgrading enabled?
The domain's CSP lacks the upgrade-insecure-requests directive. This means resources might load over insecure connections when secure ones are available.
Are nonces or hashes used for inline scripts?
The domain's CSP doesn't use nonces or hashes to validate inline scripts. This makes it harder to safely allow specific trusted inline scripts while blocking malicious ones.
Are CSP directives consistently configured?
The domain's CSP contains conflicting or redundant directives. This can create confusion about which rules apply and may leave security gaps.
Industry Standards
CSP is recommended by:
OWASP Security Standards
NIST Web Security Guidelines
Mozilla Web Security Guidelines
Google Web Security Requirements