Audit OWASP : les 5 failles que je retrouve sur 80% des sites

En 20 ans de prod, j'ai fait un paquet d'audits de sécurité. Sur des sites vitrines, des plateformes e-commerce, des back-offices internes. Et le constat est toujours le même : les failles se ressemblent. C'est presque rassurant — si vous corrigez ces cinq points, vous êtes déjà au-dessus de 80% du web francophone.

1. Les headers HTTP absents

C'est le premier truc que je vérifie. Et c'est presque toujours la même chose : aucun header de sécurité.

Pas de Content-Security-Policy, pas de X-Content-Type-Options, pas de Strict-Transport-Security. Le navigateur est livré à lui-même. N'importe quel script injecté tourne sans restriction.

La correction prend 10 minutes dans la config Nginx ou Apache. Mais personne ne la fait parce que « ça marche sans ».

2. Les formulaires sans rate-limiting

Formulaire de contact, formulaire de login, formulaire de réinitialisation de mot de passe. Aucune limite de fréquence. Vous pouvez envoyer 10 000 requêtes par minute sans que le serveur bronche — enfin si, il finit par tomber.

Le risque n'est pas qu'un bot brute-force votre admin (quoique). Le risque immédiat, c'est le spam massif via votre formulaire de contact : votre IP se retrouve blacklistée, vos mails légitimes partent en spam, et vous mettez trois semaines à comprendre pourquoi vos clients ne reçoivent plus vos factures.

Solution : un fail2ban basique sur les endpoints sensibles, un honeypot dans les formulaires, et un rate-limit au niveau du reverse proxy. Trois couches, zéro dépendance JavaScript côté client.

3. Les fichiers accessibles qui ne devraient pas l'être

Le classique. Je tape /wp-config.php.bak dans le navigateur et je récupère les identifiants de la base de données. Ou /.env. Ou /composer.json qui liste toutes les dépendances PHP avec leurs versions exactes — un catalogue de CVE potentielles.

J'ai déjà trouvé un dump.sql de 2 Go accessible à la racine d'un site e-commerce. Noms, emails, mots de passe hashés (en MD5, évidemment). Le fichier était là depuis 8 mois.

La règle : tout ce qui n'est pas un asset public (HTML, CSS, JS, images) doit être bloqué au niveau du serveur web. Point final.

4. Les dépendances obsolètes

jQuery 1.12 sur un site en 2025. Un WordPress 5.x qui n'a pas été mis à jour depuis 18 mois. Un plugin Contact Form avec une CVE critique publiée 6 mois plus tôt.

Ce n'est pas de la négligence — c'est de la peur. « Si on met à jour, ça va casser. » Et c'est parfois vrai. Mais la question n'est pas « est-ce que la mise à jour va casser quelque chose ? », c'est « est-ce qu'on préfère un bug d'affichage corrigé en 2h ou une base de données exfiltrée ? »

Mon approche : un staging qui reproduit la prod à l'identique, des mises à jour testées sur le staging, et un rollback automatique en cas de problème. Ça prend du temps à mettre en place, mais une fois que c'est fait, les mises à jour deviennent un non-événement.

5. Le HTTPS mal configuré

Le site est en HTTPS, oui. Mais le certificat est en auto-renouvellement avec un cron qui n'a jamais fonctionné. Ou le site accepte encore les connexions HTTP sans redirection. Ou TLS 1.0 est encore activé « pour compatibilité ».

Pire : les cookies de session sans flag Secure ni HttpOnly. Le cookie transite en clair sur un hotspot Wi-Fi et c'est game over.

Vérification rapide : curl -I https://votre-site.com et regardez les headers. Si vous ne voyez pas Strict-Transport-Security, il y a du travail.

Et après ?

Ces cinq points ne couvrent pas tout. Il y a les injections SQL, le CSRF, les problèmes d'authentification... Mais dans mon expérience, corriger ces cinq fondamentaux élimine 80% de la surface d'attaque réelle.

Le plus frustrant ? Aucun de ces problèmes n'est difficile à corriger. C'est juste que personne n'y pense tant que ça n'a pas explosé. Un audit sérieux, même basique, sauve des nuits de sommeil.