Guide SEO Étape 7 : Sécurité

Cela constitue l'étape 7 du Guide SEO en 13 étapes. La sécurité ne concerne pas seulement la protection des utilisateurs — elle a un impact direct sur vos classements de recherche. Google utilise HTTPS comme signal de classement depuis 2014, et les attentes n'ont fait qu'augmenter.

La plupart des propriétaires de sites pensent à la sécurité de manière binaire : "Nous avons SSL, donc nous sommes sécurisés." En réalité, Google évalue des dizaines de signaux de sécurité. Les sites avec des en-têtes de sécurité appropriés, des certificats valides et sans contenu mixte surpassent les sites avec seulement un certificat SSL de base — toutes choses étant égales par ailleurs.

La bonne nouvelle : la plupart des corrections de sécurité sont des configurations uniques. Configurez-les une fois, et elles protègent vos classements de manière permanente.

Configuration SSL

SSL (techniquement TLS) crypte la connexion entre votre serveur et vos visiteurs. Depuis 2014, Google a explicitement confirmé HTTPS comme signal de classement. En 2026, ne pas avoir HTTPS n'est pas seulement un problème de classement — Chrome marque les sites HTTP comme "Non sécurisé" dans la barre d'adresse, détruisant la confiance des utilisateurs.

Exigences pour un SSL approprié :

Exigence	Pourquoi	Comment Vérifier
Certificat valide	Expiré = avertissement du navigateur = utilisateurs rebondis	Vérifiez la date d'expiration
Chaîne complète	Les chaînes incomplètes échouent sur certains appareils	Test SSL Labs
TLS 1.2+	Les versions plus anciennes ont des vulnérabilités connues	Test SSL Labs
Pas de SHA-1	Obsolète, les navigateurs le rejettent	Détails du certificat
Couverture SAN	www et non-www doivent être couverts	Détails du certificat
Renouvellement automatique	Évite les désastres d'expiration	Let's Encrypt / configuration du fournisseur

Scoring SSL :

100% = Certificat valide + Chaîne complète + TLS 1.3 + Chiffre fort + Renouvellement automatique
  0% = Certificat expiré ou manquant

Erreurs courantes SSL :

Le certificat expire sans préavis — Configurez une surveillance (Étape 6) au minimum 30 jours avant l'expiration
Chaîne de certificat incomplète — Le serveur doit envoyer les certificats intermédiaires, pas seulement le certificat final
Contenu mixte — La page HTTPS charge des ressources HTTP (images, scripts, feuilles de style)
Boucles de redirection — Cycles HTTP → HTTPS → HTTP causés par un CDN/proxy mal configuré
Mauvais alignement entre non-www et www — Le certificat couvre l'un mais pas l'autre

Gains rapides : Faites passer votre domaine par SSL Labs (ssllabs.com/ssltest). Tout résultat en dessous d'un classement "A" a des problèmes exploitables. La plupart des fournisseurs d'hébergement corrigent cela en un clic.

En-têtes de Sécurité

Les en-têtes de sécurité sont des en-têtes de réponse HTTP qui demandent aux navigateurs comment se comporter lors du chargement de votre site. Ils préviennent des catégories entières d'attaques — et les crawlers de Google les vérifient.

Les en-têtes de sécurité essentiels :

Content-Security-Policy (CSP)

CSP est l'en-tête de sécurité le plus puissant. Il indique aux navigateurs exactement quelles ressources (scripts, styles, images, polices) sont autorisées à charger sur vos pages.

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' https://fonts.gstatic.com; connect-src 'self' https://api.example.com; frame-ancestors 'none';

Ce que CSP empêche :

Attaques de scripting inter-sites (XSS)
Attaques par injection de données
Clickjacking (via frame-ancestors)
Exécution de scripts non autorisés (cryptomineurs, injecteurs de publicités)

Stratégie de déploiement CS:

Commencez par Content-Security-Policy-Report-Only (journalise les violations sans bloquer)
Surveillez les rapports pendant 1 à 2 semaines
Mettez sur liste blanche les sources légitimes
Passez en mode d'application
Ajoutez report-uri ou report-to pour le journal des violations continu

X-Frame-Options

Empêche votre site d'être intégré dans des iframes sur d'autres domaines (protection contre le clickjacking).

X-Frame-Options: DENY

Ou si vous devez autoriser les cadres de même origine :

X-Frame-Options: SAMEORIGIN

X-Content-Type-Options

Empêche les navigateurs de faire de la détection de type MIME (interprétation des fichiers comme différents types de ceux déclarés).

X-Content-Type-Options: nosniff

Cette ligne unique empêche les attaques où un fichier .jpg contient un JavaScript caché que le navigateur pourrait exécuter.

Referrer-Policy

Contrôle la quantité d'informations sur le référent envoyées lorsque les utilisateurs cliquent sur des liens depuis votre site.

Referrer-Policy: strict-origin-when-cross-origin

Cela envoie l'URL complète pour les requêtes de même origine mais seulement l'origine (domaine) pour les requêtes inter-domaines. Équilibre les besoins d'analytique avec la confidentialité.

Permissions-Policy

Contrôle quelles fonctionnalités du navigateur (caméra, microphone, géolocalisation, etc.) peuvent être utilisées sur votre site.

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

Désactiver les fonctionnalités que vous n'utilisez empêche les scripts tiers de les abuser.

Exemple de mise en œuvre de l'en-tête (Next.js) :

// next.config.js
module.exports = {
  async headers() {
    return [{
      source: '/(.*)',
      headers: [
        { key: 'X-Content-Type-Options', value: 'nosniff' },
        { key: 'X-Frame-Options', value: 'SAMEORIGIN' },
        { key: 'Referrer-Policy', value: 'strict-origin-when-cross-origin' },
        { key: 'Permissions-Policy', value: 'camera=(), microphone=(), geolocation=()' },
        { key: 'Strict-Transport-Security', value: 'max-age=31536000; includeSubDomains; preload' },
      ]
    }]
  }
}

Mise en œuvre de l'en-tête (Apache .htaccess) :

Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

Mise en œuvre de l'en-tête (Nginx) :

add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Gains rapides : Ajoutez tous les 5 en-têtes ci-dessus à votre configuration serveur. Cela prend 5 minutes et améliore immédiatement votre posture de sécurité dans tout outil de scan.

HSTS Preload

HTTP Strict Transport Security (HSTS) indique aux navigateurs d'utiliser toujours HTTPS pour votre domaine — même avant la première requête. Sans HSTS, la première visite sur votre site peut encore utiliser HTTP (vulnérable à l'interception) avant que la redirection vers HTTPS ne se produise.

En-tête HSTS :

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

Les trois directives :

Directive	Signification
`max-age=31536000`	Se souvenir de cela pendant 1 an (en secondes)
`includeSubDomains`	S'applique également à tous les sous-domaines
`preload`	Demande l'inclusion dans les listes de préchargement des navigateurs

Liste de préchargement HSTS :

La protection HSTS ultime. Les navigateurs livrent avec une liste intégrée de domaines qui doivent toujours utiliser HTTPS. Soumettre votre domaine à hstspreload.org signifie :

Les visiteurs de première fois obtiennent immédiatement HTTPS (pas de redirection HTTP → HTTPS)
Impossible pour les attaquants de rétrograder les connexions
Permanent (difficile à supprimer une fois soumis)

Exigences pour le préchargement HSTS :

Certificat HTTPS valide
Rediriger tout HTTP vers HTTPS (y compris les sous-domaines)
En-tête HSTS avec max-age >= 31536000
L'en-tête HSTS inclut includeSubDomains
L'en-tête HSTS inclut preload
Tous les sous-domaines doivent prendre en charge HTTPS

Avertissement : Soumettez au préchargement uniquement si TOUS vos sous-domaines prennent en charge HTTPS. La directive includeSubDomains signifie que tout sous-domaine uniquement HTTP deviendra inaccessible.

Gains rapides : Si vous avez déjà HTTPS sur tous les sous-domaines, ajoutez l'en-tête complet HSTS et soumettez-le à hstspreload.org. Le traitement prend quelques semaines mais la protection est permanente.

Scan de Vulnérabilités

Le scan de vulnérabilités automatisé identifie les problèmes de sécurité connus dans votre stack avant que des attaquants ne les exploitent.

Ce que le scan de vulnérabilités vérifie :

Logiciels obsolètes : WordPress, plugins, bibliothèques JavaScript avec des CVE connus
Fichiers exposés : .env, .git, wp-config.php, dumps de base de données
Fuites d'informations : En-têtes de version serveur, mode débogage, traces de pile
Identifiants par défaut : Pages admin sans authentification, mots de passe par défaut
Ports/services ouverts : Services inutiles exposés à Internet
Points d'injection : Formulaires sans protection CSRF, entrées non validées

Vulnérabilités courantes par plate-forme :

Plate-forme	Principale Vulnérabilité	Correction
WordPress	Plugins obsolètes	Auto-mise à jour + WAF
Shopify	Permissions d'applications tierces	Audit de la liste d'applications trimestriel
Next.js	Routes API exposées	Middleware d'authentification + limitation de débit
Sites statiques	Mauvaise configuration CDN	Révision des règles de cache
Personnalisé	Injection SQL	Requêtes paramétrées

Fréquence de scan :

Quotidien : Scan de surface automatisé (SSL, en-têtes, fichiers exposés)
Hebdomadaire : Vérification des vulnérabilités de dépendances (npm audit, scanner de plugins WordPress)
Mensuel : Scan approfondi avec test authentifié
Après chaque déploiement : Vérification de régression

Gains rapides : Exécutez npm audit (Node.js) ou vérifiez votre liste de plugins CMS pour les composants obsolètes. Corrigez immédiatement les problèmes critiques/hauts.

Contenu Mixte

Le contenu mixte se produit lorsqu'une page HTTPS charge des ressources (images, scripts, feuilles de style, iframes) via HTTP. Cela rompt partiellement le cryptage et déclenche des avertissements des navigateurs.

Types de contenu mixte :

Type	Sévérité	Exemple	Comportement du Navigateur
Actif	Élevé	Script HTTP, iframe, CSS	Bloqué par défaut
Passif	Moyen	Image HTTP, vidéo, audio	Chargé avec avertissement

Le contenu mixte actif est bloqué par les navigateurs modernes — ce qui signifie que vos scripts et styles ne se chargeront tout simplement pas. Le contenu mixte passif se charge mais affiche des avertissements de sécurité.

Trouver du contenu mixte :

Ouvrez Chrome DevTools → Console
Recherchez les avertissements "Contenu mixte"
Alternativement, scannez avec un crawler (Screaming Frog, LANGR)

Sources courantes de contenu mixte :

URLs http:// codées en dur dans le contenu (articles de blog, descriptions de produits)
Widgets tiers chargeant des ressources HTTP
Contenu intégré (anciens embeds YouTube, widgets de médias sociaux)
CSS background-image avec URLs HTTP
Polices chargées via HTTP

Correction du contenu mixte :

<!-- Mauvais -->
<img src="http://example.com/image.jpg" />

<!-- Bon -->
<img src="https://example.com/image.jpg" />

<!-- Meilleur (relatif au protocole, s'adapte au protocole de la page) -->
<img src="//example.com/image.jpg" />

Correction de base de données (WordPress) :

UPDATE wp_posts SET post_content = REPLACE(post_content, 'http://yourdomain.com', 'https://yourdomain.com');
UPDATE wp_postmeta SET meta_value = REPLACE(meta_value, 'http://yourdomain.com', 'https://yourdomain.com');

Gains rapides : Ouvrez votre page d'accueil dans Chrome, appuyez sur F12, vérifiez l'onglet Console pour des avertissements de contenu mixte. Corrigez ceux qui apparaissent — ceux-ci sont directement visibles par Google.

Risques des Scripts Tiers

Chaque script externe que vous chargez est une responsabilité potentielle en matière de sécurité (et de performance). Les scripts tiers peuvent :

Être compromis (attaques par chaîne d'approvisionnement)
Suivre vos utilisateurs sans consentement (violation du RGPD)
Ralentir votre site (bloqueur de rendu, latence réseau)
Ruiner la fonctionnalité (mises à jour de version, pannes)
Injecter du contenu indésirable (scripts publicitaires défectueux)

Audit de vos scripts tiers :

Script	Nécessaire ?	Niveau de Risque	Alternative
Google Analytics	Souvent oui	Faible	Suivi côté serveur
Widgets de chat	Peut-être	Moyen	Solutions auto-hébergées
Boutons de partage social	Rarement	Moyen	Liens de partage statiques
Testing A/B	Parfois	Élevé	Testing côté serveur
Pixels de reciblage	Décision d'entreprise	Élevé	Données de première partie
CDNs de polices	Pratique	Faible	Polices auto-hébergées

Atténuation des risques pour les scripts tiers essentiels :

Intégrité des sous-ressources (SRI) : Vérification par hachage empêche le chargement de scripts altérés

<script src="https://cdn.example.com/lib.js"
        integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxAE+sO0..."
        crossorigin="anonymous"></script>

Restrictions CSP : Autorisez uniquement les scripts provenant de domaines connus
Iframes sandboxées : Isolez les widgets tiers
Audits réguliers : Révision trimestrielle de toutes les ressources externes
Surveillance : Alerte sur les nouveaux domaines externes apparaissant dans vos pages

Gains rapides : Dressez la liste de chaque balise