The Web Content-Security-Policy (CSP) specifications, support a crucial directive called report-uri (and it’s newer successor report-to), which instructs the browser to issue a form of webook request, whenever the #CSP blocks a certain element from getting loaded on a page.

Why Should I use the report-uri Directive?

This ability is supported on all major browsers, comprising 98% of total web traffic (source: caniuse), and it’s a crucial element of your client-side defense-in-depth strategy for multiple reasons:

  1. Creating your first Content-Security-Policy
    The typical flow of rolling out a good CSP, comprises of running it first in Report-Only mode. Essentially we are giving the browser a CSP, and asking to get violation reports as-if it were enforced, but actually not blocking anything in practice (to avoid breaking legitimate parts of the site). These reports can be used to refine the CSP (more on this in a future blog post).
  2. Getting informed of blocked attacks
    Once you have your policy in live enforced mode – getting the violation reports is still highly important, as you want to be know of attacks immediately when they happen – in order to be able to act accordingly.
    Think of an #XSS (cross-site scripting) firing on your site, yet blocked by the CSP. You would still want to be notified in order to block the attacking user, and fix any underlying issues in your architecture that created the vulnerability.
  3. Run strict monitoring
    One common pattern that we see at RapidSec is running with “Dual policies”. Basically this would mean running a strict policy in Report-Only Mode – so that you get more violation reports for analysis, and a less strict policy, in order to prevent regressions to site functionality.

What are the challenges with collecting CSP logs?

Many developers set to generate a CSP for their site, try to setup their own report-uri endpoint in order to collect the browser logs. However, from indie developers to large enterprises, developers usually encounter these major obstacles:

  1. Scale, Scale, Scale
    Collecting the massive amounts of logs sent from your users’ browsers worldwide, requires a dedicated architecture for both data processing and querying.
    We’ve seen so many companies breaking an SQL DB into pieces, because it could not handle the needs of CSP log processing.
  2. Browser Quirks
    While theoretically all the browsers should be sending reports in the exact same W3C specs – in practice, there is an amplitude of implementation details to iron-out and abstract away when processing the data for data storage and querying.
  3. CSP-wtf injections
    You CSP will be blocking a lot of garbage that is trying to run inside you users’ pages. This is good, since it is not a legitimate part of your site, but was added by Malware infested browsers, creepy networks, rogue ad scripts and more. However, without prior dedicated knowledge about these, it can be really hard to separate the noise from the valuable information. Lists like CSP-wtf, try to explain the nature of these reports, but tackling this internally in an org is highly time consuming.

Side note: A major challenge of building the best CSP report-uri tool in the world at RapidSec, is abstracting away a lot of the noise – so that you don’t have to!

What do CSP analytics look like?

So after you collect all your CSP reports into your dedicated report-uri endpoint, what are the main Analytics abilities that you need?

  1. Slice and Dice
    Ability to easily extract the data points that you needs. The most commonly used filters by RapidSec users analyzing their CSP logs are
    Effective Directive. Was a Script / Style / Image / Frame / etc. blocked?
    Domain. Did it happen on my blog / marketing site / core application / etc. ?
    Blocked Host. Filter for specific blocked assets.
    Time. When did the the CSP violation occur?)
    Policy version. Since RapidSec generates policies with versions, it’s easy to understand for every report, which policy generated it.
  2. Drill-down
    So now that a specific piece of data has caught your attention, you can drill-down and learn more about this violation group, for example:
    Locations of the reports. Many times you may find that a specific report is related to one location. This is a common pattern with custom logic and ad scripts.
    Browsers. Many violation types are confined to one certain legacy browser. RapidSec makes it easy to know of this, and act.
    In-depth check of root problems. Reconstruct attacker strategies, and much more.
RapidSec CSP Analytics Dashboard GIF
RapidSec CSP Analytics dashboard – allows to easily
filter, slice and sort your data.

Conclusion of the RapidSec report-uri value for developers and IT professionals

So now that you understand how challenging and time-consuming it can be to roll-out your own CSP analysis technology, go ahead and sign up for the RapidSec.com CSP automation. It will make your life with this technology much easier. There is 14 day free trial, with a generous free tier after that.

Write A Comment