Retour au blog
Programmation 28 septembre 2026 2 min

5 réflexes de sécurité que j'applique systématiquement sur vos projets web

Les vérifications que je fais par défaut sur chaque projet, avant même qu'on me le demande : accès, mots de passe, formulaires, dépendances, erreurs.

5 réflexes de sécurité que j'applique systématiquement sur vos projets web

La sécurité d'un site web ne se résume pas à un cadenas dans la barre d'adresse. Voici cinq points que je traite systématiquement, sans attendre qu'un client me les demande, parce qu'ils évitent les incidents les plus courants.

1. Séparer ce qui est public de ce qui ne l'est pas

Chaque endpoint de l'API a une règle d'accès explicite : ouvert en lecture pour le contenu public, réservé à un compte administrateur pour tout le reste (création, modification, suppression, messagerie). Cette règle doit être écrite noir sur blanc, jamais déduite implicitement, sous peine d'oublier une route.

2. Ne jamais stocker un mot de passe en clair

Les mots de passe sont toujours hashés avec un algorithme conçu pour ça (argon2id ou équivalent), jamais chiffrés ni stockés tels quels. Même en cas de fuite de la base de données, les mots de passe restent inexploitables.

3. Valider et limiter les formulaires publics

Un formulaire de contact accessible à tous doit valider ce qu'il reçoit (un message vide, un e-mail invalide) et limiter le nombre d'envois par visiteur sur une période donnée. Sans cette limite, un formulaire de contact devient un outil de spam gratuit.

4. Garder les dépendances à jour

Un framework ou une bibliothèque publie régulièrement des correctifs de sécurité. Je vérifie l'état des dépendances avant chaque mise en production, pas seulement au lancement du projet : une faille corrigée dans une bibliothèque ne protège personne si le projet reste bloqué sur une ancienne version.

5. Ne jamais renvoyer le détail d'une erreur au visiteur

Quand quelque chose échoue côté serveur, le visiteur reçoit un message générique, jamais la trace technique de l'erreur (fichier, ligne, requête SQL). Ce détail part dans les journaux du serveur, où seule l'équipe technique peut le consulter.

Aucun de ces points n'est spectaculaire. C'est justement leur régularité, projet après projet, qui fait la différence.

Partager