Autorisation et permissions – Principes fondamentaux des meilleures pratiques

L'authentification, c'est savoir « qui vous êtes ». Autorisation, c'est savoir "ce que vous pouvez faire".

De nombreux développeurs confondent les deux. Vous êtes connecté au système (Authentification ok), mais pouvez-vous supprimer la base de données ? Ou voir le salaire du PDG ? C'est l'autorisation.

La gestion des autorisations est la partie la plus critique de la sécurité d'une application. Une faille ici (Broken Access Control) est la vulnérabilité numéro 1 dans le classement OWASP.

Dans cet article, nous aborderons les bases et les meilleures pratiques pour mettre en œuvre un système d'autorisations robuste.

Modèles de contrôle d'accès

Il existe plusieurs façons de dire « oui » ou « non » à un utilisateur.

1. RBAC (Contrôle d'accès basé sur les rôles)

Le plus courant. Vous créez des « Rôles ».

Administrateur : vous pouvez tout faire.
Éditeur : peut créer et modifier des publications.
Lecteur : Vous pouvez simplement lire. Vous attribuez le rôle à l'utilisateur (user.role = 'editor'). Le code vérifie : if (user.role == 'admin').
Avantages : Simple à comprendre et à mettre en œuvre.
Inconvénients : Il est rigide. Que se passe-t-il si je souhaite qu'un éditeur spécifique puisse supprimer des publications, mais uniquement les siennes ?

2. ABAC (Contrôle d'accès basé sur les attributs)

Plus granulaire et puissant. Il est basé sur des attributs.

"Autoriser la modification IF (user.id == post.author_id) AND (heure < 18h00)".
Avantages : Flexibilité infinie.
Inconvénients : complexité de mise en œuvre.

3. PBAC (Contrôle d'accès basé sur des politiques)

Définit les politiques en langage naturel ou en code séparé.

Exemple : stratégies AWS IAM.

Principe du moindre privilège

C'est la règle d'or : Donnez à l'utilisateur uniquement l'autorisation minimale nécessaire pour qu'il puisse faire son travail. Ni plus, ni moins.

Si un service a uniquement besoin de lire des données, ne lui accordez pas d'autorisation d'écriture.
Si un développeur a uniquement besoin de voir les journaux, ne donnez pas accès à la base de données de production.

Cela réduit la « surface d'attaque ». Si le compte de cet utilisateur est piraté, les dégâts sont limités.

Où vérifier l'autorisation ?

TOUJOURS DANS LE BACKEND. De nombreuses applications modernes masquent le bouton « Supprimer » sur le frontend si l'utilisateur n'est pas un administrateur. Il s'agit simplement d'UX, pas de sécurité. Un attaquant peut appeler directement l'API DELETE /users/1. Le backend doit vérifier l'autorisation sur chaque demande.

IDOR (références d'objet directes non sécurisées)

Un échec classique. L'URL est site.com/fatura/100. Je vois ma facture. Je change l'URL en site.com/fatura/101. Je vois la facture du voisin. C'est IDOR. Correction : Le backend doit vérifier : "L'utilisateur connecté est-il le PROPRIÉTAIRE de la facture 101 ?". Sinon, renvoyez 403 Forbidden.

Conclusion

L'autorisation n'est pas quelque chose qui s'ajoute à la fin. Il doit être conçu dans l'architecture de la base de données et de l'API. Utilisez des bibliothèques matures (comme CASL dans JS ou Pundit) au lieu d'encombrer votre code avec des if/else dispersées. La sécurité est le contrôle.