What is Content Security Policy (CSP)?

Content Security Policy (CSP) is a browser-enforced web security control that tells the browser which scripts, styles, images, frames, and other resources a page can load or execute.

For teams asking what is a content security policy, the practical answer is a defensive allowlist for web content. It reduces exposure to cross-site scripting, data injection, and unapproved third-party resources.

How does it work?

A website usually delivers CSP through the Content-Security-Policy header, although a limited policy can also be set with a meta tag. The browser reads directives such as default-src, script-src, img-src, and frame-ancestors, then blocks or reports behavior that violates the policy.

Strong CSPs often avoid broad sources such as wildcard domains, unsafe-inline, and unsafe-eval. Many teams first deploy report-only mode to collect violations, fix breakage, and then move to enforcement.

Content Security Policy vs CORS

Content Security Policy controls what a page may load or run in the browser. CORS controls whether a browser may read responses from another origin during cross-origin requests.

The two are complementary, not interchangeable. Permissive CORS can expose APIs to unintended origins, while weak CSP can let injected content execute even when API access is restricted.

How Hexnode supports content security policy

Hexnode does not replace secure coding or server-side CSP configuration. It supports the endpoint environment by helping IT teams enforce browser security policies, kiosk policies, application controls, compliance checks, patch workflows, and remote actions.

This is useful because CSP depends on browsers, devices, and sessions behaving predictably. Endpoint visibility helps teams find outdated browsers, unmanaged devices, risky kiosk settings, or noncompliant endpoints.

When should organizations use it?

Organizations should use CSP for public websites, SaaS applications, admin portals, payment flows, self-service portals, and internal web apps that handle sensitive data. It is especially important when pages load third-party scripts, analytics, ads, payment libraries, or embedded content.

Teams researching what is a content security policy should treat implementation as an ongoing control, not a one-time header. Review it after application changes, new vendors, framework upgrades, and incident findings.