ÉTUDE DE CAS · SÉCURITÉ
Postgres, API REST, permissions
Fermée deux fois
Base de données en production · Une colonne secrète, lisible de dehors
Résultat : colonne refermée au niveau de la table, puis redonnée colonne par colonne
01 / LE PROBLÈME
Une colonne secrète, lisible par n'importe qui à travers l'API REST.
La base expose une API REST. Une protection anti-robot était placée devant. Le rôle anonyme pouvait lire la colonne malgré elle, et le rôle authentifié aussi.
02 / LA CONTRAINTE
Une protection placée devant une API ne protège pas la base derrière.
Le filtre anti-robot faisait son travail, mais au mauvais étage. La permission réelle se joue dans Postgres, et Postgres répondait oui. La première correction a échoué en silence : un GRANT au niveau de la table annule un REVOKE posé sur une colonne. La commande passe, elle ne change rien.
03 / CE QUE J'AI CHOISI
Retirer l'accès à la table entière, puis le redonner colonne par colonne.
C'est plus long à écrire et plus long à relire, mais c'est la seule forme où la permission dit vraiment ce qu'elle a l'air de dire. Tout ce qui n'est pas nommé explicitement reste fermé.
04 / CE QUE ÇA FAIT AUJOURD'HUI
La même requête, sous chaque rôle, avant et après.
- Rôle anonymelisait la colonneaccès refusé
- Rôle authentifiélisait la colonneaccès refusé
- Protection anti-robotcontournée par l'APItoujours là, mais plus seule
05 / CE QUE JE CHANGERAIS
Je ne laisserais plus un correcteur automatique toucher aux permissions.
La faille a été fermée deux fois. Entre les deux, un scanner automatisé l'a « corrigée » dans le mauvais sens et l'a rouverte. Une permission n'est pas un problème de style qu'on corrige à la volée. Ce que j'ajouterais : un test qui rejoue la requête sous chaque rôle et échoue si elle répond, pour que la prochaine régression se voie au lieu de se croire.
Un problème du même genre chez vous ? Décrivez-le.