SSL, DNS, vulnérabilités — ce que vous ignorez sur votre site

Zakaria Gharzouli·18 avril 2026·7 min de lecture

Votre site est en HTTPS. Vous avez un petit cadenas dans la barre d'adresse. Vous pensez être en sécurité. C'est exactement ce que pensent 80% des propriétaires de sites web qui ont, en réalité, des vulnérabilités critiques non corrigées.

Le problème n'est pas l'ignorance de la sécurité — c'est une fausse compréhension de ce qu'elle signifie réellement. Voici les cinq angles morts les plus courants.

1. Avoir un certificat SSL ne signifie pas être sécurisé

C'est le malentendu le plus répandu. Le cadenas HTTPS certifie une seule chose : que la connexion entre le navigateur de votre visiteur et votre serveur est chiffrée en transit. Ce n'est pas une garantie de l'intégrité de votre site, de l'absence de malware, ni de la robustesse de votre infrastructure.

Un site peut avoir un certificat SSL valide et simultanément :

  • Utiliser TLS 1.0 ou 1.1, deux protocoles officiellement dépréciés depuis 2021 (RFC 8996). Ces versions sont vulnérables à des attaques documentées comme BEAST, POODLE, et CRIME.
  • Utiliser des suites cryptographiques faibles (RC4, export ciphers) qui peuvent être cassées avec des ressources modestes.
  • Avoir un certificat signé par une autorité de certification compromise ou peu fiable.
  • Laisser des sous-domaines en HTTP — même si le domaine principal est en HTTPS.

Ce qui importe, c'est la qualité du SSL, pas sa présence. SSL Labs (ssllabs.com) analyse ces paramètres en détail et vous donne une note. Tout ce qui est en dessous de A est un problème à traiter.

Par ailleurs, les certificats expirent. Même Let's Encrypt, qui est gratuit et très utilisé, nécessite un renouvellement tous les 90 jours. Un certificat expiré n'est pas juste un avertissement gênant — c'est une interruption de service et un signal négatif fort pour vos visiteurs. Configurez des alertes à 30, 14 et 7 jours avant expiration.

2. Votre DNS : la surface d'attaque que personne ne surveille

Le DNS est le système qui traduit votresite.com en adresse IP. C'est aussi l'un des vecteurs d'attaque les moins surveillés par les propriétaires de sites.

Le subdomain takeover est une vulnérabilité particulièrement insidieuse. Elle survient quand vous avez un sous-domaine (par exemple newsletter.votresite.com) qui pointe vers un service tiers que vous n'utilisez plus — une ancienne instance Heroku, un bucket S3 supprimé, une page HubSpot désactivée. Si le service est supprimé mais que l'enregistrement DNS existe toujours, n'importe qui peut revendiquer ce service tiers et prendre le contrôle de votre sous-domaine. Du point de vue de vos visiteurs, le contenu affiché semble venir de vous.

Pour auditer cela : exportez tous vos enregistrements DNS et vérifiez que chaque CNAME pointe vers un service actif que vous contrôlez. Des outils comme can-i-take-over-xyz (sur GitHub) automatisent cette vérification.

Le DNS sans SPF, DKIM et DMARC est une invitation à l'usurpation d'identité. Sans ces trois enregistrements correctement configurés, n'importe qui peut envoyer un email qui semble provenir de contact@votresite.com. Ces emails passent souvent les filtres anti-spam basiques et arrivent directement dans la boîte de vos clients, partenaires, ou fournisseurs. Les attaques de phishing ciblées (spear phishing) utilisent massivement ce vecteur.

La configuration minimale à avoir :

  • SPF : v=spf1 include:votre-fournisseur-email.com ~all
  • DKIM : clé publique publiée dans un enregistrement TXT, signature vérifiable par les destinataires
  • DMARC : v=DMARC1; p=reject; rua=mailto:dmarc@votresite.com — la politique reject est la seule qui soit vraiment protectrice

Beaucoup de sites ont SPF mais pas DMARC, ce qui rend SPF pratiquement inutile : sans DMARC, le destinataire ne sait pas quoi faire quand SPF échoue.

3. Les headers HTTP manquants : la faille silencieuse

Les headers HTTP de sécurité sont invisibles pour vos visiteurs mais fondamentaux pour la protection de votre site. Leur absence ne cause pas d'erreur visible — elle ouvre simplement des vecteurs d'attaque.

Content-Security-Policy (CSP) est le plus important et le plus souvent absent. Sans CSP, votre site est vulnérable aux attaques XSS (Cross-Site Scripting) : un attaquant qui réussit à injecter du code JavaScript dans une page peut voler les sessions de vos utilisateurs, exfiltrer des données de formulaires, ou rediriger vers des sites malveillants. Les attaques XSS représentent historiquement l'une des catégories de vulnérabilités les plus exploitées du web.

HTTP Strict Transport Security (HSTS) est régulièrement mal compris. Avoir le HTTPS activé ne suffit pas — sans HSTS, un utilisateur qui tape votresite.com (sans https://) peut être redirigé vers la version HTTP avant d'être renvoyé vers HTTPS. Cette fenêtre, même brève, permet une attaque de type SSL stripping sur les réseaux non sécurisés (Wi-Fi public, réseaux d'entreprise compromis).

Avec HSTS correctement configuré (Strict-Transport-Security: max-age=31536000; includeSubDomains; preload), le navigateur refuse d'établir toute connexion HTTP, même lors de la première visite.

X-Frame-Options et son successeur frame-ancestors dans la CSP protègent contre le clickjacking : une technique où votre site est chargé dans une iframe invisible superposée à un autre site, amenant votre utilisateur à cliquer sur des éléments de votre site sans le savoir — par exemple, un bouton de confirmation de virement.

4. Les versions de logiciels : la porte d'entrée préférée des bots

Les scanners automatisés parcourent internet en permanence à la recherche de versions vulnérables connues. Ils ne visent pas votre site en particulier — ils cherchent des patterns. Si votre serveur expose PHP/7.4.3 dans ses headers ou que votre WordPress tourne en version 6.3 (alors que des failles de sécurité sont corrigées dans 6.5+), vous êtes dans les listes de cibles potentielles.

Les vecteurs les plus exploités :

  • Plugins WordPress non mis à jour : c'est la première cause de compromission des sites WordPress. Des plugins avec des centaines de milliers d'installations ont régulièrement des CVE critiques publiées.
  • Versions PHP obsolètes : PHP 7.4 n'est plus maintenu depuis décembre 2022. Toute vulnérabilité découverte depuis cette date n'est pas corrigée.
  • Dépendances JavaScript (npm) : votre frontend utilise probablement des bibliothèques avec des sous-dépendances. npm audit ou yarn audit révèle souvent des dizaines de vulnérabilités dans des packages que vous n'avez jamais installés directement.

La règle est simple : si un logiciel n'est plus maintenu, il est vulnérable. Pas potentiellement — il l'est.

5. "Mon site n'est pas assez important pour être hacké"

C'est le raisonnement le plus dangereux. Les attaques modernes sont massivement automatisées. Un bot ne décide pas de cibler votre site parce qu'il est intéressant — il scanne des millions de sites et exploite les failles qu'il trouve, mécaniquement.

Votre site compromis peut servir à :

  • Envoyer du spam à des millions d'adresses depuis votre IP (ce qui blackliste votre domaine)
  • Héberger du phishing — des pages imitant des banques ou services populaires, hébergées sur votre domaine de bonne réputation
  • Miner de la cryptomonnaie en utilisant les ressources de votre serveur
  • Servir de point de rebond dans une attaque plus large sur d'autres cibles
  • Exfiltrer les données de vos clients si vous avez un formulaire de contact ou un e-commerce

La taille de votre site est indifférente. Sa réputation de domaine, son infrastructure, ses ressources serveur — tout cela a de la valeur pour un attaquant, même si votre activité est modeste.

Ce que ça signifie concrètement

Ces cinq vulnérabilités — SSL mal configuré, DNS non sécurisé, headers manquants, logiciels obsolètes, et fausse sécurité par obscurité — forment le profil type du site exploité avec succès. Elles sont toutes détectables automatiquement et corrigeables sans compétences avancées.

Le premier pas est simple : savoir où vous en êtes. Un audit automatisé vous donne en quelques secondes une vue claire de vos expositions. Ce que vous faites ensuite est une décision éclairée — pas une découverte après coup.

Zakaria Gharzouli — Residual Labs

Zakaria Gharzouli

Founder & Software Engineer — Residual Labs

Fondateur de Residual Labs, studio d'ingénierie IA basé à Paris. Spécialisé en agents IA autonomes, automatisation B2B et développement SaaS sur mesure.

Residual Audit

Votre site est-il vraiment sécurisé ?

Analysez votre site en 60 secondes : SSL, DNS, CVE, headers de sécurité. 30+ sources. Rapport complet gratuit.

Lancer l'audit gratuit →

Dans la même catégorie