Une liste de contrôle de revue de code axée sécurité pour les changements aux frontières de confiance

Objectif

Repérer les défauts de sécurité qu'une relecture générale laisse passer parce qu'il s'agit de code correct faisant la mauvaise chose : un contrôle d'autorisation manquant, une sortie non échappée, une URL récupérée depuis une saisie utilisateur.

Prérequis

Une description du changement qui nomme les frontières de confiance touchées, une relecture générale déjà effectuée pour la conception et la correction, et les articles du wiki liés pour le détail de chaque contrôle. L'OWASP Code Review Guide (cité) est la référence détaillée pour la même activité.

Étapes

1. Décider si la liste de contrôle s'applique : le changement lit-il une saisie venant de l'extérieur du processus, change-t-il qui peut faire quoi, touche-t-il une base de données ou un système de fichiers, effectue-t-il des requêtes sortantes, gère-t-il des identifiants ou des clés, ou ajoute-t-il une dépendance ? Si aucun de ces cas, s'arrêter.
2. Saisie : pour chaque nouveau point d'entrée, trouver où la donnée est validée (type, longueur, liste blanche) et où elle est utilisée ; tout usage qui construit une requête, une commande, un chemin, une URL ou un balisage doit passer par la paramétrisation ou l'encodage, non par la concaténation de chaînes.
3. Authentification et sessions : tout nouveau point d'accès se trouve derrière la même authentification que ses homologues ; le code de connexion, de réinitialisation, de MFA et de jeton régénère les identifiants et les expirations là où les articles existants le préconisent.
4. Autorisation : pour chaque objet accédé par un identifiant issu de la requête, repérer le contrôle vérifiant que le principal courant peut accéder à cet objet, et non seulement au point d'accès. Rechercher le contrôle manquant sur la seconde voie (traitement en masse, export, administration, webhook).
5. Accès aux données et stockage : requêtes paramétrées ; nouvelles colonnes contenant des données personnelles classées et couvertes par une politique de conservation ; fichiers écrits sous un nom aléatoire dans un emplacement non exécutable.
6. Sortant : toute URL construite à partir d'une saisie passe par la liste blanche anti-SSRF ; les redirections ne ciblent que des chemins relatifs ou des hôtes listés ; XML, YAML et la sérialisation native sont analysés avec le chargeur sûr.
7. Secrets et configuration : aucun identifiant en clair, aucun secret dans les journaux ou les messages d'erreur, une nouvelle configuration échoue de façon fermée en cas d'absence.
8. Dépendances : un nouveau paquet a une raison d'être, une version figée et un amont maintenu ; une modification du fichier de verrouillage est examinée pour repérer des paquets inattendus.
9. Journalisation et erreurs : les actions pertinentes pour la sécurité produisent un événement d'audit ; les réponses d'erreur n'exposent ni traces de pile ni hôtes internes.
10. Rédiger les constats sous forme de questions avec un renvoi vers l'article pertinent ; ne bloquer la fusion que sur les éléments des étapes 2, 4 et 6, ceux qu'un attaquant atteint en premier.

Résultat attendu

Les changements touchant une frontière reçoivent un second regard cohérent ; les relecteurs concentrent l'attention sécurité là où elle rapporte et la passent ailleurs.

Limites et base de vérification

Une proposition, non une pratique mesurée. La liste trouve des omissions, non des failles logiques dans les règles métier, qui nécessitent une modélisation des menaces. L'appliquer à chaque changement la dilue ; ne l'appliquer que lorsque l'auteur signale une frontière dépend de ce que l'auteur le remarque.