Audit conformité usage API 42 — Swifty Companion

Date : audit local dépôt de travail
Contraintes respectées : aucune lecture du fichier .env local actuel ; aucune requête vers api.intra.42.fr.

Objectif : vérifier si le code et le dépôt peuvent expliquer une extraction massive (~140k profils) du type décrit par le mail 42 — ou seulement un usage pédagogique ponctuel.

1. Verdict global

Question	Réponse
Le code Flutter ressemble-t-il à un scraper massif ?	Non
Usage prévu du sujet Swifty Companion ?	Oui (1 login → 1 profil)
Risque d’être l’auteur principal de la fuite nationale décrite ?	Très improbable si tu n’as pas lancé d’autres scripts
Point sécurité à corriger dans ton Git ?	Oui — voir §4

2. Analyse du code (`swiftyCompanion/swifty_companion/lib/`)

Appels API présents

Fichier	Comportement	Volume typique
`intra_user_service.dart`	`GET /v2/users?filter[login]=<un login>`	1 utilisateur par recherche
`intra_profile_service.dart`	`GET /users/{login}`, évent. `cursus_users`, `projects_users` (page 100)	1 profil par navigation
`intra_auth_service.dart`	OAuth + `GET /me` + refresh token	Session
`intra_http.dart`	GET avec retry 429, refresh sur 401	Par requête ci-dessus

Absent du dépôt (recherché)

Pas de script sh / py d’export massif
Pas de boucle sur campus / pagination page[number] sur tous les users
Pas de filter[campus], pas de dump CSV/JSON de milliers de profils
Pas de stockage fichier des profils (cache mémoire 2 min, 1 id à la fois)

Conclusion technique : l’application ne peut pas, seule, extraire 140k profils sans modification majeure du code.

3. Lien avec le mail école

Le mail décrit :

extraction automatisée à très grande échelle ;
multi-campus, candidats + étudiants ;
via un compte légitime (pas forcément ton app OAuth).

Ton projet :

recherche manuelle par login ;
quelques requêtes par profil ;
aligné sur le sujet (« consulter un pair »).

Ce n’est pas le même profil d’usage, sauf si tu as en plus utilisé un autre outil, un script perso, ou partagé des données.

4. Risque sécurité — dépôt Git (hors fuite massive)

Audit Git sans afficher les valeurs des secrets :

Élément	État
`swifty_companion/.env`	Ignoré par `.gitignore` (OK)
`swifty_companion/.env copy`	Versionné dans Git (commit `06fe43b`)
Contenu versionné	Présence de `CLIENT_ID` et `CLIENT_SECRET` dans ce fichier (valeurs non recopiées dans ce document)
Remote	`origin` → Gitea privé perso (pas Vogosphere 42)

Risque : si le dépôt est privé et que toi seul y as accès, l’exposition des clés via .env copy est limitée (pas équivalent à un repo public). Ça ne te relie pas à l’incident ~140k profils. Reste une mauvaise pratique (historique Git + sujet 42) : régénérer le SECRET si tu as déjà poussé ce fichier, retirer .env copy du suivi Git pour l’avenir.

Actions recommandées (à faire de ton côté)

Régénérer le SECRET sur Applications OAuth Intra (même si déjà fait après le chat).
Retirer swifty_companion/.env copy du suivi Git (git rm --cached, supprimer le fichier, commit).
Si le dépôt distant a déjà reçu ce fichier : considérer réécriture d’historique ou invalidation des anciens secrets (SECRET régénéré = ancien jeton mort).
Ne jamais committer .env, captures avec clés, ou dumps de profils.

5. Ce que cet audit n’a pas fait

Pas d’appel à l’API 42 (pas de logs côté 42 consultés).
Pas de lecture du .env actuel sur disque.
Pas d’accès aux serveurs 42 / pas de corrélation avec l’enquête interne.

Seul 42 ou la police pourrait lier un compte OAuth à un volume de requêtes précis.

6. En cas de contact DPO / campus

Tu peux décrire factuellement :

projet Swifty Companion (Flutter) ;
recherche par login uniquement ;
pas d’export massif dans le code livré ;
app OAuth pédagogique avec scopes public + projects.

Contact mail incident : dpo@42.tech (comme indiqué par l’école).

7. Références

guide-soutenance-realisation.md — cartographie sujet ↔ code
sujet traduit — usage autorisé vs extraction massive (CGU 42)

4.6 KiB Raw Blame History Unescape Escape