Sécurité des API et CNIL : les 5 failles visées en 2026

Pourquoi la CNIL regarde vos API

Les API transportent aujourd’hui l’essentiel des données personnelles d’un produit SaaS : synchronisation avec un outil comptable, envoi d’un profil vers un service tiers, application mobile qui lit le compte de l’utilisateur. Lors d’un contrôle, la CNIL ne lit pas votre code. Elle regarde ce qu’un appelant peut obtenir, ce que vous journalisez et ce que vous savez prouver.

Les recommandations publiées en 2026 se lisent donc comme une liste de failles à ne pas avoir. Les voici, avec la manière de les vérifier.

Faille 1 : l’exposition excessive de données

Un endpoint GET /api/users/{id} renvoie l’objet complet de la base : nom, e-mail, mais aussi numéro de sécurité sociale, IBAN, hash du mot de passe ou notes internes. Le front n’affiche que deux champs, donc personne ne remarque le reste. Un attaquant qui ouvre l’onglet réseau, lui, voit tout.

C’est la catégorie « Broken Object Property Level Authorization » de l’OWASP API Top 10. La correction consiste à définir explicitement les champs renvoyés pour chaque usage (sérialiseurs, projections côté serveur, DTO) et à ne jamais renvoyer un enregistrement brut.

Faille 2 : l’accès aux objets des autres (BOLA / IDOR)

L’API vérifie que l’appelant est connecté, mais pas que l’objet demandé lui appartient. Remplacer invoice_id=1042 par 1043 affiche la facture d’un autre client. C’est la faille d’API la plus fréquente et la plus grave, détaillée dans notre article sur les failles BOLA et IDOR.

La CNIL insiste sur la séparation entre authentification (qui appelle) et autorisation (a-t-il le droit sur cet objet précis). La vérification doit se faire côté serveur, objet par objet, à chaque requête.

Faille 3 : des tokens trop puissants et trop longs

Un token créé pour synchroniser des absences peut aussi lire les dossiers RH complets. Un token d’intégration n’expire jamais. Un refresh token ne peut pas être révoqué individuellement. Dans tous ces cas, la fuite d’un seul secret donne accès à tout.

Bonnes pratiques attendues :

• des scopes granulaires (read:employees:identity séparé de read:employees:payroll) ;
• des access tokens de courte durée, quelques minutes à une heure selon la sensibilité ;
• des refresh tokens révocables un par un, et une rotation à chaque usage ;
• un token par intégration, jamais un token partagé entre plusieurs partenaires.

Faille 4 : pas de limitation de débit

Sans rate limiting, un attaquant qui a trouvé une BOLA peut aspirer toute la base en itérant sur les identifiants, et un formulaire de connexion devient une cible de bourrage d’identifiants. L’absence de limitation est aussi ce qui rend l’énumération d’utilisateurs rentable. La limitation doit s’appliquer par compte, par token et par adresse IP, avec des seuils plus bas sur les endpoints sensibles (connexion, réinitialisation, export).

Faille 5 : une journalisation inexploitable

Après un incident, la première question est : quelles données ont été lues, par qui, quand ? Si vos logs ne contiennent ni l’identité de l’appelant, ni l’endpoint, ni l’identifiant de l’objet demandé, vous ne pouvez pas répondre, et vous ne pouvez pas délimiter la notification à la CNIL.

Ce qu’il faut journaliser pour chaque appel touchant des données personnelles : identité de l’appelant (utilisateur ou token), endpoint, identifiants des objets demandés, code de réponse, horodatage. Sans les données elles-mêmes. La recommandation générale de la CNIL sur la journalisation prévoit une conservation de six mois à un an.

Comment le tester

Vous pouvez faire une première passe vous-même en une demi-journée :

1. Créez deux comptes de test dans deux organisations différentes (A et B), avec des données factices.
2. Passez le trafic par un proxy (Burp Suite, Caido ou mitmproxy) et naviguez dans l’application avec le compte A.
3. Exposition excessive : pour chaque réponse JSON, comparez les champs reçus avec ceux affichés à l’écran. Tout champ sensible non affiché est un constat.
4. BOLA : rejouez chaque requête du compte A en remplaçant les identifiants par ceux des objets du compte B. Un code 200 avec des données de B est une faille critique.
5. Scopes : avec un token d’intégration, appelez des endpoints hors de son usage déclaré. Notez ceux qui répondent.
6. Rate limiting : envoyez 200 requêtes rapides sur la connexion et sur un endpoint de lecture. L’absence de code 429 est un constat.
7. Logs : déclenchez une lecture précise avec le compte A, puis vérifiez que vous retrouvez cet appel dans vos journaux avec l’identité, l’objet et l’heure.

Si un test révèle une fuite, arrêtez-vous à la preuve : constatez que les données sont lisibles, sans les télécharger.

Ce que ça change quand un agent IA appelle vos API

Un agent IA connecté à vos API par function calling ou par un serveur MCP hérite des droits de son token. Si ce token est trop large, une injection de prompt cachée dans un e-mail ou un document suffit à lui faire lire, puis renvoyer ailleurs, des données qu’aucun utilisateur n’aurait dû voir. L’agent sait itérer sur des identifiants et ne se lasse pas : sans limitation de débit, il devient un outil d’extraction très efficace.

Les mêmes règles s’appliquent, plus strictement : un token dédié à l’agent avec le minimum de scopes, une vérification d’autorisation par objet, des plafonds de volume, et des journaux qui distinguent les appels de l’agent de ceux des humains. Notre article sur la surface d’attaque du function calling détaille ces scénarios.

Par où commencer

Commencez par les endpoints qui renvoient des données d’identité, de santé, de paie ou bancaires, et par ceux qu’utilisent vos intégrations et vos agents. Si vous voulez savoir ce qu’un attaquant obtient réellement en passant par l’agent IA branché sur ces API, le Red Team Agent Express teste ce scénario en cinq jours, avec des preuves pour chaque constat.