Amendes à 10 % du CA en Corée : la faille derrière Coupang

Ce que change le décret coréen

Le décret d'application de la loi révisée sur la protection des informations personnelles entre en vigueur le 11 septembre 2026 :

• Amende jusqu'à 10 % du chiffre d'affaires total pour une fuite de 10 millions de personnes ou plus, par intention ou négligence grave.
• Notification sous 72 h dès que le risque d'exposition est élevé, même si la fuite n'est pas encore confirmée.
• Jusqu'à 40 % de réduction pour les entreprises qui investissent dans la protection des données et qui détectent ou notifient vite.
• Un CPO renforcé : sa nomination et sa révocation passent par le conseil d'administration dans les grandes entreprises.

Le texte récompense donc deux capacités techniques précises : empêcher l'accès illégitime et le détecter tôt. Coupang a échoué sur les deux.

La faille : une clé de signature qui survit au départ de son détenteur

D'après les éléments publiés par le régulateur et la presse coréenne, un ancien développeur de l'équipe d'authentification avait eu accès, pendant son contrat, à une clé servant à signer les jetons d'accès. À son départ, la clé n'a été ni révoquée ni renouvelée. Elle a ensuite servi à fabriquer des jetons valides, présentés au système comme s'ils sortaient du vrai serveur d'authentification. Le système les a acceptés sans contrôle supplémentaire. Le gouvernement coréen parle de 33,7 millions de comptes concernés.

Trois défauts se cumulent :

1. Une clé de signature longue durée, copiée hors de son coffre (les enquêteurs évoquent des clés stockées sur des postes de développeurs).
2. Aucune rotation au départ d'une personne qui y avait eu accès.
3. Aucune détection : des accès anormaux depuis l'étranger ont duré plusieurs mois avant d'être repérés.

Pourquoi c'est si grave avec des JWT

Avec des jetons signés de type JWT, le serveur vérifie seulement que la signature est valide. Il ne consulte aucune base pour savoir si le jeton a réellement été émis. Celui qui détient la clé privée (ou le secret HMAC) peut donc émettre n'importe quel jeton, pour n'importe quel utilisateur, avec n'importe quelle durée. Changer les mots de passe des utilisateurs ne sert à rien : seule la rotation de la clé invalide les faux jetons. Les erreurs classiques sur les jetons sont détaillées dans notre guide sur l'expiration des JWT.

Comment le tester

Ces vérifications se font en une demi-journée, sans outil exotique :

1. Inventoriez vos clés de signature : secret HMAC, clé RSA ou EC du serveur d'authentification, clés de signature de webhooks, clés de service (Supabase service_role, comptes de service cloud). Pour chacune, notez où elle est stockée et qui y a accès.
2. Cherchez les copies : dépôts Git (historique compris), fichiers .env partagés, tickets, wikis, postes de travail. Un outil comme gitleaks ou trufflehog repère les clés dans l'historique ; voir notre article sur les secrets dans Git.
3. Vérifiez la date de dernière rotation de chaque clé et comparez-la aux départs récents de l'équipe. Toute clé antérieure au départ d'une personne qui y avait accès est à renouveler.
4. Testez la révocation : signez un jeton avec l'ancienne clé après rotation et vérifiez que l'API le refuse (401). Vérifiez aussi que le serveur rejette alg: none et les jetons sans exp.
5. Testez la détection : générez un jeton légitime, utilisez-le depuis une IP inhabituelle et à un volume anormal, puis regardez si une alerte remonte. Si personne ne le voit, vous ne tiendrez pas un délai de notification de 72 h.

Comment corriger

• Stockez les clés de signature dans un KMS ou un HSM : la signature se fait par appel d'API, la clé privée ne quitte jamais le service.
• Faites tourner les clés régulièrement et publiez-les via un JWKS avec un identifiant kid, pour pouvoir en retirer une sans casser le service.
• Ajoutez la rotation des secrets à la procédure de départ, au même titre que la désactivation du compte.
• Liez les jetons à une session côté serveur pour les opérations sensibles (export, changement d'e-mail, lecture massive), afin qu'un jeton forgé sans session correspondante soit refusé.
• Journalisez et alertez sur les émissions de jetons et les accès massifs à des comptes différents depuis une même source.

Ce que ça change quand un agent IA a ces accès

Un agent IA branché sur votre back-office détient souvent un jeton de service à larges droits, longue durée, stocké dans une variable d'environnement. C'est exactement le profil de la clé Coupang. Si l'agent lit un e-mail ou un document piégé, une injection de prompt peut l'amener à appeler ses outils pour lire ou exporter des comptes en masse, avec un jeton parfaitement valide : rien ne distingue alors l'abus d'un usage normal. Limitez le périmètre de ce jeton, donnez-lui une durée courte et mettez une validation humaine sur les actions d'export. Les principes sont les mêmes que pour les failles d'authentification les plus fréquentes.

La leçon pour les équipes européennes

Le RGPD plafonne les amendes à 4 % du chiffre d'affaires mondial, et la CNIL sanctionne déjà les défauts de sécurité élémentaires. Le cas Coupang montre qu'une fuite massive peut venir d'un oubli de procédure. La question utile est simple : si un ancien membre de l'équipe gardait une copie d'une clé, combien de temps mettriez-vous à le voir ?

Pour vérifier concrètement ce qu'un attaquant ou un agent détourné pourrait faire avec les accès de votre produit, le Red Team Agent Express teste ces scénarios en cinq jours et livre les preuves.