Why I don’t use unsafe-inline, and you shouldn’t either

Building a CSP on WordPress plugin and then allowing unsafe-inline does nothing for your security. It\'s worse than nothing. It\'s a false negative. The most dangerous of all security responses. The green validation check that is NOT TRUE.
Building a CSP on WordPress plugin and then allowing unsafe-inline does nothing for your security. It\’s worse than nothing. It\’s a false negative. The most dangerous of all security responses. The green validation check that is NOT TRUE.

Building a CSP and then allowing unsafe-inline does nothing for your security. It’s worse than nothing. It’s a false negative. The most dangerous of all security responses. The green validation check that is NOT TRUE. It is a green flag that means your site is ready for XSS exploitation.

Then why do so many developers and secuirty engineers use unsafe-inline for scripts and styles? Many programers use inline scripts and styles as a fast fix technique. It’s quite challenging to change the code of an application. Especially when using code that was written by a collection of programmers who may not be following the same coding standards.

I know a lot about this, since I wrote a post-processor for WordPress to fix all the code and conform the server-side output (stdout) to the parameters of a strict Content-Security-Policy. It was the themes and plugins that offered the majority of the challenge.

As a programmer, having a solid grasp of web security principles enables you to build more resilient applications that can withstand attacks. If you want to jump back to the Foundational Techniques for Web Security, it’s a good place to start.

Why is a Strict CSP is the First Best Defense for websites and web applications

By defining a strict CSP, you can dictate where scripts, styles, and other content can come from, thereby restricting any unintended sources. This is particularly crucial in modern web sites like WordPress, Shopify, Webflow and others that often load resources from various external providers.

Implementing a strict CSP comes with several benefits beyond just security. It can lead to better performance since browsers can cache resources more efficiently when the sources are well-defined. Additionally, a well-configured CSP can help in identifying vulnerabilities during the development phase by logging violations. Learn more About Building a Strict CSP with Hashes and Nonces.

Understanding the Risks of unsafe-inline

One of the most dangerous directives in CSP is “unsafe-inline”. It permits the execution of inline scripts, which can easily be exploited by attackers. When “unsafe-inline” is used, it essentially negates the protective benefits that a CSP is supposed to provide, declaring your application vulnerable to XSS attacks.

Building a CSP on WordPress plugin and then allowing unsafe-inline does nothing for your security. It\'s worse than nothing. It\'s a false negative. The most dangerous of all security responses. The green validation check that is a false flag. It is a green flag for hackers.
Building a CSP on WordPress plugin and then allowing unsafe-inline does nothing for your security. It\’s worse than nothing. It\’s a false negative. The most dangerous of all security responses. The green validation check that is a false flag. It is a green flag for hackers.

By allowing “unsafe-inline” you actually announce open doors for attackers to inject malicious scripts directly into your pages, leading to potential data breaches and significant reputational damage. As a best practice, avoid using “unsafe-inline” entirely.

If you don’t openly admit to strangers that your house has an unlocked backdoor, then you should never set ‘unsafe-inline’ for your script-src when building a CSP. This is essentially saying, in computer jargon, I am formally inviting skilled adversaries to launch successful XSS attacks on this website.

Maybe you want to build a CSP, just like a small child makes cookies with an Easy-Bake oven… but they didn’t really bake, and if you use script-src: unsafe-inline, you didn’t build an effective CSP.

Examples of Attacks Enabled by `unsafe-inline`

Consider a scenario where an application uses `unsafe-inline`. An attacker could exploit a vulnerability to inject JavaScript that steals user cookies or session tokens. This type of attack can be devastating, allowing the attacker to login to your private Amazon, business, or bank accounts, all because my WordPress website didn’t use a strict CSP.

This vulnerability is why I wrote code to protect WordPress websites with a strict CSP.

Another example is when inline event handlers are allowed via `unsafe-inline`, enabling attackers to manipulate user interactions and execute unwanted actions without the user’s consent. This shows how the risks associated with `unsafe-inline` far outweigh any potential convenience it might offer.

Alternatives to Inline Scripts

If you ask ChatGPT about how to solve this, it says very matter of factly:
To avoid the pitfalls of `unsafe-inline`, developers should utilize external scripts. By moving all JavaScript code to external files, you can specify these sources in your CSP and eliminate the need for inline scripts altogether. This approach not only enhances security but also improves code maintainability and reusability.

This is a nice idea, but a distance from reality. In reality we have functionality libraries that are linked to remote repositories, CDNs, and everything needs to be hashed to verify the proper library is loading. We also have all sorts of dynamic data, which is vulnerable and unprotected until we protect it.

This is where we can combine hashes and nonces in the file include method on the remote server.

How to Write for a Strict CSP

Setting Up Your CSP Header

Setting up your Content Security Policy involves adding a Content-Security-Policy HTTP header. This header dictates which sources can be trusted for loading resources. A simple CSP header might look like this:

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none';`

This example allows resources to load only from the same origin and disallows any objects, enforcing stricter security. Depending on your application’s needs, you may need to customize your CSP further to include trusted third-party services.

Defining Your Content Sources

When defining content sources in your CSP, it’s crucial to be specific about which domains can be accessed. Use directives like script-src, style-src, and img-src to provide granular control over which resources can be loaded. For instance, if you are using a third-party analytics service, include that specific domain in your script-src directive.

Always aim for the most restrictive policy that still allows your application to function correctly. This minimizes your attack surface and significantly enhances security without compromising usability.

Testing and Validating Your CSP

After configuring your CSP, testing is essential to ensure it works as intended. Tools like Google’s CSP Evaluator help analyze your policy and identify any weaknesses. Additionally, using browser developer tools can help you monitor CSP violations in real time.

Regularly validate your CSP, especially when making changes to your application’s code or when adding new resources. This ongoing diligence ensures that your security measures remain robust against evolving threats.

Common Pitfalls and How to Avoid Them

A common pitfall when implementing CSP is being too lenient with allowed sources. Avoid wildcards like * which can expose your application to various risks. Always specify trusted domains to maintain tight control over what’s permissible.

Another common mistake is neglecting to address CSP violations in production. Monitor your application for CSP-related errors and resolve them promptly to ensure that your security measures are effective. This proactive approach helps maintain the integrity of your web application.

Conclusion

Recap of Key Points

In summary, a strict Content Security Policy is an essential tool in the arsenal of any developer or security engineer. It provides a strong defense against XSS attacks and other vulnerabilities that could compromise your application. By avoiding unsafe-inline, defining explicit content sources, and rigorously validating your CSP, you can significantly enhance the security of your website and web applications.

If you are doing eCommerce or collecting user PII, and your company is larger than tiny, this kind of stuff is very important. If you are in a information security compliance industry, your vulnerability or penetration test present this test.

Being security in our website is a marketable effort. Prioritizing security protects your users and builds trust and credibility for your brand in an increasingly security-conscious environment.

Encouragement to Adopt Strict CSPs

As product owners, project managers, and developers, it’s our responsibility to implement best practices that secure our applications. Adopting a strict Content-Security-Policy is a significant step in the right direction. If you embrace these principles and encourage your peers to do the same, together, we can create a safer internet for customers and web users.

1 comment
Leave a Reply

Your email address will not be published. Required fields are marked *

You May Also Like

What is an ISMS?

An Information Security Management System (ISMS) is a structured framework designed to manage sensitive company information, ensuring its…