Correction incomplète : quand le serveur acceptait un cookie vide

Un cookie de session présent côté web. Une API entièrement accessible sans lui. Et une correction déployée qui n'est allée qu'à mi-chemin. Ce que ce cas illustre dépasse la vulnérabilité technique : c'est une leçon sur la façon dont les corrections peuvent échouer à régler ce qu'elles prétendent régler.

Contexte

Une PME du retail fait développer une application interne (web et mobile) pour permettre à ses employés de consulter les stocks disponibles en boutique. L'application est en lecture seule : pas d'écriture, pas de transaction. Mais la donnée a de la valeur : niveaux de stock par référence, disponibilités par boutique. Le client a une exigence claire : ces informations ne doivent être accessibles qu'aux employés connectés.

La découverte côté web

Je commence par analyser le trafic entre le navigateur et l'API. L'application configure un cookie de session après le login, jusque-là rien d'anormal. Ce qui l'est davantage : en supprimant ce cookie des requêtes suivantes et en les rejouant manuellement, l'API répond normalement. Toutes les données de stock sont accessibles, sans cookie, sans session.

Le serveur acceptait les requêtes sans vérifier si l'appelant était authentifié.

Le problème n'était pas dans l'interface : c'est l'API sous-jacente qui ne vérifiait pas la session. L'application web créait l'illusion d'une protection parce que le frontend exigeait un login, mais côté serveur, aucun contrôle n'était effectué sur les endpoints de l'API.

Pourquoi c'est critique même pour une app « interne »

L'application est accessible uniquement sur le réseau de l'entreprise. Mais ça ne change pas le fondamental : n'importe quel employé, prestataire ou visiteur passant par le WiFi peut accéder à l'ensemble des données sans s'identifier. Si un attaquant a accès au réseau (compromission d'un poste, connexion physique, Wi-Fi insuffisamment segmenté), il a accès aux données.

La correction… et le test de l'app mobile

Une semaine plus tard, la correction est déployée. Je teste l'application mobile, qui utilise la même API. Cette fois, le cookie est bien attendu par le serveur : une requête sans cookie est rejetée. Progrès.

Mais en testant avec un cookie présent mais vide (valeur : chaîne vide), le serveur accepte la requête. Les données de stock sont toujours accessibles.

La correction avait ajouté une vérification de présence du cookie. Elle n'avait pas ajouté de vérification de sa validité.

Un cookie vide n'est pas une session. Vérifier qu'un token existe n'est pas vérifier qu'il est valide.

Ce que ça illustre

Tester la remédiation fait partie du pentest. Une correction partielle peut créer une fausse sécurité : l'équipe pense que le problème est résolu, le cookie est « présent », les tests basiques passent. Mais un attaquant qui connaît cette classe de vulnérabilité va précisément tester les cas limites : cookie absent, cookie vide, cookie malformé, token expiré.

La bonne pratique pour les développeurs : la vérification d'authentification doit être un middleware appliqué systématiquement à tous les endpoints concernés, pas un contrôle ajouté au cas par cas. Une fonction centrale, testée unitairement, qui valide la session de façon complète : existence, format, signature, expiration.

Ce cas ne vient pas d'une équipe négligente. Il vient d'une correction faite dans l'urgence, sans spécification précise du comportement attendu, et sans retour d'un œil extérieur pour valider que le résultat correspondait bien à l'intention.