Un fichier .env accessible depuis un navigateur. Je suis tombé sur ça chez un client il y a deux ans, en ouvrant simplement monsite.fr/.env par curiosité. Le fichier contenait les identifiants de la base de données, une clé d'API de paiement et le mot de passe SMTP. Le site était en ligne depuis quatre ans. Personne n'avait jamais regardé.
C'est tout le problème de l'audit de sécurité web : ce qui n'est pas vérifié reste ouvert. Pas par malveillance. Par oubli. Alors voici comment j'audite réellement un site, dans l'ordre, avec les outils que j'utilise et les erreurs que j'ai faites.
Points clés à retenir
- Un audit de sécurité commence toujours par un inventaire des actifs, pas par un scan.
- Les en-têtes de sécurité (CSP, HSTS, X-Frame-Options) se vérifient en 30 secondes et révèlent souvent 3 à 4 failles exploitables.
- Les fichiers exposés (.git, .env, sauvegardes) sont la première cause de fuite que je rencontre.
- Un scan automatisé ne remplace jamais un test manuel sur les formulaires et les sessions.
- Priorisez par exploitation réelle, pas par score CVSS brut.
- Un audit sans re-test trois semaines plus tard ne vaut rien.
Un audit de sécurité de site web, c'est quoi au juste (et ce que ce n'est pas)
La question « qu'est-ce qu'un audit de site web ? » revient souvent, et la réponse est plus restrictive qu'on ne le croit. Un audit de sécurité, c'est une évaluation méthodique de la surface d'attaque d'un site : ce qui est exposé, ce qui peut être atteint sans authentification, ce qui casse si on force un peu. Concrètement, ça produit une liste de failles classées par gravité et par facilité d'exploitation.
Un audit de site web au sens large, celui qu'on vend dans les agences, mélange souvent trois choses distinctes : le SEO, la performance, et la sécurité. Ce n'est pas la même chose et ça ne demande pas les mêmes compétences. J'ai vu des rapports de 40 pages dont 35 parlaient de balises méta. Ce n'est pas un audit de sécurité.
Ce que ce n'est pas non plus : un pentest complet. Un pentest est une attaque simulée, menée par quelqu'un qui essaie vraiment de rentrer. L'audit est plus large et moins profond — il couvre l'hygiène, la configuration, la conformité. Les deux se complètent mais ne se substituent pas.
Pourquoi s'en préoccuper ? Parce qu'un site non audité depuis deux ans héberge statistiquement plusieurs dépendances obsolètes avec des vulnérabilités connues. Ce n'est pas une théorie : à chaque audit que j'ai mené sur un site laissé à l'abandon, j'ai trouvé au moins une bibliothèque JS en version obsolète avec une CVE publique.
Quels sont les 4 critères de sécurité à examiner en priorité ?
Quand on me demande par où commencer, je réponds toujours la même chose : ces quatre critères couvrent l'essentiel des failles réellement exploitées. Pas les plus spectaculaires. Les plus fréquentes.
1. Confidentialité — qui peut lire quoi ?
Ça englobe le chiffrement en transit (HTTPS, version de TLS), les fichiers accessibles publiquement qu'on croyait privés, les données de formulaires stockées sans précaution. Le test le plus rapide : vérifier que le certificat est valide, que TLS 1.0 et 1.1 sont désactivés, et qu'aucun dossier de sauvegarde ne traîne à la racine. Un curl -I sur l'URL suffit souvent à voir la version TLS.
2. Intégrité — peut-on modifier ce qui ne devrait pas l'être ?
Ici, on parle des formulaires sans validation côté serveur, des paramètres d'URL manipulables, des uploads non filtrés. Une requête POST modifiée à la main peut parfois changer un prix, un rôle utilisateur, un statut de commande. Je teste systématiquement en modifiant un champ caché dans le HTML.
3. Disponibilité — le site tient-il la charge et les abus ?
La disponibilité, c'est aussi la protection contre les attaques par déni de service, les formulaires sans limitation de fréquence, les endpoints coûteux en ressources accessibles sans authentification. Un formulaire de contact qui envoie 500 emails en cinq minutes, c'est un problème de disponibilité et de réputation.
4. Traçabilité — garde-t-on une trace de ce qui se passe ?
Les logs. Sans logs, aucune investigation n'est possible après incident. Concrètement : est-ce que les connexions sont enregistrées ? Les tentatives échouées ? Avec quel niveau de détail et pendant combien de temps ? Sur la plupart des sites que j'audite, les logs existent mais personne ne les lit jamais. Ça revient à ne pas en avoir.
Comment vérifier concrètement la sécurité d'un site web ?
La méthode que j'applique tient en sept étapes. Elle prend entre une demi-journée (site vitrine) et trois jours (application avec authentification). Voici l'ordre exact que je suis.
1. Inventaire des actifs et cartographie
Avant tout outil, je liste : les domaines et sous-domaines, les IP, les technologies (CMS, frameworks, versions), les services exposés, les formulaires, les points d'authentification. Un Nmap léger sur les ports ouverts révèle parfois des services oubliés — un phpMyAdmin en 8080, une interface d'admin sur un sous-domaine staging.
2. Scan automatisé (30 minutes, jamais plus)
Pour l'automatique, j'utilise OWASP ZAP pour l'analyse web et Nuclei pour les CVE connues. Je passe toujours par Security Headers (securityheaders.com) et SSL Labs pour les en-têtes et la configuration TLS. Le scan automatique sert à dégrossir, pas à conclure. J'ai déjà reçu des rapports ZAP bourrés de faux positifs sur des pages de blog statiques.
3. Tests manuels sur les points critiques
Là, on prend Burp Suite (même la version Community) et on teste à la main : les formulaires d'authentification (injection SQL basique, contournement de login), les paramètres d'URL, les cookies, les mécanismes de réinitialisation de mot de passe, les uploads. C'est là que je trouve 80 % des vraies failles. Les outils ne remplacent jamais un humain qui essaie de casser son propre site.
4. Fichiers exposés et en-têtes
Un Nikto en complément, puis une vérification manuelle : /.git/config, /.env, /backup.zip, /wp-config.php.bak, /phpinfo.php. C'est bête, mais c'est la première cause de fuite que je rencontre. Vérifiez aussi les en-têtes : CSP, HSTS, X-Content-Type-Options, X-Frame-Options, Referrer-Policy. L'absence de CSP n'est pas une faille critique en soi, mais elle transforme un XSS mineur en exécution de script.
5. Priorisation par exploitation
Je classe par exploitabilité réelle, pas par score CVSS. Une faille critique mais qui nécessite un accès physique au serveur passe après une faille moyenne exploitable en une requête depuis Internet. Tableau de priorisation, avec trois niveaux : à corriger sous 48h, sous deux semaines, sous trois mois.
Tableau récapitulatif des vérifications prioritaires
| Critère | Vérification | Outil | Fréquence |
|---|---|---|---|
| Confidentialité | TLS, certificat, fichiers exposés | SSL Labs, curl | Mensuelle |
| Intégrité | Formulaires, paramètres, uploads | Burp Suite | À chaque déploiement majeur |
| Disponibilité | Rate limiting, endpoints coûteux | Tests manuels | Trimestrielle |
| Traçabilité | Logs, rétention, alertes | Revue manuelle | Trimestrielle |
| Dépendances | Versions obsolètes, CVE | Nuclei, npm audit | Mensuelle |
6. Remédiation puis re-test
Un audit qui ne mène à aucun re-test est un audit décoratif. Je reviens systématiquement trois semaines après la remédiation. La première fois que j'ai oublié cette étape, j'ai cru un client corrigé — il avait en fait patché le mauvais fichier. Depuis, je re-teste. Toujours.
Comment réaliser un audit d'une application informatique (et pas seulement d'un site) ?
Une application web — avec authentification, comptes, données personnelles — demande un audit plus large qu'un site vitrine. La méthodologie suit le standard OWASP Testing Guide, qui reste la référence en 2026, et j'ajoute trois volets spécifiques.
Authentification et gestion des sessions
Les cookies doivent porter les flags Secure, HttpOnly, SameSite=Strict (ou Lax si vraiment nécessaire). Les sessions doivent expirer. Les mots de passe doivent être stockés avec bcrypt ou argon2, jamais en MD5 ou SHA1. Je vérifie aussi la résistance au credential stuffing : y a-t-il une limitation de tentatives ? Un CAPTCHA après échec ? Un verrouillage temporaire ?
Logique métier et contrôle d'accès
C'est le volet que les scanners ratent systématiquement. Modifier un identifiant dans une URL pour accéder au compte d'un autre utilisateur (IDOR), changer un prix, accéder à une fonction admin sans le rôle. Tout ça ne se trouve qu'en comprenant comment l'application fonctionne et en la manipulant à la main.
Revue du code et des dépendances
npm audit, composer audit, pip-audit selon la stack. Puis une revue ciblée sur les endpoints sensibles. Je ne fais pas de revue exhaustive (trop long), je cible les points d'entrée critiques : authentification, paiement, upload, export de données.
Les erreurs que j'ai faites en auditant (pour que vous ne les fassiez pas)
Deux erreurs me reviennent en mémoire, et elles sont instructives.
La première : j'ai audité un site WordPress en me concentrant sur le thème et les plugins, et j'ai complètement oublié de vérifier la version de PHP. Le site tournait sur une version obsolète depuis deux ans. Le thème était impeccable. Le serveur, pas du tout. Depuis, je commence toujours par l'environnement (PHP, base de données, serveur web) avant de toucher au code applicatif.
La seconde : j'avais livré un rapport excellent, exhaustif, priorisé. Le client ne l'a pas lu. Trop long, trop technique. J'ai appris à faire deux versions : une page pour le dirigeant (les trois choses à corriger, le coût du risque), et un document technique complet pour l'équipe. Un audit qui dort dans une boîte mail ne protège personne.
Bref. Auditer la sécurité de son site web, ce n'est pas une formalité qu'on coche. C'est un cycle : vérifier, corriger, re-tester, recommencer. Les sites que je vois le mieux protégés ne sont pas ceux qui ont fait le plus gros audit — ce sont ceux qui ont gardé le rythme. Une vérification mensuelle de 30 minutes fait plus qu'un pentest annuel qu'on oublie de renouveler.
Et cette curiosité du départ, celle qui m'a fait ouvrir /.env par hasard ? C'est devenu la première ligne de ma checklist. Il faut toujours un premier réflexe. Le vôtre peut être celui-là.
