En mai 2026, le portail moncompte.ants.gouv.fr a subi une faille IDOR (Insecure Direct Object Reference) ayant exposé les données de 11,7 millions de Français. L’exploitation, qualifiée de « vraiment stupide » par son auteur, consistait simplement à modifier un identifiant numérique dans une URL pour accéder aux comptes d’autres utilisateurs, faute de vérification d’autorisation entre l’authentification et la récupération des données.
L’article explique que cette vulnérabilité, courante mais critique, survient lorsque les applications ne contrôlent pas si un utilisateur a le droit d’accéder à une ressource spécifique, même après s’être authentifié. L’exemple donné illustre un endpoint /api/account/{id} où seule la session est validée, sans vérification que l’identifiant {id} correspond bien au compte de l’utilisateur connecté.
Pour éviter ce type de faille, l’auteur propose des solutions techniques avec Symfony et PHP, comme l’utilisation de Voters pour gérer les autorisations, l’absence d’IDs exposés dans les URLs, ou des tests automatisés pour détecter les accès non autorisés. Le problème ne dépend pas du framework utilisé, mais de l’absence d’une couche d’autorisation explicite.
L'article explique comment standardiser la déclaration des droits avec une interface, implémenter cette interface sur les entités concernées, et créer un voter unique pour gérer les autorisations. Une solution efficace pour éviter la répétition de code et centraliser la logique d'accès, particulièrement utile dans les projets SaaS. L'article aborde également les améliorations possibles et les limitations de cette approche.
L'article traite des meilleures pratiques en matière d'authentification et d'autorisation, en particulier dans le contexte des API. Voici un résumé des points clés :
-
Authentification :
- HTTP Basic Authentication : Méthode simple mais peu sécurisée, utilisable uniquement dans des environnements très contrôlés ou pour des tests locaux.
- Clés API : Doivent être traitées comme des mots de passe, transmises via HTTPS et régulièrement renouvelées.
- JSON Web Token (JWT) : Plus sécurisé que les méthodes précédentes, mais nécessite une étape de connexion initiale. Idéal pour les applications web nécessitant une authentification utilisateur.
- OpenID Connect (OIDC) : Ajoute une couche d'authentification à OAuth 2.0, permettant une intégration sécurisée des identités sur Internet.
- Authentification Multi-Facteurs (MFA) : Renforce la sécurité en exigeant plusieurs facteurs d'authentification.
-
Autorisation :
- OAuth 2.0 : Mécanisme d'autorisation basé sur des jetons, permettant aux utilisateurs de donner accès à leurs données à des applications tierces sans partager leurs identifiants.
- Contrôle d'Accès Basé sur les Rôles (RBAC) : Assigne des permissions basées sur les rôles des utilisateurs.
- Contrôle d'Accès Basé sur les Attributs (ABAC) : Permet un contrôle plus fin en se basant sur les attributs des utilisateurs, des ressources et de l'environnement.
- Contrôle d'Accès Basé sur les Politiques (PBAC) : Combine les rôles et les politiques pour déterminer les privilèges d'accès.
-
Meilleures Pratiques :
- Utiliser HTTPS pour chiffrer les communications.
- Stocker les identifiants sensibles de manière sécurisée.
- Appliquer le principe du moindre privilège.
- Valider toutes les entrées utilisateur pour prévenir les attaques par injection.
- Limiter le nombre de requêtes pour éviter les abus.
- Surveiller et journaliser les activités pour détecter les comportements suspects.
-
Erreurs Courantes à Éviter :
- Utiliser HTTP au lieu de HTTPS.
- Stocker les clés API dans le code.
- Ne pas valider les entrées utilisateur.
- Ignorer les bonnes pratiques de sécurité.
L'article souligne l'importance de rester à jour sur les menaces de sécurité et de suivre les meilleures pratiques pour garantir la sécurité des API.
Il s'agit d'un protocole concernant l'authentification et les autorisations d'utilisateurs sur un réseau.
Tout est dans le titre
Tout est dans le titre
Astucieux, l'auteur montre comment décomposer les différentes "autorisations" (non banni, ayant une souscription valide, etc.) que doit remplir un utilisateur d'une application Symfony