Sécurité API : authentification et autorisation sont différentes

Définir la frontière de confiance d’une API

Une API reçoit des données provenant de clients qu’elle ne contrôle pas entièrement. Même si l’interface officielle n’affiche pas un bouton, une personne peut envoyer une requête différente, modifier un identifiant ou ajouter un champ. Le serveur doit donc considérer les entrées comme non fiables et appliquer ses propres règles. Cette logique concerne les applications internes aussi bien que les services publics. Commencez par inventorier les ressources, les opérations et les profils d’utilisateurs. Une politique de sécurité compréhensible décrit qui peut faire quoi sur quelles données, puis précise comment cette décision est vérifiée.

Authentifier ne signifie pas donner tous les droits

L’authentification établit une identité à l’aide d’une session, d’un jeton ou d’un fournisseur d’identité. Vérifiez la validité, l’expiration et les propriétés attendues selon le mécanisme utilisé. Ne faites pas confiance à une simple valeur décodée sans validation appropriée. Une identité reconnue ne possède pas automatiquement les droits sur toutes les ressources. La gestion des sessions doit prévoir déconnexion, expiration et révocation selon le besoin. Utilisez HTTPS et protégez les secrets. Les jetons ne doivent pas apparaître dans les URL ou les journaux où ils pourraient être conservés et diffusés involontairement.

Autoriser au niveau de l’objet et de l’opération

Un utilisateur peut avoir le droit de consulter ses factures sans lire celles d’un autre compte. Chaque accès par identifiant doit être contrôlé. Le cas classique consiste à remplacer un numéro dans l’URL et à obtenir une autre fiche parce que le serveur vérifie seulement la connexion. L’autorisation doit également distinguer les actions : lire, modifier, exporter ou supprimer peuvent exiger des droits différents. Les permissions générales sont utiles, mais ne suffisent pas toujours à représenter la propriété ou le contexte. La décision doit être appliquée au moment de l’opération, pas uniquement lors de l’ouverture de l’écran.

Isoler correctement les organisations d’un SaaS

Dans une application multi-organisation, chaque requête doit rester dans le périmètre autorisé. L’identifiant d’organisation transmis par le navigateur n’est pas une preuve d’appartenance : il doit être confronté à l’utilisateur authentifié et aux règles du système. Cette isolation concerne aussi recherches, exports, fichiers, caches et traitements en arrière-plan. Un contrôle correct sur la route principale ne suffit pas si une exportation oublie le filtre. Testez explicitement deux organisations possédant des données proches. Les mécanismes de base de données peuvent renforcer l’isolation, mais leur configuration et leurs limites doivent être comprises.

Valider les champs et limiter les modifications

Définissez les propriétés acceptées et les contraintes de type, format, longueur et volume. Une API de modification de profil ne doit pas accepter silencieusement un champ donnant un rôle administrateur. Évitez d’appliquer directement un objet reçu à une entité persistée sans sélectionner les propriétés autorisées. La validation syntaxique ne remplace pas les règles métier : une quantité positive peut dépasser le stock ou la limite autorisée. Vérifiez également les formats de fichiers et les chemins de stockage. Les identifiants et noms fournis par le client ne doivent pas permettre de sortir du périmètre prévu.

Protéger les ressources contre les abus

Une requête légitime peut être coûteuse si elle demande une liste immense, un export complet ou une génération IA répétée. Limitez les tailles, les fréquences et les budgets en fonction des opérations. Une limite unique pour toute l’application peut être trop stricte pour la lecture et trop large pour une action sensible. Les mécanismes doivent tenir compte des comptes, des organisations et du contexte sans créer une méthode facile pour bloquer d’autres utilisateurs. Surveillez les erreurs et les volumes anormaux. Les limites protègent disponibilité et coûts, mais ne remplacent ni l’authentification ni les autorisations.

Sécuriser les échanges avec d’autres services

Les intégrations utilisent souvent des clés ou des comptes techniques. Accordez des permissions minimales et stockez les secrets dans des mécanismes adaptés. Vérifiez les destinations des appels sortants pour éviter qu’un paramètre utilisateur force le serveur à contacter une ressource interne inattendue. Les webhooks doivent être authentifiés ou vérifiés selon le contrat du fournisseur, et les messages répétés doivent être traités sans doubler les actions. Une réponse distante reste une donnée à valider. Le fait qu’un service soit partenaire ne dispense pas de contrôler les formats, les tailles et les erreurs qu’il peut renvoyer.

Exemple : tester l’accès à une fiche client

Créez deux comptes dans deux organisations, puis une fiche dans chacune. Avec le premier compte, vérifiez lecture, modification, suppression et export de sa propre fiche. Répétez avec l’identifiant de la seconde : toutes les opérations interdites doivent être refusées sans fuite de données. Testez ensuite les listes, les recherches et les fichiers associés. Ajoutez un utilisateur disposant de droits réduits dans la même organisation pour vérifier les distinctions d’opération. Ce scénario révèle souvent plus de faiblesses réelles qu’un test qui confirme seulement qu’un jeton valide permet d’appeler une route.

Journaliser et répondre aux incidents sans exposer davantage

Conservez les événements utiles : opération sensible, identité, résultat et identifiant de corrélation. Évitez les secrets, mots de passe et contenus complets qui ne sont pas nécessaires à l’enquête. Limitez l’accès aux journaux et définissez leur durée de conservation. Préparez la rotation des clés et la révocation des sessions compromises. Les erreurs retournées aux clients doivent être maîtrisées pour ne pas divulguer de traces, de requêtes ou de configuration. Une procédure de réponse doit indiquer comment contenir le problème et vérifier l’étendue de l’accès, sans dépendre d’une seule personne.

Intégrer la sécurité au développement quotidien

Formalisez les règles de permission avec les personnes métier et ajoutez des tests négatifs aux parcours critiques. Réévaluez les droits lorsqu’une nouvelle fonctionnalité ou intégration arrive. Les bibliothèques de sécurité aident, mais ne connaissent pas automatiquement les frontières de votre activité. Tuplify Studio peut mettre en place authentification, rôles, isolation des organisations et validation dans vos CRM et API. La sécurité doit être vérifiable dans les comportements réels. Une interface qui semble verrouillée ou une liste de dépendances réputées ne remplace pas des contrôles appliqués systématiquement aux ressources et opérations protégées.

Atelier : construire une matrice d’autorisation vérifiable

Listez les ressources sensibles et les opérations possibles, puis associez chaque profil aux autorisations attendues. Ajoutez le contexte : propriétaire, organisation, état du dossier et conditions particulières. Transformez les combinaisons importantes en tests, y compris les refus. Pour une facture, vérifiez lecture, téléchargement, modification et export : une seule route protégée ne couvre pas toutes les voies d’accès. Testez aussi les traitements asynchrones qui réutilisent des identifiants. Cette matrice permet aux personnes métier et techniques de partager une définition claire des droits. Elle sert de référence lors d’une nouvelle fonctionnalité et évite que les permissions soient décidées uniquement par les boutons présents dans une maquette.

Questions fréquentes : jetons et confiance

Un JWT est-il automatiquement sûr ? Sa sécurité dépend de sa validation, de sa gestion et de l’usage des informations qu’il contient. Décoder une chaîne ne suffit pas à lui faire confiance.

CORS protège-t-il l’API contre tous les clients ? Il encadre certains accès effectués par les navigateurs. Il ne remplace ni authentification ni autorisation pour les clients capables d’envoyer directement des requêtes.

Une API interne peut-elle se passer de contrôles ? Les erreurs, comptes compromis et déplacements de données existent aussi à l’intérieur d’une organisation. Adaptez les protections au risque et appliquez des droits minimaux. L’emplacement réseau ne prouve pas à lui seul qu’une requête est légitime pour chaque ressource.