Comment auditer la cybersecurite de son site web en 8 etapes

Votre site web est la vitrine numerique de votre entreprise — mais c'est aussi une surface d'attaque. En 2026, les cyberattaques ciblant les sites web ont augmente de 38% par rapport a l'annee precedente, et les PME sont les premieres victimes : 43% des attaques visent des entreprises de moins de 250 salaries, selon le dernier rapport de l'ANSSI. La raison est simple : les grands groupes ont des equipes securite dediees, les PME non. Un audit de cybersecurite web regulier est le meilleur moyen de combler cet ecart.

Ce guide vous presente les 8 etapes essentielles pour auditer la securite de votre site web, que vous le fassiez en interne ou avec l'aide d'un prestataire. Chaque etape est accompagnee d'outils concrets, de commandes a executer et de criteres de validation. L'objectif n'est pas de transformer votre equipe en experts en cybersecurite, mais de vous donner les moyens de detecter les failles les plus courantes et les plus critiques avant qu'un attaquant ne le fasse.

— Etape 1 : Verifier la configuration HTTPS et TLS

Le HTTPS n'est plus une option — c'est un prerequis. Un site accessible en HTTP transmet les donnees en clair, exposant les mots de passe, cookies de session et donnees personnelles a toute personne sur le meme reseau. Mais avoir un certificat SSL ne suffit pas : la configuration TLS doit etre durcie pour resister aux attaques modernes.

Ce qu'il faut verifier :

• Le certificat est valide, non expire, et couvre tous vos sous-domaines (ou utilisez un certificat wildcard)
• Seuls les protocoles TLS 1.2 et TLS 1.3 sont actives. TLS 1.0 et 1.1 doivent etre desactives (obsoletes depuis 2020)
• Les suites de chiffrement faibles sont desactivees (RC4, 3DES, CBC sans AEAD)
• La redirection HTTP vers HTTPS est en place sur toutes les URL
• Le header Strict-Transport-Security (HSTS) est configure avec une duree d'au moins 6 mois

Outils recommandes : SSL Labs Server Test (gratuit, note de A+ a F), testssl.sh (open source, a executer en ligne de commande), nmap --script ssl-enum-ciphers.

Critere de validation : Score A ou A+ sur SSL Labs. Tout score inferieur a B indique une configuration a corriger en priorite.

— Etape 2 : Auditer les headers de securite HTTP

Les headers de securite HTTP sont des directives envoyees par le serveur au navigateur pour activer des protections cote client. Ils ne coutent rien a deployer et bloquent des classes entieres d'attaques (XSS, clickjacking, injection de contenu). Pourtant, une majorite de sites web ne les configurent pas ou mal.

Les headers essentiels a verifier :

Outils recommandes : securityheaders.com (note de A+ a F, gratuit), curl -I https://votre-site.fr pour une verification rapide. L'extension navigateur "HTTP Header Live" permet de voir les headers en temps reel.

— Etape 3 : Scanner les vulnerabilites connues

Le scan de vulnerabilites est le coeur de l'audit. Il s'agit d'identifier les failles techniques exploitables dans votre site web : injections SQL, cross-site scripting (XSS), composants obsoletes avec des CVE connues, fichiers de configuration exposes, pages d'administration non protegees. L'objectif n'est pas de tout trouver — seul un test d'intrusion professionnel le peut — mais de couvrir les 80% de vulnerabilites les plus courantes.

Methodologie de scan :

1. Scan passif : identifiez les technologies utilisees (CMS, framework, serveur web, version PHP/Node.js) avec Wappalyzer ou whatweb
2. Scan de versions : verifiez si les composants identifies ont des CVE connues. Utilisez WPScan pour WordPress, droopescan pour Drupal, ou Nuclei pour un scan generique
3. Scan actif OWASP Top 10 : utilisez OWASP ZAP (gratuit) ou Nikto pour tester les injections SQL, XSS, CSRF, et les erreurs de configuration
4. Enumeration de fichiers : recherchez les fichiers sensibles exposes (.env, .git/, wp-config.php.bak, phpinfo.php) avec dirsearch ou gobuster

Attention : ne lancez jamais un scan de vulnerabilites sur un site qui ne vous appartient pas. C'est illegal (articles 323-1 a 323-7 du Code penal). Assurez-vous d'avoir l'autorisation ecrite du proprietaire du site avant tout scan actif.

— Etape 4 : Evaluer la securite de l'authentification

L'authentification est la premiere ligne de defense de votre site. Si vos formulaires de connexion sont mal protege, un attaquant peut acceder a l'interface d'administration, aux comptes utilisateurs ou aux donnees sensibles. En 2026, les attaques par force brute et le credential stuffing (reutilisation de mots de passe voles) representent 34% des compromissions de sites web.

Points a verifier :

• Politique de mots de passe : longueur minimale de 12 caracteres, pas de mots de passe courants (verification contre les listes compromises comme HaveIBeenPwned)
• Authentification multi-facteurs (MFA) : activee au minimum sur tous les comptes administrateurs. TOTP (Google Authenticator, Authy) ou cles FIDO2 sont les methodes recommandees
• Protection anti-brute force : rate limiting sur les endpoints de connexion (max 5 tentatives par minute), CAPTCHA apres 3 echecs, verrouillage temporaire de compte
• Gestion des sessions : cookies avec les attributs HttpOnly, Secure et SameSite=Strict. Duree de session raisonnable (max 4h pour les admins)
• Pages d'administration : URL non predictibles (pas /admin ou /wp-admin sans protection supplementaire), restriction par IP si possible

— Etape 5 : Auditer le code source et les dependances

Votre site web repose sur du code — le votre et celui de dizaines de bibliotheques tierces. Chaque dependance est un vecteur d'attaque potentiel : une faille dans une seule bibliotheque npm, un plugin WordPress ou un module PHP peut compromettre l'ensemble du site. En 2026, les attaques de type supply chain via des dependances compromises ont triple par rapport a 2024.

Pour les sites bases sur un CMS (WordPress, Drupal, SPIP) :

• Verifiez que le CMS et tous les plugins/extensions sont a jour
• Desactivez et supprimez les plugins non utilises (chaque plugin est une surface d'attaque)
• Verifiez que le theme n'utilise pas de fonctions PHP dangereuses (eval(), system())

Pour les sites developpes sur mesure (Node.js, Python, PHP) :

• Executez npm audit (Node.js), pip audit (Python), ou composer audit (PHP) pour lister les dependances vulnerables
• Utilisez un outil SCA (Software Composition Analysis) comme Snyk, Dependabot ou Trivy pour un suivi continu
• Verifiez que les dependances ne proviennent pas de packages malveillants (typosquatting, packages compromis)

— Etape 6 : Verifier la conformite RGPD et la protection des donnees

La conformite RGPD n'est pas qu'une question juridique — c'est un indicateur de maturite en securite des donnees. Un site qui gere correctement les consentements cookies, le chiffrement des donnees personnelles et les formulaires de contact est generalement mieux securise qu'un site qui n'y prete pas attention.

Points de verification :

• Bandeau de consentement cookies : presente avant tout depot de cookies non essentiels. Pas de case pre-cochee. Refus aussi facile que l'acceptation. Conforme aux recommandations de la CNIL
• Formulaires de contact : les donnees soumises sont transmises via HTTPS, stockees de maniere chiffree, et purgees regulierement. Une mention legale informe l'utilisateur du traitement de ses donnees
• Base de donnees : les mots de passe sont haches avec bcrypt ou Argon2 (jamais MD5 ou SHA-1). Les donnees personnelles sensibles sont chiffrees au repos
• Sauvegardes : les sauvegardes de la base de donnees sont chiffrees et stockees sur un support separe. Testez regulierement la restauration
• Politique de confidentialite : a jour, accessible, et coherente avec les traitements reels du site

Outil recommande : le guide AIPD de la CNIL, l'extension navigateur "CookieBot" pour auditer les cookies, et Lighthouse (onglet "Best Practices") pour une verification rapide.

— Etape 7 : Evaluer la protection WAF et anti-DDoS

Un WAF (Web Application Firewall) est un bouclier entre votre site et les attaquants. Il filtre les requetes malveillantes avant qu'elles n'atteignent votre application. Sans WAF, votre site est expose directement aux scans de vulnerabilites automatises, aux tentatives d'injection SQL, aux attaques XSS et aux attaques par deni de service (DDoS). En 2026, un site web non protege par un WAF recoit en moyenne 2 300 requetes malveillantes par jour.

Points de verification :

• WAF deploye et actif : que ce soit un WAF cloud (Cloudflare, AWS WAF, Sucuri) ou un WAF applicatif (ModSecurity), verifiez qu'il est en mode "blocking" et non "monitoring only"
• Regles OWASP Core Rule Set : activees pour couvrir les injections SQL, XSS, path traversal, et les attaques connues
• Rate limiting : limite de requetes par IP (typiquement 100 requetes/minute pour un site vitrine, ajustable selon le trafic)
• Protection DDoS : votre hebergeur ou CDN offre-t-il une protection contre les attaques volumetriques ? Testez avec un outil comme slowloris (sur votre propre site uniquement)
• IP du serveur non exposee : si vous utilisez un CDN comme Cloudflare, verifiez que l'IP reelle du serveur n'est pas decouvrable via les enregistrements DNS historiques ou les sous-domaines

— Etape 8 : Mettre en place le monitoring et le plan de reponse

Un audit est une photographie a un instant T. Sans monitoring continu, les nouvelles vulnerabilites qui apparaissent entre deux audits restent invisibles jusqu'a ce qu'un attaquant les exploite. L'etape finale de votre audit consiste a mettre en place les mecanismes qui vous alerteront en continu.

Les piliers du monitoring securite web :

• Surveillance de la disponibilite : alerte si votre site tombe (signe potentiel d'attaque DDoS ou de compromission). Outils : UptimeRobot, Pingdom (gratuits pour un nombre limite de moniteurs)
• Surveillance des certificats SSL : alerte avant l'expiration du certificat (30 jours minimum). Un certificat expire = perte de HTTPS = perte de confiance + penalite SEO
• Surveillance des modifications de fichiers : detectez les changements non autorises sur vos fichiers (defacement, injection de webshell). Outils : AIDE, Tripwire, ou les fonctionnalites de monitoring de votre hebergeur
• Logs d'acces et d'erreurs : centralisez les logs de votre serveur web et analysez-les regulierement. Cherchez les patterns suspects : scans de vulnerabilites, tentatives de brute force, requetes vers des fichiers sensibles
• Alertes CVE : abonnez-vous aux alertes de securite pour les technologies que vous utilisez (newsletter du CMS, flux RSS CERT-FR, alertes NVD)

Plan de reponse a incident : meme le site le mieux securise peut etre compromis. Preparez un plan de reponse a incident qui repond aux questions : qui est responsable en cas d'incident ? Comment isoler le site compromis ? Comment restaurer a partir d'une sauvegarde saine ? Comment notifier les utilisateurs et la CNIL si des donnees personnelles sont exposees ? Documentez ce plan et testez-le au moins une fois par an. Pour aller plus loin, consultez notre guide sur la gestion des vulnerabilites en PME.

— Conclusion : de l'audit a l'amelioration continue

Auditer la cybersecurite de votre site web en 8 etapes n'est pas un exercice ponctuel — c'est le point de depart d'un processus continu. Chaque audit revele des failles, chaque correction ameliore votre posture de securite, et chaque nouveau composant installe ou mise a jour manquee cree de nouvelles opportunites pour les attaquants.

La bonne frequence d'audit depend de votre contexte : trimestriel pour les sites qui traitent des donnees personnelles ou des transactions, semestriel pour les sites vitrines simples, et apres chaque modification majeure (nouvelle fonctionnalite, changement d'hebergeur, mise a jour du CMS). L'investissement est minimal compare au cout d'une compromission : en moyenne 45 000 euros pour une PME francaise, sans compter l'impact sur la reputation.

Si vous souhaitez aller plus loin, un test d'intrusion professionnel complete l'audit automatise en exploitant manuellement les failles trouvees, en testant les scenarios d'attaque complexes et en validant l'efficacite de vos protections dans des conditions reelles. C'est la difference entre verifier que la porte est fermee et tenter de la forcer.