Une API exposée sur internet est une porte d’entrée directe vers vos données. La sécuriser correctement n’est pas une option facultative, surtout lorsqu’elle alimente à la fois une application mobile, un site web, et potentiellement des partenaires externes. Voici les points essentiels à vérifier systématiquement sur une API construite avec Symfony, avant toute mise en production.

Authentification et gestion des jetons JWT

L’authentification par JWT (JSON Web Token) est une pratique très courante avec Symfony, notamment via le bundle LexikJWTAuthenticationBundle. Quelques règles essentielles à respecter :

  • Utiliser une passphrase de signature suffisamment robuste, générée aléatoirement et jamais réutilisée d’un projet à l’autre.
  • Prévoir un mécanisme de refresh token pour éviter des sessions actives trop longues, tout en évitant de demander une reconnexion trop fréquente à l’utilisateur.
  • Invalider correctement les jetons existants lors d’une déconnexion explicite ou d’un changement de mot de passe, pour éviter qu’un jeton compromis reste valide indéfiniment.

Limiter le nombre de requêtes sur les routes sensibles

Les routes sensibles, en particulier la route de connexion (typiquement /api/auth/login), doivent impérativement être protégées par une limitation du nombre de tentatives, communément appelée rate limiting. Symfony propose un composant RateLimiter natif depuis plusieurs versions, qui permet de bloquer temporairement une adresse IP ou un compte après un nombre défini de tentatives échouées.

Cette protection réduit fortement le risque d’attaque par force brute visant à deviner les mots de passe des utilisateurs par essais successifs automatisés.

Valider rigoureusement toutes les données entrantes

Chaque donnée reçue par l’API doit être validée avant tout traitement, via les DTO (Data Transfer Objects) combinés au composant Validator de Symfony. La règle à retenir est simple : ne jamais faire confiance aux données envoyées par le client, même lorsqu’elles proviennent de votre propre application mobile officielle. Un client peut toujours être modifié, intercepté, ou simulé par un outil tiers.

Vérifier la cohérence des actions métier, pas seulement les accès

La sécurité d’une API ne se limite pas à vérifier qui a le droit d’accéder à quoi. Il faut également vérifier que les actions métier elles-mêmes restent cohérentes dans tous les cas. Par exemple, sur une marketplace : une annonce déjà vendue ou réservée ne doit jamais pouvoir être achetée une seconde fois, même si deux requêtes arrivent presque simultanément. De même, un utilisateur ne doit jamais pouvoir modifier ou supprimer une ressource qui ne lui appartient pas, même s’il en connaît l’identifiant technique.

Nettoyer systématiquement les accès de développement avant la mise en ligne

Avant toute mise en production, il est essentiel de retirer tout endpoint temporaire utilisé pendant la phase de développement, en particulier les routes de vidage de cache protégées par un secret écrit en dur dans le code, ou toute route de débogage laissée accessible par oubli.

Il convient également de vérifier qu’aucune clé d’API, identifiant ou secret ne se trouve dupliqué dans plusieurs fichiers d’environnement (.env, .env.local, .env.prod), ce qui pourrait créer une incohérence ou une fuite involontaire.

Revoir attentivement la configuration de sécurité

Le fichier security.yaml doit être relu en détail avant toute mise en ligne : les firewalls doivent être correctement définis pour chaque zone de l’application, la hiérarchie des rôles doit rester cohérente et prévisible, et les accès anonymes doivent être strictement limités aux routes qui en ont réellement besoin (typiquement la connexion et l’inscription).

Faire un audit complet avant toute publication

Un audit de sécurité mené avant le lancement permet de reprendre méthodiquement chacun de ces points avec un regard extérieur et objectif : robustesse de la passphrase JWT, présence effective du rate limiting, cohérence systématique des actions métier, configuration complète du security.yaml, et revue de tous les DTO de validation. C’est une étape qui demande du temps, mais qui évite des incidents de sécurité bien plus coûteux à corriger une fois l’application en production avec de vraies données utilisateurs.

En résumé

  • Authentification JWT robuste, avec mécanisme de refresh token et passphrase de signature forte.
  • Limitation du nombre de requêtes sur les routes sensibles, en particulier la connexion.
  • Validation stricte de toutes les données entrantes via DTO et composant Validator.
  • Aucun endpoint de débogage ni secret en dur ne doit subsister en production.
  • Un audit de sécurité complet est indispensable avant toute mise en ligne.

Vous développez une API qui doit être solide et sécurisée ? Découvrez ma méthode de travail sur les projets techniques ou contactez-moi pour en discuter.