← Tous les articles

Rapports CSP et RGPD : les données personnelles qu'ils contiennent

CentralCSP Team

CentralCSP ·

Les rapports CSP sont de la télémétrie de sécurité, et presque tout leur contenu est technique : une directive, une origine bloquée, un numéro de ligne. En pratique, ils contiennent rarement des données personnelles sensibles. Quelques champs peuvent tout de même se rapporter à un visiteur : l'URL de la page qu'il consultait, parfois celle d'où il venait, le user agent de son navigateur et l'adresse IP d'où part le rapport. Au sens du RGPD, ces éléments peuvent constituer des données personnelles : mieux vaut donc savoir où ils se trouvent, et quels réglages les écartent.

Cet article passe en revue les champs, les règles du RGPD qui s'appliquent (rôles, base légale, minimisation, conservation, transferts) et les réglages qui permettent d'en collecter moins. Il s'adresse au développeur qui met en place le reporting comme au DPO qui le valide.

Il s'agit d'une information générale, pas d'un conseil juridique. C'est votre DPO ou votre conseil qui tranche pour vos traitements.

Si vous choisissez où envoyer vos rapports, le monitoring CentralCSP les stocke en France, les conserve 90 jours et peut retirer query strings, fragments et référents avant stockage. Le plan Start inclut un essai gratuit de 14 jours.

Ce que contient un rapport

Voici un rapport de violation CSP envoyé par le Reporting API (les champs viennent de CSP Level 3 et du Reporting API du W3C) :

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

L'exemple est inventé, et place volontairement des données personnelles dans chaque champ qui peut en contenir. Sur la plupart des sites, le même rapport n'en contient aucune. Voici où elles peuvent apparaître :

ChampPeut-il identifier quelqu'un ?Pourquoi
Adresse IP de l'émetteurSouventElle n'est pas dans le corps, mais votre endpoint et tout CDN placé devant la reçoivent. Le RGPD cite les adresses IP parmi les identifiants en ligne (considérant 30), et la Cour de justice a jugé qu'une adresse IP dynamique peut être une donnée personnelle pour l'exploitant d'un site (C-582/14 Breyer).
url, documentURL, sourceFileParfoisLe navigateur retire des URL le fragment, l'identifiant et le mot de passe, mais pas la query string (CSP Level 3, « Strip URL for use in reports »). Si une URL contient un e-mail, un identifiant ou un jeton de réinitialisation, le rapport le contient aussi. Des chemins comme /utilisateurs/81723/ comptent également.
referrerParfoisLa page précédente, qui peut être un site externe avec sa propre query string.
user_agentRarement à lui seulLe Reporting API reprend le User-Agent envoyé par le navigateur. Croisé avec une IP et un horodatage, il resserre l'identification.
sampleParfoisQuand la directive contient 'report-sample', le navigateur joint les 40 premiers caractères du script inline, du gestionnaire d'événement ou du style bloqué (CSP Level 3). Ils ne contiennent des données utilisateur que si vos pages en intègrent en inline.
blockedURLRarementEn général un hôte tiers. Il peut contenir des identifiants si la requête bloquée en portait.
Directive, ligne, colonne, statutNonPurement techniques.

Les autres types de rapports suivent la même logique. Un rapport Network Error Logging contient le référent et l'URL de la requête en échec ; un rapport de dépréciation ou de crash contient l'URL de la page.

La spécification du W3C souligne elle-même l'enjeu : un endpoint partagé par plusieurs sites « may learn that a particular user has interacted with a certain set of websites » (peut apprendre qu'un utilisateur donné a visité un ensemble de sites), et les navigateurs doivent permettre aux utilisateurs de désactiver le reporting (Reporting API, Privacy Considerations).

Qui est responsable de traitement, qui est sous-traitant

  • L'exploitant du site est responsable de traitement. C'est vous qui décidez de collecter des rapports, pourquoi, et avec quel outil.
  • Un service de reporting est sous-traitant. Il traite les rapports pour votre compte et sur vos instructions. L'article 28 impose de ne faire appel qu'à des sous-traitants « qui présentent des garanties suffisantes » et de signer un contrat reprenant les points de l'article 28, paragraphe 3 : objet, durée, instructions, confidentialité, sécurité, sous-traitants ultérieurs, assistance, suppression ou restitution en fin de contrat, audits. Les lignes directrices 07/2020 de l'EDPB sur les notions de responsable du traitement et de sous-traitant (version finale du 7 juillet 2021) détaillent ce partage.
  • Si vous hébergez vous-même, il n'y a pas de sous-traitant de reporting, mais votre hébergeur traite toujours les données, et vous portez seul la sécurité et la conservation.

Inscrivez le traitement à votre registre des activités de traitement (article 30) : finalité, catégories de données, destinataires, transferts, durée de conservation.

La base légale

Pour la surveillance de sécurité, la base habituelle est l'intérêt légitime, article 6, paragraphe 1, point f). Le considérant 49 l'appuie directement : le traitement « dans la mesure strictement nécessaire et proportionnée aux fins de garantir la sécurité du réseau et des informations » constitue un intérêt légitime du responsable du traitement. Détecter une injection de script sur vos pages correspond à cette description.

L'intérêt légitime n'est pas automatique. Il faut encore :

  • Documenter la mise en balance. Ce que vous collectez, pourquoi c'est nécessaire, et pourquoi cela ne l'emporte pas sur les intérêts des visiteurs. La minimisation (section suivante) est ce qui rend ce test facile à passer.
  • Informer les visiteurs. Mentionnez la télémétrie de sécurité et ses destinataires dans votre politique de confidentialité (articles 13 et 14).
  • S'en tenir à la sécurité. Réutiliser les rapports pour de l'analyse marketing demande une autre base.

Minimisation et durée de conservation

Deux principes de l'article 5, paragraphe 1 cadrent ce que vous gardez :

  • Minimisation, point c) : des données « adéquates, pertinentes et limitées à ce qui est nécessaire ». Pour corriger une CSP, il vous faut la directive, la ressource bloquée et la page. La query string sert rarement, les termes de recherche du visiteur jamais, son IP presque jamais.
  • Limitation de la conservation, point e) : une identification possible « pendant une durée n'excédant pas celle nécessaire ». Le RGPD ne fixe pas de chiffre : choisissez-en un qui colle à la finalité. Déployer une politique et repérer un nouveau script prend des semaines, pas des années. À titre de comparaison, la recommandation de la CNIL sur la journalisation (2021) préconise de six mois à un an pour les traces des actions des utilisateurs habilités sur un système d'information, une finalité différente et plus sensible que les rapports de violation.

La sécurité du traitement (article 32) s'applique aussi : limitez qui peut lire les rapports bruts, et tracez les exports.

En pratique : collecter moins

Quelques réglages suffisent pour ne garder que ce qui sert à corriger une politique.

  1. Sortez les données personnelles des URL. Passez par le corps d'un POST ou par le fragment pour tout ce qui est sensible. Le navigateur retire le fragment des rapports : #jeton=... n'atteint jamais votre collecteur, ?jeton=... si.
  2. Retirez query strings et fragments à l'ingestion. Avant le stockage, pas au moment de l'affichage. Dans CentralCSP, activez Supprimer les query strings et les fragments dans les réglages d'ingestion du site. Le réglage est désactivé à la création d'un site.
  3. Supprimez le référent. Il aide rarement à corriger une politique et contient souvent des URL de sites tiers.
  4. Ne stockez pas l'IP de l'émetteur. Si votre collecteur ou votre CDN journalise les requêtes, réduisez la durée de ces logs ou tronquez les adresses. Corriger une CSP ne demande pas d'IP.
  5. Décidez pour 'report-sample'. Selon vos scripts et la façon dont votre code est écrit, vous préférerez peut-être vous en passer si du code inline peut contenir des données personnelles.
  6. Écartez les rapports d'extensions. C'est du bruit, et ils décrivent les logiciels du visiteur plutôt que votre site.
  7. Fixez une durée de conservation et faites fonctionner la suppression : par site, par période, à la demande.
  8. Limitez les origines acceptées pour que des tiers ne remplissent pas votre stockage avec leurs propres données.

Choisir un sous-traitant

Demandez à chaque fournisseur :

  • Un DPA couvrant les points de l'article 28, paragraphe 3, avec une liste nominative des sous-traitants ultérieurs, un préavis pour les changements et un droit d'opposition.
  • La localisation du stockage, des sauvegardes et de la périphérie devant l'endpoint, et tout transfert hors de l'EEE avec son mécanisme : une décision d'adéquation comme le cadre de protection des données UE-États-Unis, ou des clauses contractuelles types (articles 44 à 46). La comparaison sur l'hébergement dans l'UE reprend ce que publie chaque service de reporting CSP.
  • Les réglages par défaut : ce qui est stocké de chaque rapport sans rien configurer, et ce qu'on peut retirer avant stockage.
  • Conservation et suppression : une durée fixe, la suppression à la demande, la suppression en fin de contrat.
  • La notification des violations de données : le délai sous lequel le fournisseur vous prévient, pour que vous puissiez notifier l'autorité dans les 72 heures si possible, comme l'article 33 vous l'impose.

Ce que fait CentralCSP

  • Rôle : CentralCSP est votre sous-traitant pour les rapports navigateur, dans le cadre d'un DPA conforme à l'article 28. Nous vous prévenons 30 jours à l'avance de tout nouveau sous-traitant ultérieur, et de toute violation de données personnelles dans les 72 heures après en avoir pris connaissance.
  • Ce que nous traitons : l'URL de la page, l'URL bloquée, le référent, les directives, les détails d'erreur, le user agent et le système d'exploitation. Une adresse IP peut apparaître quand une URL ou une ressource bloquée est elle-même une IP, et des identifiants peuvent apparaître quand ils figurent dans une URL ou une query string. Notre périphérie Bunny.net, limitée à des points de présence européens, traite l'IP de la requête en transit.
  • Réglages de minimisation : trois filtres d'ingestion retirent query strings et fragments, retirent le référent et écartent les rapports d'extensions avant tout stockage. Ils sont désactivés à la création d'un site : activez ce qui convient à vos URL. La liste des origines autorisées empêche quiconque d'autre de poster sur votre endpoint.
  • Conservation : 90 jours, durée fixe, puis suppression ou agrégation irréversible. Réinitialiser les rapports ou supprimer un site les efface plus tôt.
  • Localisation : stockage et sauvegardes chez OVHcloud en France, sans transfert hors de l'EEE dans le cours normal du service. Les canaux d'alerte et outils IA que vous connectez sont des destinations de votre choix.
  • Accès : droits par site selon les rôles, journal d'audit de chaque export, double authentification imposable.

Pour voir ce que contiennent vos propres rapports avant de décider, connectez un site de préproduction et ouvrez l'Explorer : il affiche chaque charge utile telle que stockée, après filtres.

Sources

Articles liés