Skip to main content
← Retour au blog

Guide SEO Étape 7 : Sécurité — La Base Attendue par Google en 2026

·14 min de lecture·par LANGR SEO

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 :

  1. Le certificat expire sans préavis — Configurez une surveillance (Étape 6) au minimum 30 jours avant l'expiration
  2. Chaîne de certificat incomplète — Le serveur doit envoyer les certificats intermédiaires, pas seulement le certificat final
  3. Contenu mixte — La page HTTPS charge des ressources HTTP (images, scripts, feuilles de style)
  4. Boucles de redirection — Cycles HTTP → HTTPS → HTTP causés par un CDN/proxy mal configuré
  5. 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:

  1. Commencez par Content-Security-Policy-Report-Only (journalise les violations sans bloquer)
  2. Surveillez les rapports pendant 1 à 2 semaines
  3. Mettez sur liste blanche les sources légitimes
  4. Passez en mode d'application
  5. 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 :

  1. Certificat HTTPS valide
  2. Rediriger tout HTTP vers HTTPS (y compris les sous-domaines)
  3. En-tête HSTS avec max-age >= 31536000
  4. L'en-tête HSTS inclut includeSubDomains
  5. L'en-tête HSTS inclut preload
  6. 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 :

  1. Ouvrez Chrome DevTools → Console
  2. Recherchez les avertissements "Contenu mixte"
  3. 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 :

  1. 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>
  1. Restrictions CSP : Autorisez uniquement les scripts provenant de domaines connus
  2. Iframes sandboxées : Isolez les widgets tiers
  3. Audits réguliers : Révision trimestrielle de toutes les ressources externes
  4. Surveillance : Alerte sur les nouveaux domaines externes apparaissant dans vos pages

Gains rapides : Dressez la liste de chaque balise