Étude · septembre 2026

Tout le monde a HTTPS. Presque personne n'a de CSP. Les résultats sécurité de 99 boutiques en ligne norvégiennes

23 septembre 2026 · Online Visibility Report

En août, nous avons mesuré 99 boutiques en ligne norvégiennes avec notre propre outil, Online Visibility Report. L'histoire principale portait sur la visibilité IA, mais l'audit mesure aussi deux catégories qui concernent autre chose : les en-têtes de sécurité et la confiance e-mail. Ces résultats méritent leur propre article, car le schéma est étonnamment cohérent dans l'ensemble du secteur : les fondations sont en place, et l'étage au-dessus reste déverrouillé.

Dans cet article, nous passons en revue ce que les tests de sécurité ont trouvé, ce que chaque lacune signifie concrètement pour une boutique en ligne et ses clients, et quelles mesures relèvent de la configuration, et non de projets de développement.

D'abord une précision importante : il ne s'agit pas de visibilité IA. Les en-têtes de sécurité ne vous rendent pas plus cité dans les réponses IA, et nous n'allons pas prétendre le contraire. La raison pour laquelle l'audit le mesure quand même, c'est que le rapport doit donner une vue d'ensemble de la santé du site vis-à-vis des machines, et la protection des clients en fait partie.

Qu'avons-nous mesuré, et qu'avons-nous laissé de côté ?

Les tests de sécurité vérifient les en-têtes de réponse HTTP des sites que le robot a pu lire, mesurable pour 77 des 78, plus la configuration DNS et e-mail pour les 99, puisque le DNS peut être vérifié même quand le site bloque les robots.

Ayez à l'esprit le type de mesure dont il s'agit : un contrôle de présence, pas un test d'intrusion. Nous vérifions si la protection est activée, pas si elle résisterait à une attaque ciblée. Un site peut avoir tous les en-têtes en place et présenter quand même des vulnérabilités, et inversement. Mais les en-têtes sont la ligne de défense la moins chère du secteur, et leur absence est mesurable.

Les fondations tiennent : transport et hygiène

Ce qui fonctionne, fonctionne presque partout :

95 % redirigent automatiquement les visiteurs vers HTTPS. Une connexion chiffrée est en pratique la norme dans le e-commerce norvégien.
91 % ont une Referrer-Policy : l'en-tête qui empêche que des informations d'URL internes ne fuient vers des tiers.
86 % appliquent des attributs sécurisés aux cookies, afin que les informations de session ne puissent pas être lues par un script ni envoyées sans chiffrement.

C'est la partie du tableau qui donne des raisons d'être rassuré. Le e-commerce norvégien a fait le travail devenu norme du secteur il y a cinq à dix ans.

Puis ça s'amincit, en-tête par en-tête

Au-dessus des fondations, les taux chutent vite :

Protection	Réussite	Contre quoi elle protège
HSTS (≥ 6 mois)	58 %	La rétrogradation de HTTPS vers HTTP (« SSL-stripping »)
X-Frame-Options	49 %	Le chargement de votre page dans le cadre d'un autre site (« clickjacking »)
X-Content-Type-Options	43 %	Le navigateur qui devine les types de fichiers et exécute un contenu qu'il ne devrait pas
Subresource Integrity	38 %	Le remplacement d'un script tiers sans que vous le remarquiez
Content-Security-Policy	3 %	Les scripts étrangers en général : la principale défense contre les attaques par script

Relisez cette dernière ligne : seules 2 des 77 boutiques mesurées ont une Content-Security-Policy. 97 % ne l'ont pas.

Pour une boutique en ligne, ce n'est pas une lacune théorique. La classe d'attaque la plus connue contre le e-commerce est le vol de carte en ligne, le « formjacking », où un script étranger ou altéré lit le formulaire de paiement pendant que le client le remplit. La CSP et la Subresource Integrity sont justement les deux mécanismes qui limitent quels scripts peuvent s'exécuter et vérifient qu'ils n'ont pas été modifiés. Ce sont les deux lignes les plus faibles de tout le tableau.

E-mail : l'infrastructure existe, l'application fait défaut

La confiance e-mail est en fait l'une des catégories les plus fortes de l'audit, avec une moyenne de 81 sur 100. Seules la crawlabilité et le mobile obtiennent un score plus élevé. L'infrastructure est presque complète : SPF est présent pour les 99, MX pour 97 %, DKIM pour 87 %.

Mais vient ensuite la question de la politique : que doit faire le serveur e-mail du destinataire avec un message qui prétend venir de votre domaine mais échoue aux contrôles ? C'est DMARC qui le régit, et voici comment se répartissent les 99 boutiques :

33 ont `p=reject` : les messages falsifiés sont rejetés
21 ont `p=quarantine` : ils atterrissent dans les indésirables
42 ont `p=none` : ils sont surveillés mais livrés normalement
3 n'ont pas de DMARC ou ont une configuration erronée

42 boutiques, plus nombreuses que celles ayant reject, se retrouvent donc avec une protection qui paraît complète dans le DNS mais qui n'arrête absolument rien. Pour une boutique en ligne, le scénario est concret : de fausses confirmations de commande, de fausses factures et des « liens de suivi » envoyés en votre nom, à vos clients, depuis un domaine que les systèmes destinataires ont pour consigne de traiter avec indulgence. Ce sont vos clients qui en paient le prix, et votre marque est l'expéditeur dont ils se souviennent.

Il y a une bonne raison pour laquelle beaucoup restent sur p=none : le chemin vers reject exige que tous les envois légitimes, newsletters, confirmations de commande, service client, soient réellement signés correctement, sinon vous bloquez vos propres e-mails. Mais none est censé être une phase de surveillance de quelques semaines, pas un état permanent.

Ce que cela signifie pour le score, et ce que cela signifie vraiment

Dans le modèle de score en vigueur en août, les en-têtes de sécurité pesaient 6 sur 100 et la confiance e-mail 5. La moyenne de la catégorie sécurité s'est établie à 68 sur 100, un chiffre qui masque l'écart entre un transport solide et une protection par en-têtes ténue.

Mais les points ne sont pas le sujet ici. Les résultats de visibilité de l'étude concernent le fait d'être trouvé ; les résultats de sécurité concernent ce qui attend les clients une fois arrivés. Une boutique en ligne vit de la confiance qui existe au moment précis où quelqu'un saisit son numéro de carte ou ouvre une confirmation de commande. C'est cette confiance que ces configurations protègent.

Cinq mesures, dans l'ordre où nous les prendrions

Renforcez le DMARC. Si vous êtes en p=none aujourd'hui : utilisez les rapports que vous recevez déjà pour vérifier que tous les envois légitimes sont signés, passez à quarantine, puis à reject. Ce sont des modifications DNS et du travail de vérification, pas du développement.
Activez HSTS avec une durée d'au moins six mois. Une seule ligne d'en-tête dans le serveur web ou le CDN. 34 % ne l'ont pas du tout aujourd'hui.
Définissez X-Frame-Options (ou frame-ancestors dans une CSP). Une ligne, et la surface de clickjacking est fermée. La moitié des boutiques ne l'ont pas.
Ajoutez `X-Content-Type-Options: nosniff`. La ligne la moins chère du tableau : une ligne, terminé.
Lancez le travail sur la CSP, mais commencez en mode rapport. Ici, il faut être honnête : la CSP est la seule de ces mesures qui soit un vrai projet. Une boutique en ligne a généralement de nombreux scripts tiers, et une politique trop stricte peut casser votre paiement. Commencez par Content-Security-Policy-Report-Only, cartographiez ce qui se charge réellement, puis resserrez à partir de là. Ajoutez Subresource Integrity sur les scripts tiers que vous pouvez verrouiller. Le fait que 97 % n'aient pas de CSP ne signifie pas qu'elle soit impossible : cela signifie que presque personne n'a commencé.

Une réserve honnête

Trois choses à garder à l'esprit. D'abord, les tests mesurent la présence, pas la résistance : un test d'en-tête réussi n'est pas une garantie de sécurité. Ensuite, les chiffres d'en-têtes concernent les 77 sites mesurables que le robot a pu lire ; les 21 boutiques qui bloquent les robots n'y figurent pas, et nous ignorons comment elles auraient été notées. Enfin, absolument tous les sites mesurés réussissent certains de nos tests (configuration CORS et CORP). Des tests que tout le monde réussit ne distinguent personne, nous ne leur accordons donc aucun poids ici.

Et comme toujours : les chiffres ont été mesurés avec notre propre outil, les 8–10 août 2026, et restent tels qu'ils ont été mesurés.

Pour conclure

Le tableau de la sécurité dans le e-commerce norvégien ressemble plus au tableau de la visibilité que nous ne l'attendions : le travail de la décennie précédente est fait, celui de la décennie actuelle vient à peine de commencer. HTTPS partout, CSP presque nulle part. SPF chez tout le monde, application chez un tiers.

Ce qui est encourageant, c'est que quatre des cinq mesures ci-dessus sont des lignes de configuration et des modifications DNS : un travail qui se mesure en heures, pas en semaines. Le e-commerce norvégien est à un après-midi tranquille de combler les failles les plus courantes. La cinquième mesure, la CSP, demande plus, mais le mode rapport permet de commencer sans rien risquer du tout.

N'hésitez pas à vérifier votre propre boutique : ouvrez les outils de développement de votre navigateur, regardez les en-têtes de réponse de votre page d'accueil, et consultez votre enregistrement DMARC. Si vous y trouvez p=none, vous savez par où commencer. Bonne chance !