Backend, API et données · Mixte

Authentification et autorisation : qui vous êtes et ce qui vous est permis

En une ligne : L'identité et l'autorisation sont deux questions distinctes, et la plupart des failles viennent de ce que la seconde est vérifiée dans l'interface et non dans le serveur.

Séparation

L'authentification répond à qui est l'utilisateur. L'autorisation répond s'il est autorisé à effectuer l'action sur la ressource. Cacher un bouton dans l'interface n'est pas une autorisation — toute requête peut être envoyée directement.

La règle : chaque route vérifie l'autorisation sur la ressource concrète, pas seulement que l'utilisateur est connecté.

Modèles pratiques

Par rôles — simple, suffisant pour la plupart des systèmes. Par propriété et appartenance — nécessaire quand les utilisateurs ne voient que les données de leur organisation. Par politique détaillée — puissant et coûteux à maintenir, et seulement quand c'est vraiment nécessaire.

Commencez simplement et documentez les règles dans un seul endroit du code, pas éparpillées en vingt vérifications.

Jetons

Une courte expiration pour un jeton d'accès, un jeton de rafraîchissement révocable et une liste de refus pour les événements de déconnexion. Conservez côté serveur de quoi révoquer l'accès immédiatement — une capacité nécessaire exactement le jour où il n'y a pas le temps de la construire.

Pour aller plus loin

Le danger le plus courant est l'accès direct à une ressource par identifiant : remplacer un numéro dans l'adresse qui retourne les données d'un autre. Vérifiez cela systématiquement sur chaque route qui reçoit un identifiant, et ajoutez un test automatique qui tente d'accéder entre utilisateurs.