Retour au blog
RGPDconformitéAPI

CNIL 2026 : les nouvelles recommandations sur la sécurité des API

Publié le 2026-06-087 min de lectureCleanIssue

Pourquoi la CNIL s'intéresse aux API

Les API sont devenues le principal vecteur d'échange de données dans les SaaS RH. Chaque fois qu'un logiciel de paie transmet un bulletin à un coffre-fort numérique, qu'un ATS envoie un profil candidat à un outil d'évaluation, ou qu'un SIRH synchronise les absences avec la DSN, une API est sollicitée.

Le problème : beaucoup de ces API exposent plus de données que nécessaire, ne vérifient pas correctement les droits d'accès, ou journalisent insuffisamment les appels. La CNIL l'a constaté lors de ses contrôles 2025 et a décidé de mettre à jour ses recommandations.

Ce qui change concrètement

Authentification et autorisation

La CNIL insiste désormais sur la séparation stricte entre authentification (qui appelle ?) et autorisation (a-t-il le droit ?). Les tokens d'API doivent avoir une durée de vie limitée — la recommandation est de 15 minutes maximum pour les access tokens — et les refresh tokens doivent être révocables individuellement.

Pour un éditeur de paie, ça signifie qu'un token généré pour synchroniser les salaires ne doit pas pouvoir accéder aux dossiers disciplinaires. Le principe du moindre privilège, appliqué endpoint par endpoint.

Minimisation des données

Nouveau point fort : chaque endpoint doit retourner uniquement les champs nécessaires à l'usage déclaré. Un partenaire qui a besoin du nom et de l'email d'un collaborateur ne doit pas recevoir son numéro de sécurité sociale dans la même réponse, même si le champ existe dans la base.

La CNIL recommande désormais des mécanismes de projection côté serveur (fields filtering) plutôt que de compter sur le client pour ignorer les champs inutiles.

Journalisation

Toute API traitant des données sensibles doit journaliser :

  • L'identité de l'appelant
  • L'endpoint sollicité
  • Les paramètres de requête (sans les données personnelles elles-mêmes)
  • Le code de réponse
  • L'horodatage
  • Ces logs doivent être conservés 6 mois minimum et être exploitables en cas de contrôle.

    Impact pour les éditeurs SaaS RH

    Si vous développez un logiciel RH, de paie ou de recrutement, ces recommandations ne sont pas optionnelles. La CNIL les utilise comme référentiel lors de ses contrôles. Ne pas les suivre, c'est s'exposer à une mise en demeure.

    Concrètement, voici les actions à mener :

  • Auditer vos endpoints : listez tous vos endpoints, les données qu'ils exposent, et vérifiez que chaque champ retourné est justifié par un usage documenté.
  • Revoir vos scopes OAuth : si vous utilisez OAuth2, vérifiez que vos scopes sont granulaires. Un scope read:employees est trop large — préférez read:employees:identity et read:employees:payroll.
  • Implémenter le rate limiting : la CNIL considère que l'absence de rate limiting sur une API exposant des données personnelles est une négligence.
  • Tester en conditions réelles : un test automatisé ne suffit pas. Il faut vérifier ce qu'un appelant malveillant pourrait obtenir en manipulant les paramètres.
  • Comment CleanIssue peut aider

    Notre audit API et webhooks vérifie exactement ces points. On teste vos endpoints comme le ferait un attaquant : en manipulant les paramètres, en testant les contrôles d'accès, en cherchant les fuites de données dans les réponses. Le rapport inclut les recommandations de la CNIL en regard de chaque constat.

    Si vous êtes éditeur SaaS RH et que vous n'avez jamais fait auditer vos API, c'est le moment.

    Articles liés

    Trois analyses proches pour continuer la lecture sur la meme surface de risque.

    Sources

    Rédigé par CleanIssue
    Revu le 2026-06-08

    Services associés

    Si ce sujet reflète un risque concret sur votre stack, voici les audits CleanIssue les plus pertinents.

    Besoin d'une revue externe de votre SaaS RH ?

    Expliquez votre produit, votre stack et votre contexte client. Nous revenons vers vous avec le bon niveau de revue.

    Parler de votre audit