ÉduConnect : 7,2 M de bulletins volés via IDOR

Ce qui s'est passé : une faille d'une simplicité embarrassante

Fin avril 2026, une faille de type IDOR (Insecure Direct Object Reference) découverte sur la plateforme ÉduConnect — le portail d'authentification nationale utilisé par les familles françaises pour accéder aux services scolaires — a permis l'exfiltration de 7,2 millions de bulletins scolaires. L'attaque ne nécessitait aucun outil sophistiqué : il suffisait de modifier un identifiant numérique dans l'URL de l'API pour accéder aux données d'un autre élève.

Concrètement, une requête comme :

GET /api/bulletins?eleve_id=1042837

devenait :

GET /api/bulletins?eleve_id=1042838

Et le serveur répondait avec les données de l'élève suivant — nom, prénom, établissement, notes, appréciations des enseignants — sans aucune vérification que l'utilisateur connecté avait le droit d'accéder à ce dossier.

Pourquoi l'IDOR est la faille la plus sous-estimée du web

L'IDOR figure dans le Top 10 OWASP depuis des années (catégorie A01:2021 – Broken Access Control), pourtant elle reste l'une des vulnérabilités les plus fréquemment exploitées en production. La raison est simple : elle ne résulte pas d'un bug de code complexe, mais d'une erreur de conception — l'oubli de vérifier côté serveur que l'utilisateur A a bien le droit d'accéder à la ressource B.

Dans le cas d'ÉduConnect, l'API faisait confiance à l'identifiant fourni par le client sans croiser l'identité de la session authentifiée. C'est un pattern classique qu'on retrouve dans des milliers d'applications, notamment celles construites rapidement avec des frameworks comme Laravel, Django, Express ou des solutions no-code.

L'ampleur des données exposées

Selon les premières analyses publiées, les données accessibles comprenaient :

• Nom, prénom et date de naissance des élèves
• Établissement scolaire (collège, lycée)
• Bulletins complets avec notes par matière et appréciations
• Coordonnées des représentants légaux dans certains cas

Soit des données particulièrement sensibles au regard du RGPD, puisqu'elles concernent des mineurs. La CNIL a ouvert une enquête formelle. Le ministère de l'Éducation nationale a confirmé l'incident et affirmé avoir colmaté la brèche, sans préciser la fenêtre temporelle pendant laquelle l'API était vulnérable.

L'ANSSI a été saisie pour auditer l'infrastructure. Selon les premières déclarations, l'exfiltration aurait été automatisée via un script itérant séquentiellement sur les identifiants — une technique triviale mais efficace quand aucun rate limiting n'est en place.

Pourquoi vos propres projets sont probablement vulnérables

Si vous construisez une application web — que ce soit une SaaS, une boutique Shopify personnalisée, un plugin WordPress, ou une app no-code — voici les patterns à risque :

Pattern 1 : IDs séquentiels exposés dans les URLs

/orders/10542
/invoices/88721
/profile/edit/3301

Si ces IDs sont prévisibles et que votre backend ne vérifie pas l'appartenance de la ressource à l'utilisateur courant, vous êtes vulnérable.

Pattern 2 : APIs REST sans vérification d'appartenance

// ❌ Dangereux
app.get('/api/documents/:id', async (req, res) => {
  const doc = await Document.findById(req.params.id);
  res.json(doc);
});

// ✅ Correct
app.get('/api/documents/:id', async (req, res) => {
  const doc = await Document.findOne({
    _id: req.params.id,
    owner: req.user.id  // vérification d'appartenance
  });
  if (!doc) return res.status(403).json({ error: 'Forbidden' });
  res.json(doc);
});

Pattern 3 : UUIDs comme faux rempart Beaucoup de développeurs pensent que passer à des UUIDs (ex: /api/bulletins/f47ac10b-58cc-4372-a567-0e02b2c3d479) résout le problème. Ce n'est pas vrai : si le serveur ne vérifie pas l'autorisation, un attaquant qui obtient un UUID valide par un autre moyen peut quand même accéder aux données.

Ce que les tests automatisés détectent (et ce qu'ils ratent)

Les scanners de sécurité traditionnels ont du mal avec les IDOR car la faille est contextuelle : elle dépend des relations entre utilisateurs et ressources. Un scanner doit être capable de :

1. S'authentifier avec plusieurs comptes distincts
2. Collecter les identifiants de ressources d'un compte
3. Tenter d'y accéder depuis un autre compte
4. Comparer les réponses pour détecter les accès non autorisés

C'est exactement ce que fait Scorra : en simulant plusieurs sessions utilisateurs, le scanner identifie automatiquement les endpoints où des ressources d'un compte sont accessibles depuis un autre compte. Sur une application comme ÉduConnect, ce type de test aurait flaggué la faille avant mise en production.

Les obligations légales en jeu

En France, une faille exposant des données de mineurs déclenche des obligations spécifiques :

• Notification à la CNIL sous 72 heures (article 33 RGPD) dès que la violation est constatée
• Notification aux personnes concernées si le risque est élevé (article 34 RGPD)
• Risque de sanction pouvant atteindre 4% du chiffre d'affaires mondial ou 20 millions d'euros

Pour un service public comme ÉduConnect, les conséquences politiques s'ajoutent aux sanctions réglementaires. Mais pour une startup ou un éditeur SaaS, une faille IDOR sur des données clients peut être fatale.

Comment se protéger concrètement

1. Auditez tous vos endpoints qui acceptent un identifiant de ressource en paramètre
2. Implémentez une vérification d'appartenance systématique côté serveur — jamais côté client
3. Activez le rate limiting sur vos APIs pour rendre l'énumération coûteuse
4. Loggez les accès anormaux : un utilisateur qui itère sur des centaines d'IDs en quelques secondes doit déclencher une alerte
5. Testez avec plusieurs comptes : votre suite de tests doit inclure des scénarios cross-account

---

L'affaire ÉduConnect illustre un principe fondamental : les failles les plus dévastatrices ne sont pas toujours les plus sophistiquées. Un chiffre incrémenté dans une URL a suffi à compromettre les données scolaires de millions d'enfants français.

Scannez vos APIs avant que quelqu'un d'autre ne le fasse. Lancez un scan gratuit sur scorra.io →