Sécurité de surface web — TLS, HTTPS, en-têtes HTTP

Sécurité de surface web en langage clair —
les fondations vérifiables d'un site PME

La sécurité de surface, c'est ce qu'un visiteur ou un outil d'analyse peut observer sans se connecter. Configuration TLS, en-têtes HTTP, fichiers accessibles publiquement, version du CMS exposée — autant d'éléments mesurables qui forment la première ligne de défense d'un site web. Pour une PME québécoise, c'est la couche la plus vérifiable et la plus rapide à durcir, et c'est aussi celle qu'examinent les contrôles qualité de site web et les outils automatisés de cybersécurité.

Contenu informatif. Ne constitue pas un avis juridique — pour des conseils personnalisés, consultez un juriste qualifié.

Comprendre la sécurité de surface web — guide pratique pour PME québécoises

Avant de parler de vulnérabilités complexes (injections, contrôle d'accès), un site web doit avoir des fondations correctes. Ces fondations sont vérifiables en quelques minutes par n'importe qui — y compris par un attaquant en quête d'une cible facile.

Préalable conseillé : avant d'aborder cette page, parcourir la fiche OWASP Top 10 qui présente le cadre de référence des vulnérabilités web. Le présent guide approfondit la dimension surface (catégories A02 et A05 de l'OWASP).

Qu'est-ce que la sécurité de surface et pourquoi c'est central

Définition : la sécurité de surface désigne ce qu'un visiteur ou un outil d'analyse externe peut observer du site sans connexion : configuration TLS, en-têtes HTTP, présence de fichiers sensibles, version du CMS, comportement face aux requêtes spéciales. C'est la couche la plus immédiatement visible et la plus rapide à mesurer.

Trois raisons pour lesquelles cette couche est traitée en priorité dans les contrôles qualité :

  • Vérifiable de l'extérieur — pas besoin d'accès admin, pas besoin du code source. Un consultant ou un attaquant peut produire un verdict en 10 minutes.
  • Standardisée — les bonnes pratiques sont les mêmes pour tous les sites (PME, grandes entreprises, gouvernements). Les outils de mesure (Mozilla Observatory, SSL Labs) appliquent les mêmes critères partout.
  • Souvent mal configurée — la majorité des sites de PME québécoises ont des écarts sur la sécurité de surface, simplement parce que les valeurs par défaut des plateformes ne sont pas optimales. C'est aussi la couche la plus rapide à corriger.

Les attaquants automatisés balayent l'Internet en continu à la recherche de sites avec une configuration faible. Avoir une sécurité de surface correcte ne garantit pas qu'on ne sera jamais visé — mais ça retire le site de la cible facile.

À retenir

La sécurité de surface n'est pas le tout de la sécurité d'un site — c'est le minimum vérifiable. Sans elle, les couches plus profondes (gestion des comptes, sécurité du code) deviennent inutiles. Une configuration de surface correcte est un préalable, pas un aboutissement.

HTTPS et TLS — la fondation cryptographique

Définition : HTTPS est la version chiffrée du protocole HTTP. Le chiffrement repose sur TLS (Transport Layer Security), qui a remplacé SSL au milieu des années 2010. Aujourd'hui, TLS 1.2 est le minimum acceptable, TLS 1.3 est recommandé. Les versions plus anciennes (SSL 3.0, TLS 1.0, TLS 1.1) ne devraient plus être actives.

Trois exigences pour une configuration HTTPS correcte :

  1. Certificat TLS valide. Émis par une autorité de certification reconnue (Let's Encrypt, DigiCert, GoDaddy, etc.), pas expiré, couvrant le bon domaine. La majorité des hébergeurs offrent désormais des certificats Let's Encrypt gratuits configurés automatiquement.
  2. Versions de TLS modernes. Activer TLS 1.2 et TLS 1.3, désactiver tout ce qui est antérieur. Les configurations « out of the box » des hébergeurs récents le font correctement, mais les hébergements plus anciens peuvent encore accepter TLS 1.0 ou 1.1.
  3. Suites de chiffrement fortes. Sélection des algorithmes utilisés. Les outils d'évaluation comme SSL Labs vérifient ce point — un grade A ou A+ confirme une configuration correcte.

Toutes les pages servies en HTTPS : il ne suffit pas que la page d'accueil soit en HTTPS. Toutes les pages, toutes les ressources (images, scripts, polices) doivent l'être. Une page principale en HTTPS qui charge des images en HTTP affiche un cadenas brisé dans le navigateur. La redirection 301 du HTTP vers HTTPS est attendue.

Outil de vérification : SSL Labs SSL Test publie un grade A+ à F sur la configuration TLS. C'est l'outil de référence utilisé dans les contrôles qualité.

À retenir

HTTPS n'est plus une option en 2026 — c'est le minimum absolu. Un site sans HTTPS est exclu des résultats de recherche par défaut, signalé comme dangereux par les navigateurs, et techniquement inacceptable pour collecter des renseignements personnels au sens de la Loi 25.

Strict-Transport-Security (HSTS) — forcer HTTPS au navigateur

Définition : HSTS est un en-tête HTTP qui dit au navigateur : « pour ce domaine, utilise toujours HTTPS, jamais HTTP, pour la durée indiquée ». Il protège contre les attaques de type SSL stripping où un attaquant intercepte la connexion initiale en HTTP avant la redirection vers HTTPS.

Format type :

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Lecture des trois directives :

  • max-age=31536000 — durée en secondes (un an). Pendant un an, le navigateur n'essaiera plus jamais HTTP pour ce domaine.
  • includeSubDomains — étend la protection à tous les sous-domaines (api.votreentreprise.ca, blog.votreentreprise.ca).
  • preload — indique au domaine d'être ajouté à la liste de préchargement maintenue par les navigateurs (Chrome, Firefox, Safari, Edge). Le domaine est alors forcé en HTTPS dès la première visite, sans attendre que le navigateur ait reçu l'en-tête.

Pour activer le preload : publier l'en-tête HSTS avec les trois directives, puis soumettre le domaine à hstspreload.org (service maintenu par Google). Une fois accepté, le domaine apparaît dans la liste compilée par les navigateurs. Le retrait de la liste prend ensuite plusieurs mois — c'est un engagement durable.

À retenir

HSTS avec max-age d'un an est le standard. Le preload est l'étape supplémentaire pour les sites stables. Pour une PME, configurer HSTS est typiquement une ligne dans la configuration du serveur web ou un réglage dans le panneau de l'hébergeur.

Les autres en-têtes HTTP de sécurité essentiels

Constat : au-delà de HSTS, cinq autres en-têtes ferment des angles d'attaque au niveau du navigateur. La majorité sont configurables sans développement, soit dans le serveur web, soit via un plugin de sécurité du CMS.

Content-Security-Policy (CSP).

Politique qui dit au navigateur quelles sources de contenu (scripts, styles, images, polices) sont autorisées. C'est la principale défense contre les attaques XSS (Cross-Site Scripting). Configuration complexe — elle exige d'inventorier toutes les ressources légitimes du site. Bonne pratique : démarrer en mode Content-Security-Policy-Report-Only pour observer les violations sans bloquer, puis durcir progressivement vers la version appliquée.

Une CSP en mode Report-Only rapporte les violations à la console mais n'applique aucune restriction. Si l'objectif est la protection effective, il faut basculer vers l'en-tête appliqué (sans le suffixe Report-Only) une fois la politique stabilisée.

X-Frame-Options.

Empêche le site d'être affiché dans un cadre (iframe) sur un autre site. Protection contre le clickjacking. Valeurs : DENY (interdire toute mise en cadre) ou SAMEORIGIN (autoriser uniquement depuis le même domaine). SAMEORIGIN est le choix par défaut pour la majorité des sites. Largement remplacé par la directive frame-ancestors de la CSP, mais conservé pour la compatibilité.

X-Content-Type-Options.

Valeur unique : nosniff. Empêche le navigateur de deviner le type MIME des ressources. Sans cet en-tête, un fichier JavaScript déguisé en image pourrait être exécuté. Configuration triviale, à ne jamais oublier.

Referrer-Policy.

Contrôle ce que le navigateur transmet dans l'en-tête Referer aux sites de destination des liens. Sans cette politique, l'URL complète de la page courante (incluant les paramètres) peut fuir vers les sites tiers. Valeur recommandée : strict-origin-when-cross-origin — transmet l'origine pour les liens cross-domain mais pas le chemin complet.

Permissions-Policy.

Ancien Feature-Policy. Désactive les fonctionnalités du navigateur que le site n'a pas besoin d'utiliser : géolocalisation, microphone, caméra, capteurs. Posture par défaut recommandée pour un site de PME : tout désactiver, puis activer au cas par cas si nécessaire.

Permissions-Policy: geolocation=(), microphone=(), camera=()

Outil de vérification : Mozilla Observatory (observatory.mozilla.org) publie une note A+ à F sur la qualité globale des en-têtes HTTP. La version 2 de l'outil, lancée en 2024 sur le domaine observatory-api.mdn.mozilla.net, est désormais celle utilisée par les contrôles qualité.

À retenir

Les six en-têtes (HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy) couvrent l'essentiel des vecteurs d'attaque navigateur. Une PME qui les configure correctement passe d'un grade D ou F à un grade A à Mozilla Observatory en quelques heures de travail.

Fichiers à protéger et version du CMS à masquer

Constat : au-delà des en-têtes, certains fichiers ou endpoints exposés publiquement créent des risques. Leur présence ou leur accessibilité doit être vérifiée et corrigée.

Fichiers sensibles à ne jamais exposer :

  • /.env — fichier de configuration souvent utilisé par les frameworks PHP, Node.js, Python. Contient des clés API, mots de passe de base de données, secrets. Doit retourner 403 ou 404.
  • /.git/HEAD et tout le dossier .git/ — si le site est versionné avec Git et que le dossier est exposé, un attaquant peut télécharger l'historique complet du code source.
  • /wp-config.php.bak, /wp-config.php~, /wp-config.bak — sauvegardes accidentelles du fichier de configuration WordPress contenant les identifiants de la base.
  • /wp-content/debug.log — fichier de logs WordPress qui peut contenir des informations sensibles si le mode debug a été activé.
  • Tout fichier .bak, .old, .orig, .swp — sauvegardes accidentelles laissées par les éditeurs ou les processus de déploiement.

Version du CMS à masquer : de nombreux CMS exposent leur version dans des fichiers ou en-têtes par défaut. Pour WordPress, par exemple : la balise meta generator, les fichiers readme.html et license.txt, l'en-tête X-Powered-By. Connaître la version exacte permet à un attaquant de cibler des CVE publiques. Toutes ces sources doivent être supprimées ou bloquées.

Endpoints WordPress spécifiques à examiner :

  • /wp-login.php — page de connexion. Inévitablement accessible, mais peut être protégée par limitation de tentatives, MFA, ou restriction par IP.
  • /xmlrpc.php — endpoint XML-RPC. Souvent inutile aujourd'hui mais souvent activé par défaut. À désactiver si aucun service ne l'utilise.
  • /wp-json/wp/v2/users — endpoint REST qui peut exposer la liste des utilisateurs. À bloquer côté thème ou plugin.
  • /?author=1 — redirige vers /author/<slug>/ et révèle le nom d'utilisateur du premier compte. Vecteur d'énumération à neutraliser.

Vérification : simples requêtes HTTP HEAD ou GET sur ces chemins. Un statut 200 indique une exposition à corriger ; un statut 403 ou 404 indique que la protection est en place.

À retenir

La sécurité de surface ne se limite pas aux en-têtes HTTP. Les fichiers laissés accessibles par accident et la version du CMS exposée sont autant de vecteurs faciles à exploiter. La vérification de ces points fait partie systématique d'un contrôle qualité de site web sérieux.

Articulation avec OWASP, Loi 25 et erreurs fréquentes

Convergence : la sécurité de surface couvre principalement les catégories A02 (Cryptographic Failures) et A05 (Security Misconfiguration) de l'OWASP Top 10. Elle contribue directement aux mesures de sécurité raisonnables exigées par l'article 10 de la Loi 25.

Articulation OWASP ↔ sécurité de surface :

  • HTTPS et TLS → A02:2021 Cryptographic Failures.
  • HSTS → A02:2021 (renforcement HTTPS) + A05:2021 (en-tête correctement configuré).
  • CSP, X-Frame-Options, Referrer-Policy, Permissions-Policy, X-Content-Type-Options → A05:2021 Security Misconfiguration.
  • Fichiers sensibles exposés → A05:2021 Security Misconfiguration.
  • Version du CMS exposée → A05:2021 et A06:2021 Vulnerable and Outdated Components.

Lien avec la Loi 25 :

  • Article 10 (mesures de sécurité raisonnables) → la sécurité de surface est l'une des dimensions les plus visibles. Un site sans HTTPS, sans en-têtes de sécurité ou avec des fichiers de configuration exposés ne peut pas être considéré comme protégeant adéquatement les renseignements personnels.
  • Une formulaire de contact qui collecte des renseignements personnels sur un site sans HTTPS contrevient au principe de protection raisonnable, peu importe le contenu de la politique de confidentialité.

Erreurs fréquentes en PME :

  • ❌ HTTPS partiel ou pages mixtes. Site principal en HTTPS mais ressources (images, scripts) chargées en HTTP. Le navigateur affiche un cadenas brisé.
  • ❌ HSTS absent. Le site répond en HTTPS mais sans HSTS, un attaquant peut intercepter la première connexion.
  • ❌ CSP absente ou en Report-Only indéfiniment. Une CSP en mode rapport seulement n'offre aucune protection effective. Le passage à l'application est nécessaire.
  • ❌ readme.html et license.txt accessibles. Ces fichiers exposent la version du CMS. À bloquer via .htaccess ou équivalent serveur.
  • ❌ Certificat TLS expiré ou auto-signé. Le site fonctionne mais les navigateurs affichent un avertissement. La majorité des hébergeurs offrent désormais Let's Encrypt automatiquement — il suffit de l'activer.
  • ❌ Énumération d'utilisateurs WordPress non bloquée. /?author=1 redirige vers le slug du compte administrateur, révélant le nom d'utilisateur.
  • ❌ Configuration laissée par défaut sans audit. Beaucoup de plateformes ont des paramètres « out of the box » qui ne sont pas optimaux. Sans audit après déploiement, les écarts persistent.

L'erreur structurelle la plus fréquente : croire que la sécurité de surface est l'affaire de l'hébergeur uniquement. En pratique, l'hébergeur fournit l'infrastructure (TLS, certificat) mais la majorité des en-têtes HTTP sont configurés au niveau du serveur web ou du CMS — donc à la charge de l'organisation ou de son équipe TI.

À retenir

La sécurité de surface se mesure en quelques minutes (Mozilla Observatory + SSL Labs) et se corrige en quelques heures. C'est l'investissement avec le meilleur ratio effort/protection en cybersécurité web. Pour une PME québécoise, atteindre un grade A+ sur les deux outils est l'objectif réaliste.

En résumé

La sécurité de surface d'un site web couvre ce qu'un visiteur ou un outil d'analyse externe peut observer sans connexion : configuration TLS (HTTPS, certificat valide, TLS 1.2+ avec chiffrement fort), en-têtes HTTP de sécurité (Strict-Transport-Security/HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy), fichiers à protéger (.env, .git/, sauvegardes wp-config) et masquage de la version du CMS. Cette couche correspond aux catégories A02 et A05 de l'OWASP Top 10 et contribue directement aux mesures de sécurité raisonnables exigées par l'article 10 de la Loi 25. Outils de vérification : SSL Labs pour TLS, Mozilla Observatory v2 pour les en-têtes HTTP. Pour une PME québécoise, atteindre un grade A+ sur les deux outils est l'objectif réaliste, accessible en quelques heures de travail.

Réponse rapide

Quels en-têtes prioriser? Strict-Transport-Security (HSTS), Content-Security-Policy (CSP appliquée, pas Report-Only), X-Frame-Options et Referrer-Policy. Les six en-têtes ensemble passent un site de grade F à grade A à Mozilla Observatory.

Comment vérifier rapidement? SSL Labs (ssllabs.com/ssltest) pour le TLS et Mozilla Observatory pour les en-têtes. Deux minutes par outil, verdict immédiat avec recommandations précises.

Vérifier la sécurité de surface de votre site?

Pour les organisations qui veulent valider que leur site couvre les fondations de sécurité (HTTPS, en-têtes HTTP, fichiers protégés, version masquée), un contrôle qualité de site web fournit un verdict structuré accompagné d'un plan d'action priorisé. Réservez un appel d'orientation gratuit pour discuter de votre situation.

Planifier un appel d'orientation →