Sécurité site web HTTPS : que faut-il vérifier vraiment ?

HTTPS et certificat SSL : quelle différence ?

HTTPS est le protocole utilisé pour charger une page web avec une connexion chiffrée. Le certificat SSL est le fichier numérique qui authentifie le domaine et permet d’établir cette connexion, même si le protocole moderne utilisé est TLS, pour Transport Layer Security.

Le terme SSL reste courant dans les offres d’hébergement, mais les anciennes versions de SSL ne doivent plus être utilisées. La CNIL recommande de mettre en œuvre TLS avec les versions récentes et de rendre son utilisation obligatoire sur les pages d’authentification ou qui transmettent des données personnelles.

Comment fonctionne le chiffrement TLS ?

TLS commence par un échange entre le navigateur et le serveur. Le serveur présente son certificat, le navigateur vérifie l’autorité qui l’a signé et les deux parties négocient ensuite des clés temporaires pour chiffrer la session.

Une personne qui intercepte le trafic peut alors voir qu’une connexion existe, mais elle ne doit pas pouvoir lire le mot de passe, le contenu d’un formulaire ou le numéro de commande. Le chiffrement ne corrige toutefois pas une faille présente dans votre code ou dans votre extension WordPress.

Que garantit réellement le cadenas dans le navigateur ?

Le cadenas indique principalement que la connexion avec le domaine demandé est chiffrée et que le certificat est accepté par le navigateur. Il ne prouve pas que l’entreprise derrière le site est honnête, que le serveur est à jour ou que la page ne contient pas de code malveillant.

Vérifiez le domaine affiché dans la barre d’adresse, surtout avant de saisir un identifiant. Un faux site peut lui aussi utiliser HTTPS, car obtenir un certificat pour un domaine contrôlé par un attaquant ne rend pas ce domaine légitime.

Pourquoi sécuriser son site en HTTPS ?

Protéger les données personnelles et les identifiants

Le HTTPS réduit le risque d’interception des données échangées sur un réseau Wi-Fi public ou compromis. Il protège notamment les identifiants, les adresses, les messages envoyés par formulaire et les informations affichées dans un espace client.

La CNIL rappelle que tout site doit garantir son identité aux terminaux qui s’y connectent et la confidentialité des informations transmises. Pour un site traitant des données personnelles, le HTTPS doit donc couvrir les pages de connexion, d’inscription, de contact et de gestion du compte, pas seulement la page d’accueil.

Sécuriser les paiements et les transactions en ligne

Le HTTPS chiffre le trajet entre le navigateur et votre site, mais il ne rend pas automatiquement un paiement conforme ou sûr. Pour les transactions en ligne, utilisez une page de paiement fournie par un prestataire reconnu, avec une authentification et une gestion des fraudes adaptées.

Ne transmettez jamais un numéro de carte bancaire dans une URL. La CNIL déconseille aussi de placer une base de données directement accessible depuis Internet et de faire transiter des mots de passe dans une adresse web.

Renforcer la confiance et le référencement du site

Les navigateurs signalent plus clairement les pages non chiffrées lorsque des formulaires ou des champs de mot de passe sont présents. HTTPS évite ce signal négatif et empêche aussi certains fournisseurs d’accès ou réseaux intermédiaires de modifier le contenu en transit.

• Déclarez une seule version canonique de votre site, par exemple https://www.exemple.fr.
• Mettez à jour les liens internes, le fichier robots.txt, le sitemap XML et les propriétés de suivi.
• Contrôlez les redirections avec curl -I http://exemple.fr et vérifiez le code HTTP renvoyé.

HTTPS constitue un signal technique utile pour le référencement, mais la qualité du contenu, les performances et l’accessibilité restent déterminantes. Pour comprendre le rôle d’un fichier sitemap, consultez notre article sur le sitemap et l’indexation de Google.

Choisir le bon certificat SSL/TLS

Certificat DV, OV ou EV : lequel choisir ?

Un certificat DV, ou Domain Validation, vérifie que vous contrôlez le nom de domaine. Il convient à la plupart des sites vitrines, blogs et projets WordPress qui n’ont pas besoin d’afficher une validation renforcée de l’organisation.

Un certificat OV, ou Organization Validation, ajoute une vérification de l’organisation. Un certificat EV, ou Extended Validation, impose des contrôles plus poussés, mais les navigateurs n’affichent plus systématiquement une différence visuelle évidente dans la barre d’adresse.

Pour choisir, partez du risque et des exigences de votre activité, plutôt que du seul label commercial. Une boutique doit surtout sécuriser son hébergement, son code, ses comptes et son prestataire de paiement.

Certificat gratuit ou payant : quelles différences ?

Un certificat gratuit peut fournir le chiffrement et l’authentification du domaine nécessaires à un site courant. Les certificats payants peuvent inclure une validation d’organisation, une assistance, une garantie contractuelle ou une gestion centralisée, selon l’autorité de certification.

Le prix, la durée de validité et les conditions de renouvellement changent selon le fournisseur et l’hébergement. Vérifiez ces informations au moment de l’achat, car une offre présentée comme gratuite peut facturer l’installation, l’adresse IP dédiée ou le renouvellement automatique.

Certificat pour un domaine, plusieurs domaines ou sous-domaines ?

Un certificat simple couvre généralement un nom précis, comme www.exemple.fr. Un certificat wildcard couvre un domaine et ses sous-domaines correspondants, par exemple *.exemple.fr, tandis qu’un certificat multi-domaines regroupe plusieurs noms distincts.

Recensez les domaines réellement utilisés avant de choisir. Un certificat wildcard ne couvre pas automatiquement exemple.com si vous l’avez acheté pour exemple.fr, et il demande une gestion attentive de la clé privée.

Installer un certificat SSL et activer HTTPS

Obtenir et installer le certificat sur son hébergement

La méthode la plus simple consiste à activer TLS depuis le panneau de votre hébergeur. Beaucoup d’offres proposent une émission et un renouvellement automatiques, mais vous devez confirmer que le certificat couvre la version avec et sans www.

1. Ajoutez le domaine dans l’espace d’hébergement et vérifiez que son DNS, ou système qui associe un nom à une adresse IP, pointe vers le bon serveur.
2. Activez le certificat dans la rubrique SSL/TLS, puis attendez la propagation DNS si le domaine vient d’être déplacé.
3. Testez https://exemple.fr, https://www.exemple.fr et les pages contenant des formulaires.

Sur un serveur Apache, la configuration peut utiliser un VirtualHost sur le port 443. Sur Nginx, le bloc HTTPS doit référencer le certificat et sa clé privée, qui ne doivent jamais être placés dans un dépôt public.

Rediriger automatiquement HTTP vers HTTPS

Une redirection permanente doit envoyer chaque URL HTTP vers son équivalent HTTPS. Avec Apache, vous pouvez utiliser une règle dans le fichier .htaccess après avoir vérifié la configuration de votre hébergeur :

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Testez les anciennes URL une par une, car une redirection mal configurée peut créer une boucle ou envoyer toutes les pages vers la page d’accueil. Conservez des redirections directes pour éviter plusieurs étapes successives.

Vérifier la configuration avec un outil de test SSL

Examinez la date d’expiration, le nom couvert, la chaîne de certification et les protocoles acceptés. La CNIL conseille également de limiter les ports ouverts : pour un serveur qui ne fournit que HTTPS, le port entrant 443 doit être nécessaire, tandis que les autres ports doivent être bloqués selon les besoins réels.

Un outil comme le vérificateur de sécurité de site web Sitechecker peut contrôler l’URL, rechercher une présence dans les données de navigation sécurisée de Google et signaler des problèmes techniques. Utilisez ce type de rapport comme un contrôle complémentaire, pas comme une preuve d’absence de vulnérabilité.

Éviter les erreurs fréquentes après le passage en HTTPS

Corriger le contenu mixte

Le contenu mixte apparaît lorsqu’une page HTTPS charge encore une image, une feuille CSS, un script ou une police en HTTP. Le navigateur peut bloquer la ressource ou afficher un avertissement, ce qui dégrade à la fois l’affichage et la sécurité.

Recherchez les URL commençant par http:// dans la base de données, les fichiers du thème et les réglages des extensions. Dans WordPress, mettez à jour les adresses dans Réglages, Général, puis utilisez un outil de recherche-remplacement après une sauvegarde.

Mettre à jour les liens, ressources et URL canoniques

Remplacez les liens internes HTTP par des liens HTTPS et contrôlez les attributs canonical, les données structurées, les images Open Graph et les scripts tiers. Une ressource externe restée en HTTP peut continuer à produire du contenu mixte même si toutes vos pages sont redirigées.

Après une migration, vérifiez aussi les réglages d’Analytics, les webhooks et les URL de retour de paiement. Pour un projet marchand, notre dossier sur le choix d’un hébergement e-commerce couvre les contraintes liées aux paiements, aux sauvegardes et aux performances.

Renouveler le certificat avant son expiration

Un certificat expiré provoque une alerte du navigateur et peut rendre le site inaccessible pour une partie des visiteurs. Activez le renouvellement automatique lorsque l’hébergeur le permet et configurez une alerte au moins 30 jours avant l’échéance.

Contrôlez le renouvellement sur un environnement de test avant de modifier un certificat manuellement. Les prix, les périodes de validité et les méthodes d’émission évoluent, donc vérifiez les conditions actuelles auprès de votre hébergeur.

HTTPS suffit-il à sécuriser un site web ?

Mettre à jour le CMS, les extensions et le serveur

HTTPS ne corrige ni une extension vulnérable ni un mot de passe volé. Mettez à jour le CMS, les extensions, le thème, PHP et le système du serveur après avoir vérifié la compatibilité et réalisé une sauvegarde.

La CNIL recommande de limiter le nombre de composants, d’effectuer une veille et de tester régulièrement les applications critiques. Supprimez les extensions désactivées dont vous n’avez plus besoin, car un fichier présent sur le serveur peut encore devenir une surface d’attaque.

Renforcer les mots de passe et activer la double authentification

Utilisez un mot de passe différent pour chaque compte et stockez-le dans un gestionnaire comme Bitwarden ou 1Password. Activez l’authentification multifacteur, qui demande une seconde preuve après le mot de passe, pour l’administration WordPress, l’hébergement et la messagerie.

Limitez les tentatives de connexion et désactivez les comptes inutilisés. Une protection ne constitue jamais une garantie absolue contre le piratage, mais elle réduit l’impact d’un mot de passe réutilisé ou divulgué.

Limiter les droits des comptes utilisateurs

Attribuez à chaque utilisateur le rôle minimal nécessaire. Dans WordPress, un rédacteur n’a pas besoin du rôle administrateur pour publier un article, et un prestataire temporaire doit perdre son accès dès la fin de sa mission.

La CNIL déconseille les comptes partagés, car ils empêchent d’attribuer précisément une action à une personne. Conservez des journaux d’administration et utilisez un compte distinct pour les tâches quotidiennes.

Sauvegarder régulièrement les données

Une sauvegarde indépendante permet de restaurer le site après une suppression, une panne ou une compromission. Conservez plusieurs générations dans un emplacement séparé du serveur principal et testez réellement la restauration.

La fréquence dépend du volume de changements : une boutique active peut nécessiter des sauvegardes quotidiennes ou plus fréquentes, tandis qu’un site vitrine peu modifié peut suivre un calendrier moins serré. Consultez notre comparatif sur les types de sauvegarde pour un site internet.

Sécuriser les paiements et les données clients

Utiliser une solution de paiement conforme et externalisée

Confiez la saisie des données bancaires à un prestataire de paiement spécialisé lorsque votre activité ne justifie pas une infrastructure dédiée. Votre site redirige alors le client vers une page de paiement ou utilise des champs hébergés par le prestataire, ce qui réduit les données sensibles présentes sur votre serveur.

Vérifiez les URL de retour, les notifications serveur à serveur et la validation de la signature des événements. Un paiement ne doit jamais être considéré comme confirmé uniquement parce qu’un visiteur revient sur une page de succès.

Ne pas stocker les données bancaires inutiles

Ne conservez pas de numéro de carte bancaire ou de code de sécurité si votre service n’en a pas besoin. Stockez uniquement les informations nécessaires au fonctionnement documenté du compte et définissez une durée de conservation adaptée.

Chiffrez les données sensibles au repos lorsque leur conservation est justifiée et restreignez l’accès à la base. Une base privée derrière un pare-feu reste préférable à une base exposée directement sur Internet.

Protéger les cookies et les scripts tiers

Ajoutez les attributs Secure et HttpOnly aux cookies de session, puis utilisez SameSite=Lax ou une valeur plus restrictive lorsque le service le permet. Secure limite l’envoi au HTTPS et HttpOnly empêche l’accès direct au cookie depuis JavaScript.

Inventoriez les scripts tiers, comme les pixels publicitaires, les widgets et les outils de mesure. Pour les cookies non nécessaires au service, la CNIL demande de recueillir le consentement après information et avant leur dépôt.

Protéger le site contre les attaques courantes

Pare-feu applicatif, anti-DDoS et protection contre les bots

Un pare-feu applicatif web, ou WAF, filtre certaines requêtes malveillantes avant qu’elles atteignent votre application. Une protection anti-DDoS absorbe ou limite un afflux massif de trafic, tandis qu’un mécanisme anti-bots peut ralentir les créations de comptes et les tentatives automatisées.

Ces services doivent être configurés selon votre trafic réel. Un filtrage trop agressif peut bloquer des clients, des moteurs de recherche ou des webhooks légitimes.

Se prémunir contre les injections SQL et les attaques XSS

Une injection SQL tente de modifier une requête vers la base de données avec une entrée utilisateur mal filtrée. Utilisez des requêtes paramétrées, validez les données côté serveur et n’affichez jamais directement une valeur reçue dans un formulaire.

Une attaque XSS, pour Cross-Site Scripting, injecte du code dans une page consultée par d’autres visiteurs. Échappez les sorties HTML, appliquez une politique de sécurité du contenu adaptée et maintenez vos extensions à jour.

Surveiller les journaux et détecter les activités anormales

Les journaux du serveur et du CMS peuvent révéler des connexions répétées, des fichiers modifiés ou des requêtes inhabituelles. Conservez-les assez longtemps pour enquêter, limitez leur accès et synchronisez l’heure des systèmes.

La CNIL cite notamment OWASP ZAP, Nmap et Nikto parmi les outils pouvant contribuer à détecter des vulnérabilités, avec des tests réguliers et avant la mise en production d’une nouvelle version. Lancez ces scans uniquement sur vos propres systèmes ou avec une autorisation écrite.

Comment vérifier qu’un site est bien sécurisé en HTTPS ?

Contrôler le certificat et sa date d’expiration

Ouvrez le certificat depuis les informations de connexion du navigateur et vérifiez le domaine, l’autorité émettrice et la date de fin de validité. Répétez le contrôle sur les sous-domaines réellement utilisés, car un certificat valide sur www ne couvre pas nécessairement un autre sous-domaine.

Vérifier les redirections et l’absence de contenu mixte

Testez les variantes HTTP, HTTPS, avec www et sans www. La version retenue doit répondre normalement, les autres doivent rediriger vers elle avec un code 301 ou une configuration équivalente.

Dans les outils de développement du navigateur, ouvrez l’onglet Console et recherchez les alertes de contenu mixte. Inspectez aussi l’onglet Réseau pour repérer les ressources chargées en HTTP.

Réaliser régulièrement un audit de sécurité

Un audit associe un contrôle du certificat, une analyse des dépendances, une revue des comptes, un scan des vulnérabilités et un test de restauration. Planifiez-le après chaque changement important, puis à intervalles réguliers selon le niveau de risque.

Le vérificateur de Sitechecker peut signaler une inscription dans les données de navigation sécurisée de Google et proposer un audit de plus de 300 problèmes techniques selon sa page de présentation. Ce résultat doit être complété par les journaux de votre hébergeur et une revue humaine du code.

Que faire en cas de certificat expiré ou de site compromis ?

En cas de certificat expiré, renouvelez-le depuis l’hébergeur, vérifiez la chaîne de certification et testez les domaines concernés dans plusieurs navigateurs. Si le renouvellement échoue, contrôlez le DNS, les permissions de fichiers et les journaux d’émission du certificat.

Si vous suspectez une compromission, désactivez temporairement les accès non indispensables, conservez les journaux et prévenez votre hébergeur. Changez les mots de passe depuis un appareil fiable, révoquez les clés d’accès, restaurez une sauvegarde saine après analyse et mettez à jour les composants vulnérables.

Ne supprimez pas immédiatement les fichiers suspects avant d’avoir conservé une copie pour l’analyse. Si des données personnelles sont concernées, documentez l’incident et consultez les obligations applicables auprès de la CNIL, en vérifiant les recommandations en vigueur à la date de l’incident.

FAQ sur la sécurité d’un site web en HTTPS

HTTP et HTTPS : quelle est la différence ?

HTTP transmet les échanges sans le chiffrement fourni par TLS, tandis que HTTPS chiffre la connexion et authentifie le domaine au moyen d’un certificat. HTTPS ne remplace pas les mises à jour, les sauvegardes et la sécurisation des comptes.

Un certificat SSL protège-t-il contre le piratage ?

Non. Il protège principalement les données pendant leur transport entre le navigateur et le serveur. Il ne bloque pas une extension vulnérable, une injection SQL, un mot de passe volé ou une mauvaise configuration du serveur.

HTTPS est-il obligatoire pour un site e-commerce ?

HTTPS est nécessaire pour protéger les pages de connexion, les formulaires et les paiements, mais les obligations exactes dépendent de votre activité, de votre prestataire et des données traitées. Une boutique doit aussi sécuriser son CMS, ses comptes, ses cookies et ses flux de paiement.

Comment savoir si une transaction est sécurisée ?

Vérifiez que l’adresse commence par https://, que le domaine est exactement celui du marchand ou du prestataire attendu et qu’aucune alerte ne s’affiche dans le navigateur. Le cadenas ne suffit pas : confirmez aussi le montant, le contexte de la page et le mode d’authentification demandé par votre banque.