FlashScanr
ConnexionAnalyser mon site
← Articles
Vue d'ensemble

Audit sécurité web : les 10 risques les plus courants

Audit sécurité web : les 10 risques les plus courants

« Mon site n'intéresse pas les hackers. » C'est la phrase la plus répandue — et la plus fausse — de la sécurité web. Elle repose sur un malentendu : vous imaginez un attaquant qui choisit sa cible. La réalité est inverse : l'écrasante majorité des attaques sont menées par des robots qui scannent l'intégralité du web en permanence, à la recherche de configurations vulnérables. Votre site est testé plusieurs fois par jour, que vous soyez une multinationale ou un cabinet de trois personnes.

Ce que cherchent ces robots n'a rien de sophistiqué : un certificat mal configuré, un fichier de configuration oublié, un en-tête manquant. Voici les 10 risques que tout audit de sécurité contrôle en priorité.

1. Certificat TLS : expiration et protocoles obsolètes

Le certificat TLS chiffre les échanges entre votre site et vos visiteurs. Trois défauts classiques :

  • Expiration imminente ou dépassée : un certificat expiré affiche un avertissement plein écran à chaque visiteur — chute de trafic immédiate. L'audit vérifie la date et alerte avant l'échéance.
  • Protocoles obsolètes : SSLv3, TLS 1.0 et TLS 1.1 sont cassés ou dépréciés depuis des années. Le minimum est TLS 1.2 ; le standard moderne est TLS 1.3.
  • Chaîne incomplète ou domaines non couverts : un certificat valide sur www.site.fr mais pas sur site.fr casse la moitié de vos accès.

2. HSTS : forcer le HTTPS

Sans l'en-tête HSTS (Strict-Transport-Security), un visiteur qui tape votre adresse sans « https:// » fait sa première requête en clair — fenêtre exploitable pour une interception (SSL stripping). HSTS dit au navigateur : « ne me contacte plus jamais qu'en HTTPS ». Une ligne de configuration, une classe de risque éliminée.

3. CSP : la ceinture de sécurité contre les injections

La Content Security Policy définit ce que le navigateur a le droit de charger sur vos pages (scripts, styles, images, iframes) et depuis où. C'est la défense la plus efficace contre les injections de code (XSS) : même si un attaquant parvient à injecter un script, le navigateur refuse de l'exécuter s'il viole la politique. Son absence est l'un des manquements les plus fréquents — et sa présence l'un des meilleurs signaux de maturité d'un site.

4. Les autres en-têtes de protection

Quatre en-têtes complètent la panoplie, chacun fermant une porte précise :

  • X-Frame-Options (ou frame-ancestors en CSP) : empêche l'affichage de votre site dans une iframe frauduleuse — la base du clickjacking, où l'utilisateur clique sur votre interface sans le savoir.
  • X-Content-Type-Options: nosniff : empêche le navigateur de « deviner » le type d'un fichier, vecteur d'exécution de code déguisé.
  • Referrer-Policy : contrôle les informations de provenance transmises aux sites tiers (sans elle, les URLs internes complètes fuitent).
  • Permissions-Policy : désactive les API sensibles (caméra, micro, géolocalisation) que votre site n'utilise pas.

Comment corriger : déployer les en-têtes de sécurité

Apache

Dans le fichier .htaccess à la racine du site (module mod_headers, actif chez la quasi-totalité des hébergeurs mutualisés) :

# En-têtes de sécurité de base
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"

Pour la CSP, commencez par Content-Security-Policy-Report-Only : vous mesurez les violations sans rien casser, puis vous basculez en mode bloquant.

nginx

Dans le bloc server de votre configuration, puis nginx -t && systemctl reload nginx :

# En-têtes de sécurité de base ("always" = aussi sur les pages d'erreur)
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

Attention : un add_header dans un bloc location annule ceux du bloc server — déclarez-les à un seul niveau.

WordPress

La plupart des WordPress mutualisés tournent sous Apache : ajoutez les directives de l'onglet Apache dans le .htaccess à la racine (après le bloc # END WordPress). Alternative sans toucher aux fichiers : un plugin dédié aux en-têtes HTTP de sécurité — vérifiez après coup avec l'audit que les en-têtes sortent réellement.

SaaS

Shopify, Wix et Squarespace gèrent les en-têtes HTTP eux-mêmes : vous ne pouvez ni les ajouter ni les modifier. HSTS et les protections de base y sont déjà en place. Si un audit signale une CSP absente sur ces plateformes, c'est une limite de la plateforme — pas une action à votre charge.

5. DNS : SPF, DMARC, DNSSEC, CAA

Votre zone DNS protège votre identité — en particulier votre domaine email :

  • SPF liste les serveurs autorisés à envoyer des emails en votre nom.
  • DMARC indique quoi faire des emails qui échouent la vérification — sans lui, n'importe qui peut envoyer des factures frauduleuses signées de votre domaine, et c'est un scénario d'arnaque au président tout à fait courant contre les PME.
  • DNSSEC signe cryptographiquement vos enregistrements DNS contre leur falsification.
  • CAA restreint les autorités habilitées à émettre des certificats pour votre domaine.

SPF et DMARC absents ou mal configurés sont parmi les découvertes les plus fréquentes d'un audit — et leur correction tient en deux enregistrements DNS.

6. Cookies non sécurisés

Un cookie de session sans flag Secure peut transiter en clair ; sans HttpOnly, il est lisible par n'importe quel script injecté ; sans SameSite, il accompagne des requêtes forgées depuis d'autres sites (CSRF). Le vol d'un cookie de session, c'est le vol du compte — sans avoir besoin du mot de passe.

7. Fichiers sensibles exposés

Les robots scannent en permanence une liste d'URLs bien connues :

  • .git/ : un dépôt Git accessible permet de reconstituer tout votre code source — identifiants de base de données inclus, le cas échéant.
  • .env : ce fichier concentre par définition vos secrets (clés API, mots de passe).
  • phpinfo.php, backup.sql, wp-config.php.bak : restes de développement et sauvegardes oubliées.

Ces expositions ne demandent aucune compétence pour être exploitées — il suffit de demander le fichier. C'est la première chose que teste un scanner automatique, et l'une des premières qu'un audit vérifie.

Comment corriger : bloquer l'accès aux fichiers sensibles

Apache

Dans le .htaccess à la racine :

# Refuser l'accès aux fichiers et dossiers sensibles
<FilesMatch "^\.(env|git|htaccess)">
  Require all denied
</FilesMatch>
RedirectMatch 404 /\.git

Et supprimez par FTP les restes de développement (phpinfo.php, sauvegardes .sql, fichiers .bak) : les bloquer c'est bien, ne pas les laisser traîner c'est mieux.

nginx

Dans le bloc server :

# Refuser l'accès aux fichiers cachés et sensibles
location ~ /\.(env|git) {
  deny all;
  return 404;
}

WordPress

Mêmes directives Apache dans le .htaccess. Supprimez aussi les copies de wp-config.php créées par les éditeurs (wp-config.php.bak, wp-config.php~) et les exports de base laissés par les plugins de sauvegarde dans wp-content/.

SaaS

Non concerné : vous n'avez pas d'accès fichiers sur Shopify, Wix ou Squarespace — la plateforme garantit qu'aucun fichier de configuration n'est exposé.

8. Divulgation d'informations serveur

Les en-têtes Server: Apache/2.4.41 ou X-Powered-By: PHP/7.2.0 publient la version exacte de vos logiciels. Pour un attaquant, c'est un raccourci : il lui suffit de croiser la version avec les bases de vulnérabilités publiques pour savoir quelles failles tester. Masquer ces en-têtes ne corrige pas les failles, mais cesse d'offrir le mode d'emploi.

9. Contenu mixte HTTP/HTTPS

Une page servie en HTTPS qui charge des ressources (scripts, images) en HTTP simple ouvre une brèche dans le chiffrement : ces ressources peuvent être interceptées et modifiées en transit. Les navigateurs bloquent désormais le contenu mixte « actif », ce qui casse des fonctionnalités — et le contenu « passif » continue de fuiter des informations. Séquelle classique d'une migration HTTPS inachevée.

10. Le fichier security.txt

Standardisé par la RFC 9116, le fichier /.well-known/security.txt indique aux chercheurs en sécurité comment vous contacter s'ils découvrent une vulnérabilité sur votre site. Sans lui, la personne qui trouve une faille n'a aucun canal pour vous prévenir — et la faille reste ouverte. Cinq lignes de texte qui transforment un inconnu bien intentionné en allié.

Comment réagir si une vulnérabilité est trouvée ?

Un rapport d'audit qui remonte des problèmes n'est pas une mauvaise nouvelle — c'est une liste de tâches, à traiter dans l'ordre :

  1. Traitez d'abord les expositions directes : fichiers sensibles accessibles, certificat expiré, protocoles cassés. Ce sont les portes ouvertes.
  2. Si un secret a pu être exposé (.env, .git), considérez-le comme compromis : changez les mots de passe et révoquez les clés API concernées, même sans preuve d'accès.
  3. Déployez les en-têtes manquants : HSTS, CSP, X-Frame-Options se configurent au niveau du serveur web et ne demandent aucune refonte.
  4. Corrigez le DNS : SPF et DMARC en premier — l'usurpation de votre domaine email menace vos clients autant que vous.
  5. Re-testez après correction : une configuration de sécurité se vérifie, elle ne se suppose pas.

Testez votre site avant les robots

Tous les points de cet article ont un point commun : ils sont vérifiables de l'extérieur, sans accès à votre serveur — c'est exactement ainsi que les robots d'attaque vous évaluent. FlashScanr analyse votre site sur l'ensemble de ces contrôles — certificat, en-têtes, DNS, cookies — et vous remet un rapport priorisé avec, pour chaque risque détecté, la correction à apporter.

Lancez votre audit sécurité gratuit →

Vous souhaitez analyser votre site ?

Lancer un audit gratuit