Les contrôles de sécurité d’API que nous appliquons à chaque projet

La plupart des brèches d’API que l’on nous demande d’examiner ne sont pas ingénieuses. C’est un point d’entrée qui a oublié de vérifier qui demandait, un jeton qui n’expire jamais, ou une route de débogage qui a survécu jusqu’en production. La liste ci-dessous est ennuyeuse à dessein.

Autorisez à chaque requête, objet par objet

L’authentification répond à la question de savoir qui vous êtes ; l’autorisation, à celle de savoir ce que cet enregistrement précis a à voir avec vous. Le défaut le plus courant en conditions réelles est un point d’entrée qui vérifie le jeton puis fait confiance à un identifiant fourni dans le corps de la requête. Si un utilisateur peut changer un numéro dans une URL et voir les données d’un autre, rien d’autre sur cette liste n’a d’importance.

Validez les entrées à la frontière, avec un schéma

Chaque charge utile est analysée vers une forme typée dès l’entrée, et tout ce qui est inattendu est rejeté là, plutôt que combattu à dix endroits en aval. C’est aussi ce qui bloque l’affectation en masse : le client ne peut pas définir un champ au seul motif que le modèle en possède un.

Limitez le débit sur ce qui coûte de l’argent ou divulgue de l’information

—L’authentification et la réinitialisation de mot de passe, où atterrit le bourrage d’identifiants.

—Les points de recherche et d’export, par lesquels une fuite lente devient rapide.

—Tout ce qui appelle un tiers payant en votre nom, y compris les API de modèles.

Traitez les secrets comme rotatifs dès le premier jour

Les clés vivent dans l’environnement, jamais dans le dépôt, et chacune dispose d’un moyen connu d’être renouvelée sans un déploiement qui interrompt le service. Nous vérifions que ce chemin de rotation existe pendant que le projet est calme, pas pendant un incident.

Journalisez assez pour reconstituer, pas assez pour divulguer

Toute opération qui modifie des données doit être attribuable à un acteur et à un instant. De même, aucune ligne de journal ne doit contenir un jeton, un numéro de carte ou le corps complet d’une requête authentifiée. Les deux moitiés de cette phrase sont contrôlées.

Analysez les dépendances en CI et lisez réellement le résultat

Un flux d’alertes que personne ne lit est pire que rien, car il donne l’illusion d’une couverture. Nous conditionnons les merges à son résultat, et nous trions ce qu’il signale au lieu de l’acquitter jusqu’au silence.