Vérifier la sécurité de votre site web sans rien pirater

Contrôles de sécurité passifs pour boutique en ligne : certificat TLS, HSTS, CSP, nosniff, cookies, contenu mixte, jQuery obsolète, security.txt et DMARC.

Rédaction FixReports12 min de lecture

Vous pouvez vérifier de l’extérieur une bonne partie de la configuration de sécurité d’une boutique en ligne, simplement en lisant ce que le site envoie déjà à chaque visiteur : son certificat TLS, ses redirections, les en-têtes de ses réponses HTTP, ses cookies, les scripts qu’il charge et ses enregistrements DNS publics. Ces vérifications passives n’envoient aucun trafic d’attaque et ne nécessitent aucune connexion : elles ne sollicitent donc pas plus une boutique qu’une visite normale. Elles repèrent des failles de configuration comme un certificat sur le point d’expirer, l’absence de HSTS, des cookies non sécurisés, du contenu mixte ou une version de jQuery présentant des vulnérabilités connues. Elles ne constituent pas un test d’intrusion et ne peuvent pas prouver qu’une boutique est sécurisée.

Points clés

Qu’est-ce qu’une vérification de sécurité passive ?

Une vérification passive se contente de lire ce que le site ou son DNS renvoie à une requête ordinaire.

Cela consiste à charger des pages publiques, à lire le certificat et les en-têtes de réponse, à lister les cookies et les scripts qu’une page définit, et à interroger les enregistrements DNS publics. Une vérification passive ne tente pas de deviner des mots de passe, n’envoie pas de charges d’injection, ne sonde pas les URL d’administration et ne scanne pas les ports. Tout ce qui suit peut se faire avec un navigateur, curl, openssl et dig.

Comment vérifier votre certificat TLS et sa date d’expiration ?

Lisez directement les dates et les noms du certificat, et assurez-vous que son renouvellement est automatisé.

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

Vérifiez que la date notAfter est suffisamment éloignée, que le certificat couvre à la fois example.com et www.example.com si vous utilisez les deux (le visualiseur de certificats du navigateur liste les noms), et que le navigateur n’affiche aucun avertissement. La durée de vie des certificats diminue en application des Baseline Requirements du CA/Browser Forum (section 6.3.2, version 2.3.1 en octobre 2026), à la suite du Ballot SC-081v3 (s’ouvre dans un nouvel onglet), adopté le 11 avril 2025 :

Date d’émission du certificatDurée de validité maximale
Avant le 15 mars 2026398 jours
Du 15 mars 2026 au 14 mars 2027200 jours
Du 15 mars 2027 au 14 mars 2029100 jours
À partir du 15 mars 202947 jours

Avec des durées aussi courtes, le renouvellement manuel devient risqué : vérifiez que votre hébergeur ou votre outil de gestion des certificats les renouvelle automatiquement. Vérifiez aussi que le HTTP simple redirige vers HTTPS :

curl -sI http://example.com/ | grep -i -E "^HTTP|^location"

Vous devez obtenir une réponse 301 (ou 308) avec un en-tête location commençant par https://.

Quels en-têtes de sécurité une boutique en ligne doit-elle envoyer ?

Un petit ensemble d’en-têtes de réponse bloque, pour un coût quasi nul, des attaques courantes côté navigateur.

En-têteRôleValeur typeSource
Strict-Transport-SecurityIndique aux navigateurs de n’utiliser que HTTPS et empêche les utilisateurs de passer outre les erreurs de certificatmax-age=31536000; includeSubDomainsMDN (s’ouvre dans un nouvel onglet)
Content-Security-Policy: frame-ancestorsContrôle quels sites peuvent intégrer vos pages, ce qui protège contre le détournement de clic (clickjacking)frame-ancestors 'self'MDN (s’ouvre dans un nouvel onglet)
X-Frame-OptionsAncien contrôle de l’intégration dans des cadres ; selon l’OWASP, frame-ancestors le rend obsolète dans les navigateurs compatiblesDENY ou SAMEORIGINOWASP (s’ouvre dans un nouvel onglet)
X-Content-Type-OptionsEmpêche la détection du type MIME (MIME sniffing) et bloque les scripts et feuilles de style servis avec un type incorrectnosniffMDN (s’ouvre dans un nouvel onglet)
Referrer-PolicyLimite la part de vos URL transmise aux autres sitesstrict-origin-when-cross-originOWASP
X-XSS-ProtectionEn-tête du filtre XSS des navigateurs ; selon l’OWASP, il peut créer des vulnérabilités XSS sur des sites par ailleurs sûrsNe pas le définir, ou 0OWASP

Vérifiez ce qu’envoie votre boutique :

curl -sI https://example.com/

Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Security-Policy: frame-ancestors 'self'
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin

Deux mises en garde. includeSubDomains bloque tout sous-domaine qui ne fonctionne qu’en HTTP : vérifiez donc d’abord vos sous-domaines. Le préchargement HSTS exige un max-age d’au moins 31536000 et includeSubDomains : n’ajoutez donc preload que lorsque chaque sous-domaine est prêt pour HTTPS. Une CSP complète qui restreint les scripts vaut la peine, mais l’OWASP souligne qu’elle est complexe à configurer et à maintenir, et les boutiques qui utilisent de nombreuses applications doivent la tester soigneusement.

Vos cookies sont-ils définis avec Secure, HttpOnly et SameSite ?

Les cookies de session et de panier doivent porter ces trois attributs, et vous pouvez les voir dans les en-têtes de réponse Set-Cookie.

AttributEffet (selon MDN (s’ouvre dans un nouvel onglet))Où il compte
SecureEnvoyé uniquement via HTTPS ; les sites en HTTP simple ne peuvent pas le définirChaque cookie d’une boutique en HTTPS
HttpOnlyJavaScript ne peut pas le lire via document.cookie, ce qui aide à se protéger du XSSSessions de connexion et paniers
SameSite=Lax ou StrictLimite les cas où le cookie est envoyé lors de requêtes intersitesSessions ; Strict convient aux cookies d’authentification et de panier
SameSite=NoneEnvoyé lors de requêtes intersites ; doit être combiné avec SecureUniquement les fonctionnalités tierces intégrées qui en ont besoin

Si aucun attribut SameSite n’est défini, les navigateurs traitent le cookie comme Lax. Les cookies que vos propres scripts doivent lire ne peuvent pas être HttpOnly : concentrez-vous donc sur ceux qui identifient un client connecté ou un administrateur.

curl -sI https://example.com/ | grep -i "^set-cookie"

Les outils de développement du navigateur affichent les mêmes informations, y compris les cookies définis par des scripts après le chargement de la page.

Comment repérer le contenu mixte ?

Le contenu mixte désigne toute ressource chargée en HTTP sur une page servie en HTTPS, et la console du navigateur le signale.

MDN (s’ouvre dans un nouvel onglet) le répartit en deux groupes. Les images, l’audio et la vidéo peuvent être « mis à niveau » : les navigateurs les demandent automatiquement en HTTPS. Les scripts, les feuilles de style, les iframes, les polices et les requêtes fetch() sont « bloquables » : les navigateurs les bloquent, ce qui casse tout ce qui en dépendait. Les requêtes mises à niveau vers une simple adresse IP sont également bloquées.

Pour le trouver, ouvrez la console sur vos modèles clés (accueil, collection, produit, panier) et recherchez http:// dans le code de votre thème, le contenu de vos pages et les réglages de vos applications. Le centre d’aide Shopify indique que toute page de boutique comportant une ressource qui n’est pas servie en HTTPS est considérée comme non sécurisée (s’ouvre dans un nouvel onglet), et recommande d’héberger les ressources sur Shopify ou de les servir en HTTPS. Sur WooCommerce, vérifiez le contenu des anciens articles et les options du thème si le site a un jour fonctionné en http://.

Comment repérer les bibliothèques JavaScript obsolètes touchées par des CVE connues ?

Listez les bibliothèques que charge chaque page, relevez leurs versions et comparez-les avec la National Vulnerability Database.

Commencez par jQuery. Dans la console du navigateur, $.fn.jquery renvoie la version chargée (API jQuery (s’ouvre dans un nouvel onglet)). Les versions à signaler :

CVEVersions concernéesProblèmeScore NVD (v3.1)
CVE-2020-11022 (s’ouvre dans un nouvel onglet)De 1.12.0 à 3.5.0 exclueTransmettre du HTML non fiable à des méthodes comme .html() ou .append() peut exécuter du code6,1 Moyen
CVE-2020-11023 (s’ouvre dans un nouvel onglet)De 1.0.3 à 3.5.0 exclueMême problème, pour du HTML contenant des éléments <option> ; dans le catalogue KEV de la CISA depuis le 23 janvier 20256,1 Moyen
CVE-2019-11358 (s’ouvre dans un nouvel onglet)Antérieures à 3.4.0Pollution de prototype via jQuery.extend(true, ...)6,1 Moyen

Les deux problèmes de 2020 sont corrigés dans jQuery 3.5.0. Une version vulnérable signifie que le code défectueux est présent ; la possibilité de l’exploiter dépend de la manière dont le site lui transmet des données. WordPress intègre jQuery 3.5.1 depuis la version 5.6 (s’ouvre dans un nouvel onglet) : un jQuery ancien sur une boutique WooCommerce révèle donc un WordPress obsolète, ou un thème ou une extension qui charge sa propre copie. Sur Shopify, vérifiez les fichiers de votre thème et les applications qui injectent des scripts.

Qu’est-ce que security.txt et votre boutique en a-t-elle besoin ?

C’est un fichier texte brut qui indique aux chercheurs en sécurité comment vous signaler une vulnérabilité.

La RFC 9116 (s’ouvre dans un nouvel onglet) (avril 2022, une RFC informative : la suivre est donc facultatif) précise que le fichier doit être servi en HTTPS à l’adresse /.well-known/security.txt, au format text/plain. Les champs Contact et Expires sont obligatoires, et la RFC recommande une date Expires située à moins d’un an.

Contact: mailto:security@example.com
Expires: 2027-09-30T23:00:00.000Z
Preferred-Languages: en
Policy: https://example.com/security-policy

Sur WooCommerce, vous pouvez placer le fichier sur votre serveur. Sur une plateforme hébergée, vérifiez si vous pouvez publier un fichier à cet emplacement ; sinon, un contact sécurité clairement indiqué sur votre page de contact reste utile.

Comment DMARC protège-t-il votre boutique contre l’usurpation d’adresse e-mail ?

DMARC vous permet de demander aux fournisseurs de messagerie de mettre en quarantaine ou de rejeter les e-mails qui utilisent votre domaine dans l’adresse From sans réussir SPF ou DKIM aligné.

Un enregistrement en p=none ne fait que collecter des rapports ; il n’arrête pas les e-mails usurpés. Vos clients s’attendent à recevoir de votre domaine les confirmations de commande et les réinitialisations de mot de passe : un e-mail d’hameçonnage qui affiche exactement votre domaine mérite donc d’être bloqué. Vérifiez votre politique avec dig +short TXT _dmarc.example.com, et consultez la RFC 9989 (s’ouvre dans un nouvel onglet) pour la spécification. DMARC ne couvre pas les domaines ressemblants, seulement le domaine qui publie l’enregistrement.

Que gère Shopify, et que contrôlez-vous sur WooCommerce ?

Shopify exploite les serveurs de ses vitrines, alors qu’une boutique WooCommerce auto-hébergée vous laisse, à vous et à votre hébergeur, les réglages du serveur.

VérificationShopifyWooCommerce (auto-hébergé)
Certificat TLSGratuit pour tous les domaines ajoutés à Shopify (s’ouvre dans un nouvel onglet) ; peut prendre jusqu’à 48 heures pour les domaines tiersVotre hébergeur ou votre propre configuration
Redirection HTTP vers HTTPSPlateformeRéglages du serveur web, du CDN ou de l’hébergeur
En-têtes de sécuritéEnvoyés par les serveurs de ShopifyServeur web, CDN ou extension
Attributs des cookiesLes cookies propres à Shopify sont définis par la plateforme ; ceux des applications et du thème relèvent de vousCœur de WordPress, extensions et serveur
Contenu mixte et bibliothèques JSVotre thème, votre contenu et vos applicationsVotre thème, votre contenu et vos extensions
security.txt et DMARCVotre domaine et votre DNSVotre domaine et votre DNS

Lorsque nous avons vérifié plusieurs vitrines hébergées par Shopify en octobre 2026, leurs réponses comprenaient HSTS avec un max-age d’environ 91 jours, X-Content-Type-Options: nosniff et une CSP avec upgrade-insecure-requests, tandis que frame-ancestors variait d’une boutique à l’autre. Shopify indique être certifié conforme PCI DSS de niveau 1 (s’ouvre dans un nouvel onglet). Votre thème et les applications installées restent sous votre responsabilité.

Sur WooCommerce, le guide de sécurisation (s’ouvre dans un nouvel onglet) de WordPress recommande de tenir WordPress et les extensions à jour, de supprimer les extensions inutilisées et de demander à votre hébergeur quelles mesures de sécurité il applique.

Pourquoi n’est-ce pas un test d’intrusion ?

Un test d’intrusion tente activement des attaques ; les vérifications passives se contentent d’observer.

La publication NIST SP 800-115 définit le test d’intrusion comme un test de sécurité dans lequel les évaluateurs imitent des attaques réelles pour trouver des moyens de contourner les fonctions de sécurité d’un système (glossaire du NIST (s’ouvre dans un nouvel onglet)). Les vérifications passives ne peuvent pas voir les failles côté serveur des extensions, les mots de passe d’administration faibles ou réutilisés, l’absence d’authentification à deux facteurs, les défauts de contrôle d’accès ni le code vulnérable qui n’apparaît jamais dans la source de la page. Utilisez-les comme une base de référence que vous pouvez refaire à tout moment. Pour une assurance plus poussée, commandez un test d’intrusion avec un périmètre écrit, sur des systèmes qui vous appartiennent ou que vous êtes autorisé à tester.

Une analyse gratuite effectue un premier passage sur votre boutique. Le Rapport Sécurité du site couvre les vérifications passives de cet article, du TLS et des redirections aux en-têtes, cookies, contenu mixte, bibliothèques obsolètes, security.txt et DMARC, avec des corrections pour chaque constat. Comme tout examen passif, il ne peut pas garantir qu’une boutique est sécurisée.

Foire aux questions

Les vérifications de sécurité passives font-elles courir un risque à ma boutique ?

Pas plus qu’une visite normale. Elles demandent les mêmes pages publiques et les mêmes enregistrements DNS que n’importe quel navigateur ou serveur de messagerie, et elles n’essaient ni de se connecter ni d’envoyer des charges d’attaque.

Puis-je ajouter des en-têtes de sécurité sur Shopify ?

Les en-têtes de réponse de la vitrine proviennent des serveurs de Shopify : contactez donc l’assistance Shopify s’il manque un en-tête dont vous avez besoin. Une balise CSP <meta> dans votre thème peut ajouter certaines directives, mais MDN précise que frame-ancestors n’est pas pris en charge dans <meta>.

Une ancienne version de jQuery signifie-t-elle que ma boutique a été piratée ?

Non. Cela signifie qu’un code présentant des vulnérabilités connues est chargé, ce qui augmente le risque si le site transmet du HTML non fiable aux méthodes concernées. Mettez-le à jour, ou supprimez le thème ou l’extension qui le charge.

Combien de temps un certificat TLS peut-il être valide aujourd’hui ?

Les certificats reconnus publiquement émis à partir du 15 mars 2026 peuvent être valides 200 jours au maximum. La limite passe à 100 jours à partir du 15 mars 2027, puis à 47 jours à partir du 15 mars 2029.

Un fichier security.txt est-il obligatoire ?

La RFC 9116 est une RFC informative : selon cette norme, publier le fichier est donc facultatif. Il ne coûte presque rien à publier et donne aux chercheurs un moyen clair de vous joindre.

Une analyse passive sans problème signifie-t-elle que ma boutique est sécurisée ?

Non. Elle montre que la configuration publique semble correcte. Les vulnérabilités côté serveur, la sécurité des comptes et les failles de logique métier nécessitent d’autres tests.

Sources

Tous les guides