CSP bypasses, and how developers can build a strict CSP!

When implementing a Content-Security-Policy, precision is always key: Too strict of rules, will block legitimate parts of your website from working properly. Too loose of rules, will be easily bypassable — not offering true protection. A google research on CSP has found that 94.72% of CSPs are automatically bypassable — and don't even require the attacker to apply sophisticated logic in order to find a bypass.

This excellent article summarizes the top Common CSP bypasses for XSS:

  • Wildcards: such as *, https: , data: , blob: (which truly offer no real protection, so no bypass is needed)
  • 'unsafe-inline' / 'unsafe-eval' : which are at the base of the most basic XSS attacks.
  • Objects / Plugins: another tool for getting js-runtime access
  • Uploadable destinations: Website 'self' allows user file upload, or a public CDN is allowed.
  • JSONP workarounds: If your CSP allows a site with a JSONP endpoint — the attacker could easily manipulate it into running your
  • Legacy Angular: legacy Angular 1.x libraries are easily manipulated to run injected content from the DOM as javascript, and since these files exist all over the web, many allowlists are susceptible to this bypass.
  • Iframes: use the special attribute srcdoc or iframes to easily achieve XSS

Considering the above bypasses, developers seeking to implement an effective Content-Security-Policy have a complex roadmap. Yet, it does not stop there, as there many advanced and exotic techniques that can even bypass strong CSPs:

Why are developers creating bad CSPs?!

Currently developers are not able to build a Content-Security-Policy that is actually immune to the bypasses above… With deadlines, business requirements and many other considerations — they just don't have the time and resources to reach expertise with this technology.

Also, since attackers will always seek the weakest link in policy, and it only takes 1 mistake on behalf of the developer to achieve a CSP bypass for XSS, Clickjacking, Formjacking, Data exfiltration, and more — the odds are stacked against the developer!

So how can developers implement a strong and effective Content-Security-Policy?

As we've seen in these bypasses, the many CSP directives actually work together in harmony and cannot be considered separately — with each directive requiring precision and know in its configuration.

CSPscanner.com is a free service that we've made to help developers and security professionals understand how to improve their CSPs for better protection — based on a wide cumulative knowledge base and accrued best-practice, and understanding of how attackers are bypassing directives today. It is also helpful to dissect how top companies such as github built their CSP — there really is a lot to learn from evaluating such good examples.

If you're looking to easily improve your web client-side security, try RapidSec.com which automates your deployment of CSP, secure cookie settings, and many other security headers — making sure your site is operating at it's full integrity without the regressions (CSP too strict), or getting bypassed (CSP too loose).

Closing thoughts:

CSP is a swiss-army knife for your Client-Side security efforts, that can block out entire groups of attacks when configured correctly. However, overcoming CSP bypasses is just one of many challenges associated with using this technology. If you think there is more to cover regarding CSP bypasses, or this technology in general — please let me know @Shai_Alon and I will look into it.

Credits for the articles/videos linked above:

@Bhavesh_Thakur_ , @mikispag, @we1x , @garethheyes , @Bo0oM , theMiddleBlue

Automate your CSP