Section’s Content Security Policy (CSP) Module Adds Another Security Layer to Protect Web Applications

In today’s dynamic threat landscape, Section’s Content Security Policy (CSP) Module adds another line of defense in web application security. The CSP Module, backed by computer security standards recommended by the W3C working group, allows system administrators to easily configure, enforce, and track activity around security policies to ensure that browsers only fetch or execute resources from valid sources. These policies help protect against Cross-Site Scripting (XSS) attacks, clickjacking, and other data injection threats.

Why should application developers use CSP?

Although there are some built-in protections offered by the same-origin policy (SOP), whereby a web browser permits scripts contained in a first web page to access data in a second web page if they share the same origin, the modern web is more demanding.

Web applications today use scripts and other resources from external sources. A few examples include analytics and font scripts, and resources served from content delivery networks (CDNs). Without additional security measures in place, browsers may confuse legitimate sources with illegitimate sources attempting to inject malicious code into web applications.

How does Section’s CSP module work?

The Content Security Policy (CSP) helps protect against these threats by explicitly telling browsers which sources to trust content from. Based on the defined protocols around HTTP, Section’s CSP module makes it easy to quickly configure and deploy security policies for a given application’s unique requirements.

The CSP Module accepts user-defined security policies for browsers to determine which origins to accept content from. These policies are passed through using a Content-Security-Policy HTTP header, which will block assets requested from origins not in the list. You can also configure settings for the browser to send reports to a designated url using the report-uri directive of the Content-Security-Policy header.

A few examples of common security policies include:

• All content must come from the site’s own origin (excluding subdomains).
• Allow content from a trust domain and all its subdomains.
• All content must be loaded using TLS.
• Allow HTML in email, as well as images loaded from anywhere, but restrict JavaScript or other potentially dangerous content.

If you’d like more information on how to leverage the CSP module or if you’d like some assistance in getting it set up, contact our team of solution engineers.