Content-Security-Policy: The Web Tester’s Headache

By Red Siege | November 6, 2025

The Q*Bert Effect

As a kid I loved playing a game called QBert. You would control this alien-like creature with a long nose like an ant eater trying to hop up and down squares while avoiding other creatures that would harm you if you collided. If you did collide, QBert would release his infamous string of frustrated characters something like “@!#?@!”. That’s pretty much what happens to me when I find XSS (Cross-Site Scripting) with Content-Security-Policy in play. I literally believe a chat bubble with that exact string appears above my head.

When developers add an effective Content-Security-Policy, it can really frustrate attackers attempts to inject things like XSS. It makes it harder to get execution, as it can effectively block the attack vector being used.

What is Content-Security-Policy

Example CSP Policy

Content-Security-Policy (CSP) is a security feature that can be implemented for web applications to help prevent specific types of attacks, such as XSS. The CSP policy works by allowing the developer to choose where resources are loaded from. For instance, they can place restrictions on the img src, so that it becomes much harder to use to inject XSS. Below is a sample CSP policy that you might seen in a returned HTTP Response.

Can it Be Bypassed?

CSP Evaluator

Bypassing CSP is possible, but it usually depends on if the policy is misconfigured. One of the first places I go when coming across a CSP policy is to check with the CSP Evaluator.

Examination of a CSP Policy for Misconfigurations

With the CSP Evaluator, you can paste in the CSP policy you are seeing and check for potential issues. The figure below shows an evaluation of a CSP policy. The evaluator will let you dig in and see where there are issues with the current policy. Misconfigurations aren’t uncommon, as many web applications depend on third-party resources and will often leave a door or two open to make sure those resources work as intended. Below you can see the evaluation of a CSP policy.

Let’s say for instance you find this within the policy:

Content-Security-Policy: script-src https://fakesite.org 'unsafe-inline';

The policy itself seems like an issue, especially with the word unsafe wedged in there, and honestly pretty much opens the door for a lot of issues. With this, we know we can use inline resources regardless of where they originate, such as simply doing something like:

/><script>prompt(1);</script>

External scripts will also work, as long as they come from https://fakesite.org.

Now it’s doubtful you will commonly see this (I’ve seen it a few times!), but other issues will often arise within the policies, such as the ability to link external JavaScript files, or the inclusion of a third-party domain. You’ll have to evaluate the rules carefully to see how you might be able to inject even though the CSP policy is in play. With multiple frameworks in play, and third-party resources in use, examining the policy for flaws can truly pay off.

Takeaways

Content Security Policies are an excellent device when used properly. For developers they can be an extra barrier of protection to help thwart nasty things like XSS attacks. However, this is only true if the policies are implemented correctly, so make sure you test your own policies and use the evaluator yourself to make sure there are no holes. For the tester, CSP can be quite a headache. One of the only ways of defeating CSP is trying to look for misconfigurations, which isn’t always a piece of cake; however security testing rarely is!

About Stuart Rorer, Security Consultant

Stuart has worked in the IT Industry for more than twenty years and has worked within Cyber Security for the past twelve. In the past he has held jobs in the education, government, and private sector, and for the last few years has specialized in web application penetration testing. Stuart has performed testing on clients in all sectors, many of which have been in the Fortune 500. He enjoys spending time in research and exploring new penetration testing tactics, and techniques.

Certifications:

CPT, ECPPT, ECSA, CEH, SEC+