Les guides de sécurité pour développeurs échouent souvent de deux façons. Soit un mur de jargon de conformité que personne ne lit, soit une liste de mots effrayants sans instructions. Voici la checklist que je lance vraiment avant de livrer, écrite comme je l’expliquerais à un collègue.
Authentification : arrêtez de réinventer la roue
Si vous hachez encore des mots de passe à la main en 2026, arrêtez. Utilisez une bibliothèque qui fait de l’argon2id ou du bcrypt avec des réglages sains. Les façons de se tromper subtilement sont nombreuses, et aucune n’apparaît aux tests, car un hash faible connecte quand même l’utilisateur.
Des sessions plutôt que des JWT pour la plupart des applications web. Une session côté serveur que vous pouvez révoquer vaut mieux qu’un jeton sans état que vous ne pouvez pas. Si vous utilisez des jetons, gardez-les à courte durée et prévoyez un vrai flux de rafraîchissement. Le confort du « je n’interroge jamais la base » devient un problème le jour où vous devez expulser quelqu’un immédiatement.
L’autorisation, c’est là que vivent les vrais bugs
L’authentification demande qui vous êtes. L’autorisation demande ce à quoi vous avez le droit de toucher, et c’est là que surviennent la plupart des fuites graves. Le grand classique : un endpoint lit l’identifiant utilisateur depuis le corps de la requête au lieu de la session, donc je modifie mon profil en envoyant votre identifiant. Ça s’appelle IDOR et c’est partout.
Le correctif est une habitude, pas un outil. Chaque fois que vous chargez un enregistrement, demandez : « l’utilisateur courant en est-il propriétaire, et l’ai-je vérifié ? » Écrivez ce contrôle au niveau des données pour qu’il ne s’oublie pas dans un contrôleur. Le même soin vaut pour les fonctionnalités IA : un agent agissant au nom d’un utilisateur a besoin des permissions de cet utilisateur, pas du compte de service, un point que j’aborde dans l’IA agentique en cybersécurité.
Toute entrée est hostile jusqu’à preuve du contraire
L’injection SQL est ancienne et marche encore parce que quelqu’un, quelque part, construit toujours des requêtes par concaténation de chaînes. Utilisez des requêtes paramétrées. Toujours. Votre ORM le fait probablement pour vous, jusqu’au moment où vous passez en requête brute pour la performance et l’oubliez.
Pour tout ce qui finit dans du HTML, l’échappement par défaut du framework est votre ami. Le danger, c’est l’instant où vous appelez la fonction « rendre ce HTML brut ». Chaque bug XSS que j’ai corrigé vivait à quelques lignes d’un de ces appels.
Les secrets n’ont rien à faire dans le dépôt
Clés API, mots de passe de base, secrets de signature : rien de tout ça ne va dans git, même un dépôt privé, même « temporairement ». Utilisez des variables d’environnement ou un gestionnaire de secrets. Ajoutez un scanner pre-commit pour qu’une version fatiguée de vous-même ne puisse pas en divulguer un à minuit.
Et faites-les tourner quand quelqu’un part ou quand une clé traîne depuis un an. Un secret dont vous ne vous souvenez pas de la création est un secret à retirer.
Les en-têtes que la plupart oublient
Une poignée d’en-têtes de réponse HTTP achète beaucoup de sécurité pour presque aucun effort. Une Content-Security-Policy stricte est la plus importante ; pénible à régler et payante. Ajoutez HSTS pour que les navigateurs refusent le HTTP en clair, et posez des drapeaux de cookies sensés (HttpOnly, Secure, SameSite). Une demi-heure de travail qui ferme des catégories entières d’attaques.
Les dépendances font partie de votre surface d’attaque
L’essentiel de votre code n’est pas le vôtre. Lancez un audit de vos dépendances, activez les PR de mise à jour automatiques, et lisez-les vraiment au lieu de les valider d’un tampon. Un paquet compromis dans votre pipeline de build peut faire tout ce que votre build peut faire, c’est-à-dire beaucoup. C’est une raison pour laquelle je garde les frontières build/exécution propres, un sujet que j’aborde dans l’architecture full-stack moderne.
Testez-la avant de la livrer
Pointez un scanner sur votre propre application avant qu’un attaquant le fasse. Même gratuit, il attrapera les trous évidents. Associez ça à l’habitude de tester les chemins malheureux : que se passe-t-il avec un mauvais type, une charge énorme, l’identifiant d’un autre, un jeton manquant. Les bugs se cachent dans les cas que vous n’aviez pas prévus.
Rien de tout cela n’est exotique. C’est les mêmes dix choses, faites à chaque fois, qui séparent les applications piratées de celles qui ne le sont pas. Pour aller plus loin dans la construction de systèmes sécurisés avec l’IA dans la boucle, les pratiques de l’ingénierie IA pratique sont la suite logique.
Laisser un commentaire