← All posts

Personal data in CSP reports: what GDPR means for browser reporting

CentralCSP Team

CentralCSP ·

CSP reports are security telemetry, and almost everything they contain is technical: a directive, a blocked origin, a line number. In practice they rarely hold sensitive personal data. A few fields can still relate to a visitor: the URL of the page they were on, sometimes the page they came from, their browser's user agent, and the IP address the report arrives from. Under the GDPR those can count as personal data, so it helps to know where they sit and which settings keep them out.

This post goes through the fields, the GDPR rules that apply (roles, legal basis, minimisation, retention, transfers) and the settings that let you collect less. It is written for the developer who sets up reporting and the DPO who signs off on it.

This is general information, not legal advice. Your DPO or counsel decides for your processing.

If you are choosing where to send reports, CentralCSP monitoring stores them in France, keeps them 90 days, and can drop query strings, fragments and referrers before storage. The Start plan has a 14-day free trial.

What a report contains

A CSP violation report sent through the Reporting API looks like this (the fields come from CSP Level 3 and the W3C Reporting API):

[
  {
    "type": "csp-violation",
    "age": 10,
    "url": "https://shop.example/account/orders?email=jane.doe%40mail.example",
    "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) ...",
    "body": {
      "documentURL": "https://shop.example/account/orders?email=jane.doe%40mail.example",
      "referrer": "https://www.search.example/?q=jane+doe+order+12345",
      "blockedURL": "inline",
      "effectiveDirective": "script-src-elem",
      "sourceFile": "https://shop.example/account/orders?email=jane.doe%40mail.example",
      "sample": "window.__USER__={\"id\":81723,\"name\":",
      "lineNumber": 42,
      "columnNumber": 7,
      "disposition": "report",
      "statusCode": 200
    }
  }
]

The example is invented, and deliberately puts personal data in every field that can hold it. On most sites the same report carries none. Here is where it can appear:

FieldCan it identify someone?Why
IP address of the senderOftenNot in the body, but your endpoint and any CDN in front of it receive it. The GDPR lists IP addresses among online identifiers (Recital 30), and the Court of Justice held that a dynamic IP address can be personal data for a website operator (C-582/14 Breyer).
url, documentURL, sourceFileSometimesThe browser strips fragments, usernames and passwords from URLs, but not the query string (CSP Level 3, "Strip URL for use in reports"). If a URL carries an email, a user id or a reset token, the report carries it too. Paths such as /users/81723/ count as well.
referrerSometimesThe previous page, which may be an external site with its own query string.
user_agentRarely on its ownThe Reporting API includes the User-Agent the browser sent. Combined with an IP and a timestamp, it narrows people down.
sampleSometimesWith 'report-sample' in the directive, the browser includes the first 40 characters of the blocked inline script, event handler or style (CSP Level 3). They contain user data only if your pages inline it.
blockedURLRarelyUsually a third-party host. It can contain identifiers when the blocked request itself carried them.
Directive, line, column, statusNoPurely technical.

Other report types follow the same pattern. A Network Error Logging report includes the referrer and the URL of the failed request; a deprecation or crash report includes the page URL.

The W3C spec itself flags the privacy side: a reporting endpoint "may learn that a particular user has interacted with a certain set of websites" when several sites share one endpoint, and browsers must let users disable reporting (Reporting API, Privacy Considerations).

Who is controller and who is processor

  • The website operator is the controller. You decide to collect reports, why, and with which tool.
  • A reporting service is a processor. It processes the reports on your behalf and under your instructions. Article 28 requires you to use only processors "providing sufficient guarantees" and to sign a contract with the content listed in Article 28(3): subject matter, duration, instructions, confidentiality, security, sub-processors, assistance, deletion or return at the end, and audits. The EDPB's Guidelines 07/2020 on the concepts of controller and processor (final version, 7 July 2021) explain the split in detail.
  • If you self-host, there is no reporting processor, but your hosting provider still processes the data, and you carry the whole security and retention burden.

Add the processing to your record of processing activities (Article 30): purpose, categories of data, recipients, transfers, retention.

For security monitoring, the usual basis is legitimate interest, Article 6(1)(f). Recital 49 supports it directly: processing "to the extent strictly necessary and proportionate for the purposes of ensuring network and information security" constitutes a legitimate interest of the controller. Detecting script injection on your pages fits that description.

Legitimate interest is not automatic. You still need to:

  • Document the balancing test. What you collect, why it is needed, and why it does not override visitors' interests. Minimisation (next section) is what makes the test easy to pass.
  • Inform visitors. Mention security telemetry and its recipients in your privacy notice (Articles 13 and 14).
  • Keep it to security. Reusing reports for marketing analytics needs its own basis.

Minimisation and retention

Two principles of Article 5(1) shape what you keep:

  • Data minimisation, point (c): data must be "adequate, relevant and limited to what is necessary". To fix a CSP, you need the directive, the blocked resource and the page. You rarely need the query string, never need the visitor's search terms, and almost never need their IP.
  • Storage limitation, point (e): data kept in identifiable form "for no longer than is necessary". The GDPR gives no number. Set one that matches the purpose. Rolling out a policy and catching a new script take weeks, not years. For comparison, the CNIL's 2021 recommendation on logging suggests six months to a year for logs of authorised users' actions on information systems, a different and more sensitive purpose than violation reports.

Security of processing (Article 32) applies too: restrict who can read raw reports, and log exports.

Practical steps to collect less

A few settings keep reports to what you need to fix a policy.

  1. Keep personal data out of URLs. Use POST bodies or the fragment for anything sensitive. The browser strips fragments from reports, so #token=... never reaches your collector while ?token=... does.
  2. Strip query strings and fragments at ingestion. Do it before storage, not at display time. In CentralCSP, turn on Drop query strings and fragments in the website's ingestion settings. It is off when you create a site.
  3. Drop the referrer. It rarely helps fix a policy and often carries third-party URLs.
  4. Do not store the sender's IP. If your collector or CDN logs requests, set a short log retention or truncate addresses. You do not need the IP to fix a CSP.
  5. Decide on 'report-sample'. Depending on your scripts and how your code is written, you may prefer to leave it out if inline code could contain personal data.
  6. Filter extension reports. They are noise, and they describe the visitor's software rather than your site.
  7. Set a fixed retention and make deletion work: per site, per period, on request.
  8. Restrict accepted origins so third parties cannot fill your store with their data.

How to choose a processor

Ask each vendor for:

  • A DPA that covers the Article 28(3) points, with a named sub-processor list, a notice period for changes and a way to object.
  • Location of storage, backups and the edge in front of the endpoint, and any transfer outside the EEA with its mechanism: an adequacy decision such as the EU-US Data Privacy Framework, or Standard Contractual Clauses (Articles 44 to 46). The EU data residency comparison lists what each CSP reporting service publishes.
  • Defaults: what is stored from each report out of the box, and what you can strip before storage.
  • Retention and deletion: a fixed period, deletion on request, deletion at contract end.
  • Breach notification: how fast the vendor tells you, so you can notify the supervisory authority within 72 hours where feasible, as Article 33 requires of you.

What CentralCSP does

  • Role: CentralCSP acts as your processor for browser reports, under a DPA that follows Article 28. We notify you of new sub-processors 30 days in advance, and of a personal data breach within 72 hours of becoming aware of it.
  • What we process: the page URL, blocked URL, referrer, directives, error details, user agent and operating system. An IP address can appear where a URL or blocked resource is itself an IP, and identifiers can appear where they are embedded in a URL or query string. Our Bunny.net edge, restricted to EU points of presence, processes the request IP in transit.
  • Minimisation controls: three ingestion filters drop query strings and fragments, referrers and extension reports before anything is stored. They are off when you create a site, so turn on what fits your URLs. Allowed origins stops anyone else from posting to your endpoint.
  • Retention: a fixed 90 days for reports, then deletion or irreversible aggregation. Reset reports or deleting a site removes them earlier.
  • Location: stored and backed up on OVHcloud in France, with no transfer outside the EEA in the ordinary course. Alert channels and AI tools you connect are destinations you choose.
  • Access: role-based access per website, audit logs of every export, and enforceable two-factor authentication.

To see what your own reports contain before deciding, connect a staging site and open the Explorer: it shows each payload as stored, after filters.

Sources