En-têtes de Sécurité HTTP

🛡️ X-Frame-Options — Protection contre le Clickjacking

🎯 Ce qu'il fait

Contrôle si votre site peut être affiché dans un <iframe> sur un autre site. Empêche les pages externes d'intégrer votre contenu sans autorisation.

⚠️ Pourquoi c'est important

Sans cette protection, un attaquant peut charger votre site dans un iframe transparent et piéger les utilisateurs pour qu'ils cliquent sans le savoir (clickjacking). Cela peut exposer des identifiants, autoriser des paiements ou modifier des paramètres.

⚙️ Options de configuration

DENY (recommandé) : Bloque toute tentative d'afficher votre site dans un iframe, sans exception.

SAMEORIGIN : Autorise uniquement les iframes du même domaine. Utile si vous utilisez des iframes légitimes de votre propre site.

🎯 Exemple réel : un attaquant crée une page imitant un concours ou un sondage inoffensif, et place votre panneau d'administration WordPress (wp-admin) dans un <iframe> transparent, positionné exactement sur le bouton "Participer". La victime — connectée en tant qu'administrateur dans un autre onglet — pense cliquer sur "Participer", mais le clic atterrit en réalité sur le vrai bouton wp-admin caché en dessous, comme "Supprimer l'utilisateur" ou "Installer l'extension". Sans X-Frame-Options, le navigateur permet à votre site de se charger dans cet iframe étranger. Avec X-Frame-Options: DENY, le navigateur refuse catégoriquement d'afficher votre site dans un iframe externe, laissant un vide sur la page de l'attaquant là où devrait se trouver l'appât.

✅ Recommandation : Utilisez DENY sauf si vous avez une raison spécifique d'avoir besoin de vos propres iframes, auquel cas utilisez SAMEORIGIN.

📝 X-Content-Type-Options — Prévention du MIME Sniffing

🎯 Ce qu'il fait

Dit au navigateur de NE PAS deviner le type de fichier (MIME sniffing). L'oblige à respecter exactement le type déclaré dans l'en-tête Content-Type.

⚠️ Pourquoi c'est important

Sans cet en-tête, un navigateur peut interpréter un fichier texte comme du JavaScript et l'exécuter. Cela permet aux attaquants de télécharger un fichier avec une extension .txt mais avec du code malveillant que le navigateur exécutera.

⚙️ Configuration

La seule valeur valide est nosniff. Il est recommandé de toujours l'activer. Il n'a aucun effet secondaire négatif.

🎯 Exemple réel : un formulaire de téléversement de fichiers mal validé (dans une extension tierce, par exemple) permet à un attaquant de téléverser un fichier nommé image.jpg qui contient en réalité du code JavaScript déguisé en image. Si le navigateur d'un visiteur tente de "deviner" le type de contenu au lieu de faire confiance à l'en-tête déclaré par le serveur, il peut finir par interpréter ce fichier comme un script et l'exécuter dans le contexte de votre site, au lieu de l'afficher comme une image inoffensive. Avec X-Content-Type-Options: nosniff, le navigateur s'en tient strictement au type déclaré par le serveur (image), et refuse de l'exécuter comme du code, quoi que suggère son contenu interne.

✅ FORTEMENT RECOMMANDÉ : Activez-le sans hésitation. C'est l'un des en-têtes les plus sûrs avec le moins d'impact. Il ne casse rien et protège contre une vulnérabilité courante.

🔒 X-XSS-Protection — Pourquoi Nous Ne l'Envoyons Plus

🎯 Qu'était-ce ?

Un en-tête qui activait un filtre anti-XSS intégré dans les navigateurs anciens (Internet Explorer, anciennes versions de Chrome et Safari), conçu pour détecter et bloquer les tentatives d'injection de scripts réfléchis.

⚠️ Pourquoi nous l'avons retiré

Chrome l'a complètement supprimé en 2019 — il n'a pas seulement cessé d'avoir un effet, Google l'a en fait considéré comme plus un risque qu'une aide, car le filtre lui-même avait des failles de sécurité documentées et était assez facile à contourner. Firefox ne l'a jamais implémenté. Microsoft a mis fin au support d'Internet Explorer en 2022. Garder un en-tête qui ne protège plus rien de réel, et qui pouvait autrefois introduire ses propres problèmes, n'avait pas de sens.

✅ Perd-on une protection en le retirant ? Non. Dans Internet Explorer, le seul navigateur où cet en-tête a jamais compté, le filtre était activé par défaut même sans que le site n'envoie d'en-tête — l'en-tête permettait seulement à un site de modifier ce comportement (forcer le blocage total, ou le désactiver s'il causait des faux positifs). En n'envoyant pas l'en-tête, IE conserve simplement son comportement d'usine : rien de ce qui était activé auparavant n'est désactivé.

🎯 La protection réelle, aujourd'hui : l'attaque que ce filtre tentait d'arrêter (XSS réfléchi : une URL manipulée qui fait qu'un champ de recherche mal échappé renvoie du code exécutable au navigateur de quiconque clique sur un lien préparé) est aujourd'hui couverte par deux couches qui fonctionnent de la même façon sur tout navigateur, ancien ou récent : le WAF du pare-feu, qui bloque le motif d'injection au niveau de la requête avant que le HTML n'atteigne le navigateur, et la Content-Security-Policy, qui empêche le navigateur d'exécuter des scripts non autorisés même si le code malveillant est déjà présent dans la page. Aucune des deux ne dépend du navigateur ayant son propre filtre heuristique.

🔗 Referrer-Policy — Contrôle des Fuites d'Informations Referer

🎯 Ce qu'il fait

Contrôle la quantité d'informations de l'URL d'origine envoyée dans l'en-tête Referer lorsque les utilisateurs cliquent sur un lien ou chargent une ressource externe.

⚠️ Pourquoi c'est important

Sans contrôle, l'URL complète (incluant des paramètres comme les jetons, les IDs de session ou les données personnelles) peut fuiter vers des sites externes. Cela viole la confidentialité des utilisateurs et peut exposer des données sensibles.

⚙️ Options de configuration

no-referrer : N'envoie jamais le Referer. Confidentialité maximale, mais peut casser les analytics.

same-origin : Envoie le Referer uniquement au sein du même domaine. N'envoie pas aux sites externes.

strict-origin : Envoie uniquement l'origine (domaine), jamais l'URL complète. Uniquement sur les connexions HTTPS vers HTTPS.

strict-origin-when-cross-origin (recommandé) : Envoie l'URL complète au sein du même domaine, et seulement l'origine aux sites externes. Le meilleur équilibre entre fonctionnalité et confidentialité.

🎯 Exemple réel : un utilisateur connecté navigue vers une page dont l'URL contient un jeton sensible en paramètre (par exemple, un lien de réinitialisation de mot de passe fraîchement généré). Si cette page inclut une ressource chargée depuis un domaine externe — une police web, une bannière publicitaire, un widget tiers —, le navigateur pourrait envoyer cette URL complète, jeton inclus, comme en-tête Referer au serveur externe, sans que l'utilisateur ni le propriétaire du site externe ne le demande explicitement. Avec Referrer-Policy: strict-origin-when-cross-origin, le navigateur ne partage que le domaine d'origine avec les sites externes, jamais le chemin complet avec le jeton, et les liens au sein de votre propre domaine continuent de fonctionner normalement.

💡 Recommandation : Utilisez strict-origin-when-cross-origin. C'est la valeur par défaut dans les navigateurs modernes et offre le meilleur équilibre entre fonctionnalité et confidentialité.

🔐 HSTS — Forcer la Connexion HTTPS

🎯 Ce qu'il fait

Oblige les navigateurs à se connecter exclusivement via HTTPS, même si l'utilisateur tape http:// ou clique sur un lien HTTP. Le navigateur s'en souvient pendant la max-age configurée.

⚠️ Pourquoi c'est important

Sans HSTS, un attaquant sur le même réseau (Wi-Fi public, par exemple) peut intercepter la première connexion HTTP et rediriger l'utilisateur vers un site frauduleux (attaque man-in-the-middle). HSTS élimine cette fenêtre de vulnérabilité.

⚙️ Configuration : max-age

max-age=0 : Désactive HSTS. Force les navigateurs à oublier la politique.

max-age=3600 (1 heure) : Pour les tests. Risque faible, les navigateurs oublient rapidement.

max-age=63072000 (2 ans, recommandé) : Pour la production. Les navigateurs se souviendront d'imposer HTTPS pendant 2 ans.

🎯 Exemple réel : un client se connecte au wifi gratuit d'un café et tape votre domaine de mémoire dans la barre d'adresse, sans le préfixe https://. Le navigateur tente d'abord la connexion non sécurisée en HTTP. Un attaquant sur ce même réseau wifi peut intercepter cette première requête HTTP et renvoyer une copie falsifiée de votre site pour voler des identifiants, avant que la redirection normale vers HTTPS ne se termine (c'est ce qu'on appelle une attaque de l'homme du milieu). Avec HSTS actif et le site déjà visité une fois auparavant en HTTPS, le navigateur ne tente même pas la connexion non sécurisée : il force HTTPS directement, localement sur l'appareil lui-même, privant l'attaquant de cette fenêtre d'interception.

🚨 AVERTISSEMENT CRITIQUE : Si vous activez HSTS avec un max-age élevé et que vous désactivez ensuite HTTPS sur votre serveur, les navigateurs bloqueront l'accès à votre site jusqu'à l'expiration du max-age. Il n'existe aucun moyen de le révoquer avant. Utilisez d'abord une valeur faible pour les tests.

🎯 Content-Security-Policy (CSP) — La Police du Contenu

🎯 Ce qu'il fait

Définit exactement quelles sources sont autorisées à charger des scripts, des styles, des images, des polices et d'autres ressources sur votre site. Toute ressource non autorisée est automatiquement bloquée par le navigateur.

⚠️ Pourquoi c'est important

CSP est la défense la plus puissante contre XSS. Même si un attaquant parvient à injecter un script malveillant, CSP le bloque car le script ne provient pas d'une source autorisée. C'est votre dernière ligne de défense.

🎯 Exemple réel : un commentaire ou un champ de formulaire mal filtré permet à un attaquant d'injecter une balise <script> qui charge du code depuis un domaine étranger dans une de vos pages (une faille typique quand une extension n'échappe pas correctement les entrées utilisateur). Sans CSP, le navigateur de tout visiteur chargeant cette page exécuterait ce script sans poser de question, et le code pourrait voler des cookies de session, rediriger vers un site de phishing ou capturer des frappes clavier. Avec une CSP qui restreint script-src à votre propre domaine (et aux sources que vous avez explicitement autorisées), le navigateur détecte que ce domaine étranger n'est pas sur la liste autorisée et refuse de charger et d'exécuter le script, même si le code malveillant est déjà présent dans le HTML de la page.

⚙️ Configuration

CSP utilise un éditeur de texte libre où vous écrivez la politique directement. Il n'y a pas de boutons de modèle en un clic.

🚨 La valeur par défaut n'est PAS une politique complète — c'est une seule ligne minimale : la première fois que vous activez CSP, le champ de texte n'est pré-rempli qu'avec default-src 'self';. Cette directive unique sert de repli pour TOUT type de ressource sans directive explicite propre (scripts, styles, images, polices...), et comme elle n'inclut ni 'unsafe-inline' ni aucun domaine externe, elle bloquera les styles et scripts en ligne que presque tout thème ou extension WordPress écrit directement dans le HTML, ainsi que toute ressource chargée depuis un CDN externe (Google Fonts, jQuery, YouTube, etc.). N'activez pas l'interrupteur CSP avec cette valeur non modifiée : cela cassera très probablement l'apparence et le fonctionnement d'un vrai WordPress.

💡 Que faire à la place : avant d'activer l'interrupteur CSP, ouvrez votre site avec la console du navigateur (F12) et ajoutez manuellement au champ de texte les domaines dont votre thème, vos extensions et vos scripts tiers ont besoin (Google Fonts, YouTube, votre fournisseur d'analytics, etc.), en suivant la syntaxe des directives expliquée plus bas. Commencez toujours avec le pare-feu en mode Monitoring afin de pouvoir examiner les erreurs de la console sans risquer de rendre votre site en production inutilisable.

Pourquoi n'y a-t-il pas de modèle « sûr pour WordPress » en un clic ? Cela a été testé en profondeur au préalable : il n'existe pas de politique CSP unique qui fonctionne sans rien casser parmi les milliers de combinaisons thème + extensions + services tiers qui tournent sur ce plugin — il y a toujours un cas qui nécessite unsafe-inline, un domaine CDN spécifique ou une permission dont un autre site n'a pas besoin. C'est pourquoi le champ est laissé vide (avec le repli minimal default-src 'self';) afin que vous le construisiez vous-même selon ce que votre site charge réellement, plutôt que de proposer un bouton qui inviterait à l'activer à l'aveugle.

⚠️ Risque CSP : Une politique mal configurée peut casser votre site (bloquer les scripts, styles, images ou ressources essentiels). Testez toujours d'abord avec le pare-feu en mode Monitoring, en surveillant la console du navigateur. N'ajoutez que ce dont votre site a réellement besoin, directive par directive.

💡 Astuce : Si quelque chose cesse de fonctionner après l'activation de CSP, ouvrez la console du navigateur (F12). Les erreurs vous diront exactement quelle ressource a été bloquée et depuis quel domaine. Ajoutez simplement ce domaine aux directives correspondantes.

✍️ Comment S'écrit une Politique CSP (Syntaxe de Base)

Même si cela ressemble à un bloc de texte intimidant, la CSP suit toujours une structure très simple et cohérente :

directiva1 valor1 valor2 valor3; directiva2 valor1; directiva3 valor1 valor2;

Chaque directive se termine par un point-virgule (;). C'est ce qui sépare une règle de la suivante — si vous en oubliez un, la directive suivante peut rester « collée » à la précédente et cesser de fonctionner.
Au sein d'une directive, les valeurs sont séparées par des espaces (jamais des virgules) : script-src 'self' https://exemple.com https://autre.com; autorise trois sources différentes pour les scripts.
Les mots-clés spéciaux sont entre guillemets simples : 'self' (votre propre domaine), 'none' (rien, totalement interdit), 'unsafe-inline' (autorise le code écrit directement dans le HTML). Les domaines normaux ne portent jamais de guillemets : https://fonts.googleapis.com, pas 'https://fonts.googleapis.com'.
Vous pouvez autoriser un domaine entier avec un joker : https://*.googleapis.com autorise n'importe quel sous-domaine de googleapis.com, au lieu de devoir les lister un par un.

✏️ Comment ajouter une nouvelle permission, étape par étape : trouvez la directive correspondante (ex. script-src pour un script) dans le texte déjà présent dans le champ, et ajoutez le nouveau domaine juste avant le point-virgule de cette directive, séparé par un espace de la valeur précédente. Exemple : si vous aviez script-src 'self' 'unsafe-inline'; et devez autoriser https://widget.exemple.com, changez-le en : script-src 'self' 'unsafe-inline' https://widget.exemple.com;. Ne supprimez rien de ce qui existait déjà, ajoutez seulement.

📚 Les Directives Que Vous Allez Utiliser (Combien Il y en a et à Quoi Sert Chacune)

La spécification CSP définit plus de 20 directives au total, mais sur un site WordPress normal, vous n'aurez besoin de toucher qu'à ces 12 — ce sont celles déjà présentes dans la valeur par défaut ou celles le plus souvent nécessaires lors de l'ajout d'un nouveau service :

Directive	À quoi elle sert (ce qu'elle contrôle)	Quand vous y touchez
`default-src`	Valeur de repli : s'applique à tout type de ressource qui n'a pas sa propre directive spécifique ci-dessous.	Presque jamais — sert de filet de sécurité
`script-src`	D'où le JavaScript peut être chargé et exécuté (`<script>`, code dans les attributs `onclick`, etc.)	Lors de l'installation d'un chatbot, d'un pixel de suivi, d'un widget d'avis...
`style-src`	D'où les feuilles de style CSS et les styles écrits directement dans le HTML peuvent être chargés	Lors de l'ajout d'une police externe (Google Fonts, Adobe Fonts...)
`img-src`	D'où les images peuvent être chargées	Si vous utilisez un CDN d'images, des avatars externes (Gravatar), des cartes intégrées...
`font-src`	D'où les fichiers de police (.woff, .ttf...) peuvent être chargés	Va presque toujours de pair avec `style-src` pour le même service de polices
`connect-src`	À quels domaines le JavaScript de la page peut se connecter (requêtes `fetch`, `XMLHttpRequest`, WebSockets)	Lors de l'intégration d'analytics, d'un chat en direct, de tout service envoyant des données en arrière-plan
`frame-src`	Quelles pages externes peuvent être intégrées dans un `<iframe>` sur votre site	Lors de l'intégration d'une vidéo YouTube/Vimeo, d'une carte Google Maps, d'un formulaire d'un autre service
`media-src`	D'où les fichiers audio/vidéo lus avec `<audio>`/`<video>` peuvent être chargés	Si vous hébergez des podcasts ou votre propre vidéo en dehors de votre domaine (ex. sur un CDN séparé)
`object-src`	Contrôle `<object>`, `<embed>` et `<applet>` (Flash et anciens plugins de navigateur)	Jamais — laissez-la toujours à `'none'`, c'est une technologie obsolète et non sécurisée
`base-uri`	Quelles URLs la page peut utiliser comme base pour résoudre les liens relatifs (balise `<base>`)	Presque jamais — `'self'` est correct dans 99 % des cas
`form-action`	Vers quelles URLs un formulaire de votre site peut être soumis (`action=`)	Si un formulaire envoie des données à un domaine externe (ex. une passerelle de paiement avec redirection)
`frame-ancestors`	Qui peut intégrer VOTRE site dans un `<iframe>` (protection anti-clickjacking)	Presque jamais — `'self'` couvre déjà la plupart des cas
`upgrade-insecure-requests`	Force tout ressource demandée en HTTP à se recharger automatiquement en HTTPS (ne prend pas de valeurs, reste seule)	Laissez-la toujours activée si votre site utilise HTTPS (la norme aujourd'hui)

🔍 Comment Trouver la Valeur à Chercher Quand Quelque Chose Casse

Vous avez trois façons de découvrir exactement quel domaine manque à votre CSP, de la plus rapide à la plus complète :

Console du navigateur (F12 → onglet « Console ») : la méthode la plus directe. Chaque ressource bloquée apparaît sous forme de ligne rouge indiquant littéralement « Refused to load/execute... because it violates the following Content Security Policy directive: "script-src ..." » — la partie finale indique la directive exacte, et juste avant figure l'URL complète de la ressource bloquée. Copiez le domaine de cette URL et ajoutez-le à cette directive.
Onglet « Network » du navigateur (F12 → « Network ») : utile pour voir, même avant d'activer la CSP, de quels domaines dépend réellement votre page. Rechargez la page avec cet onglet ouvert et vous verrez chaque requête avec son domaine d'origine — vous saurez ainsi à l'avance ce que vous devrez autoriser.
La documentation du service externe lui-même : si vous installez un chat en direct, un formulaire de paiement ou un widget tiers connu, cherchez sur son site d'aide « CSP » ou « Content Security Policy » — la plupart des services sérieux (Stripe, Intercom, HubSpot, etc.) publient exactement quels domaines vous devez autoriser et dans quelle directive, car c'est une question très courante parmi leurs propres clients.

🧩 Exemple complet, étape par étape : vous installez un widget de chat d'un fournisseur externe et, après activation de la CSP, il cesse de s'afficher. Vous ouvrez la console (F12) et voyez :

Refused to load the script 'https://widget.fournisseurchat.com/loader.js' because it violates the following Content Security Policy directive: "script-src 'self' 'unsafe-inline'"

. Vous repérez script-src dans le champ de texte et y ajoutez le domaine : de script-src 'self' 'unsafe-inline'; à script-src 'self' 'unsafe-inline' https://widget.fournisseurchat.com;. Vous enregistrez, rechargez la page avec F12 ouvert à nouveau — si le chat se charge et qu'aucune nouvelle erreur liée n'apparaît, c'est résolu. Si, une fois chargé, le chat doit aussi se connecter à un autre domaine pour envoyer des messages, vous verrez une deuxième erreur pointant vers connect-src, et vous répétez le même processus avec cette directive.

📖 Où Consulter la Référence Complète

Avec les 12 directives du tableau ci-dessus, vous résolvez pratiquement n'importe quel cas réel sur WordPress. Si un jour vous avez besoin d'une directive plus spécifique qui ne figure pas ici (il y en a plus de 20 au total, certaines très rarement utilisées en dehors d'applications web complexes), la référence officielle et la plus complète est la documentation de MDN Web Docs (Mozilla), qui tient la liste complète avec des exemples et la compatibilité par navigateur — cherchez « MDN Content-Security-Policy » dans n'importe quel moteur de recherche. C'est la même source qu'utilisent les développeurs de navigateurs eux-mêmes.

🛠️ Également au sein du plugin lui-même : dans ce même onglet Headers, la section « Logging et Diagnostic » vous permet d'activer l'enregistrement des en-têtes réellement envoyés et de les afficher dans un panneau de diagnostic — utile pour confirmer que la politique enregistrée est bien celle qui atteint le navigateur de vos visiteurs, sans dépendre uniquement de la consultation du code source.

🔌 Permissions-Policy — Contrôle des APIs du Navigateur

🎯 Ce qu'il fait (explication simple)

Imaginez votre site web comme une maison et chaque visiteur entre avec son téléphone. Cette autorisation dit au navigateur : « ce site n'a pas besoin de savoir où vous êtes, de voir votre visage ou de vous écouter ». Ainsi, même si un script malveillant s'infiltre sur votre site, le navigateur ne lui prêtera pas la caméra, le microphone ni la localisation.

⚠️ Pourquoi c'est important (scénario réel)

Pensez à ceci : vous avez une boutique en ligne. Un pirate trouve une faille dans un plugin installé il y a 2 ans et injecte un script. Ce script pourrait silencieusement allumer la caméra du visiteur qui regarde vos produits, récupérer sa position exacte ou enregistrer avec le microphone. Sans Permissions-Policy, le navigateur ne dira pas non. Avec cette protection activée, même si le script malveillant essaie, le navigateur répondra : « Désolé, ce site n'a pas la permission d'utiliser la caméra ». Et le visiteur ne saura jamais qu'une tentative a eu lieu.

🧠 Voyez-le ainsi : C'est comme dire à un employé : « Vous travaillez au comptoir, vous n'avez pas besoin des clés du coffre ». Même si quelqu'un vole son identité et entre dans le magasin, il ne peut pas ouvrir le coffre parce que cet employé n'a jamais eu accès. Permissions-Policy fait exactement cela : il dit au navigateur « ce site n'a pas besoin de la caméra, ne donne pas l'accès même si on te le demande ».

🧩 Que bloque-t-il exactement ?

Ce sont des fonctions du téléphone ou de l'ordinateur dont un site web normal N'A PAS besoin pour fonctionner. Si votre site est un blog, une boutique ou un site d'entreprise, vous ne devriez avoir besoin d'aucune de ces fonctions :

📡 Localisation

Exemple : Un site de pâtisserie n'a pas besoin de savoir où vous habitez pour vous montrer un gâteau. Risque : Un script espion pourrait traquer vos visiteurs. Bloqué ✅

🎥 Caméra

Exemple : Un site de recettes n'a pas besoin de vous voir pour vous apprendre à cuisiner. Risque : Espionner les visiteurs en les enregistrant à leur insu. Bloqué ✅

🎤 Microphone

Exemple : Un journal numérique n'a pas besoin de vous entendre pour vous montrer les actualités. Risque : Enregistrer des conversations privées. Bloqué ✅

💳 Paiements / 🔔 Notifications

Exemple : La plupart des sites utilisent leur propre formulaire de paiement ou des plugins tiers, pas l'API native du navigateur. Risque : Des scripts non autorisés prennent de l'argent ou envoient de fausses notifications. Bloqué ✅

🔄 Capteurs / 🔗 USB

Exemple : Un site d'actualités n'a pas besoin de savoir si vous marchez (accéléromètre) ni d'accéder à vos périphériques USB. Risque : Savoir si l'utilisateur est immobile ou en mouvement, ou accéder aux fichiers USB sans autorisation. Bloqué ✅

✅ Est-ce sécurisé à activer ? Oui, absolument. La plupart des sites WordPress n'utilisent aucune de ces fonctions (caméra, microphone, GPS...) pour fonctionner. C'est comme fermer une porte qui était déjà fermée : cela n'affecte rien et protège si quelqu'un tente de l'ouvrir. Si votre site est un blog, une boutique, une landing page ou un site d'entreprise, activez-le sans crainte. Seulement si votre site propose des appels vidéo ou utilise la localisation de l'utilisateur, vous devriez le désactiver.

🔐 SRI (Subresource Integrity) — Protection des Ressources CDN

🎯 Ce qu'il fait (explication simple)

Imaginez que vous commandez une pizza livrée à domicile. Le livreur vous apporte une boîte scellée avec un sceau de sécurité. Si le sceau est brisé, vous savez que quelqu'un l'a ouverte et vous ne la mangez pas. SRI fait exactement cela avec les fichiers que votre site charge depuis d'autres serveurs (Google Fonts, jQuery, Bootstrap...) : il met un « sceau numérique » sur chaque fichier. Si le fichier arrive modifié (par un pirate, par exemple), le navigateur détecte que le sceau est brisé et le rejette. L'utilisateur ne le sait jamais, mais il est protégé.

⚠️ Pourquoi c'est important (scénario réel)

Presque tous les sites web utilisent des ressources externes : Google Fonts pour les belles polices, jQuery pour les effets visuels, Bootstrap pour l'affichage mobile, Google Analytics pour les statistiques... Tous ces fichiers sont sur des serveurs que vous NE contrôlez PAS. Il y a eu des cas réels où des pirates ont injecté du code malveillant dans des CDN très connus. Sans SRI, si un CDN est piraté, votre site chargerait ce virus sans que vous le sachiez. Avec SRI, le navigateur dit : « Ce fichier ne correspond pas à son empreinte digitale, je le bloque ».

🔍 Cas réel qui s'est produit : En 2018, un attaquant a réussi à modifier un fichier JavaScript sur un CDN utilisé par des millions de sites (une bibliothèque appelée Event-Stream). Le fichier modifié volait des cryptomonnaies aux visiteurs. Si ces sites avaient activé SRI, le navigateur aurait détecté que le fichier ne correspondait plus à son empreinte originale et l'aurait bloqué automatiquement. Personne n'aurait perdu d'argent.

⚙️ Comment ça fonctionne en 3 étapes (facile)

1️⃣ Analyse automatique

SeenSecure examine votre site et trouve tous les fichiers chargés depuis des serveurs externes (Google Fonts, jQuery, Bootstrap, icônes, etc.). C'est comme faire l'inventaire de tout ce qui entre dans votre maison.

2️⃣ L'empreinte est calculée

Pour chaque fichier, SeenSecure génère une « empreinte digitale » unique (un code spécial qui identifie ce fichier exact). C'est comme prendre les empreintes digitales de chaque ressource. Si le fichier change ne serait-ce que d'une lettre, l'empreinte change complètement.

3️⃣ Protection active

Quand quelqu'un visite votre site, le navigateur compare l'empreinte du fichier qui arrive avec celle qu'il devrait avoir. Si elles correspondent → le fichier s'exécute normalement. Si elles ne correspondent pas → le fichier est rejeté. Simple comme ça. Le visiteur voit le site correctement et ne sait jamais qu'il y a eu une tentative d'attaque.

📌 À quelle fréquence faut-il re-analyser ? Seulement quand vous ajoutez quelque chose de nouveau : un plugin qui charge jQuery depuis un CDN, un thème qui utilise Google Fonts, une nouvelle icône. C'est-à-dire presque jamais. Et quand vous le faites, c'est seulement un clic dans le panneau. Le reste du temps, SRI travaille tout seul.

✅ Est-ce sécurisé à activer ? Oui, absolument. SRI ne ralentit pas votre site (la vérification est effectuée par le navigateur du visiteur, pas par votre serveur). Il ne casse rien si les fichiers sont légitimes. Le seul cas où il bloquerait quelque chose, c'est si un fichier CDN a été modifié... ce qui est exactement ce que nous voulons. Activez-le et oubliez-le.

📋 Résumé & Recommandations

Tous les en-têtes n'ont pas le même niveau de risque ou d'urgence. Ce tableau vous aide à prioriser :

Activer Immédiatement

Ces en-têtes n'ont aucun effet secondaire négatif et protègent contre les attaques courantes :

✅ X-Frame-Options: DENY — Clickjacking

✅ X-Content-Type-Options: nosniff — MIME sniffing

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

✅ Permissions-Policy — APIs du navigateur

✅ SRI — Intégrité des ressources CDN

Activer avec Précaution

Ces en-têtes nécessitent une vérification préalable. Ils peuvent bloquer le site s'ils sont mal configurés :

⚠️ HSTS — Commencez avec un max-age faible (3600). N'augmentez à 2 ans que lorsque vous êtes sûr à 100% que HTTPS ne sera jamais désactivé.

⚠️ CSP — Ne l'activez pas avec la valeur par défaut d'une seule ligne. Construisez d'abord la politique vous-même en mode Monitoring, en surveillant la console du navigateur. Si quelque chose est bloqué, ajustez la politique.

🎯 Ordre d'activation recommandé : 1️⃣ X-Frame-Options → 2️⃣ X-Content-Type-Options → 3️⃣ Referrer-Policy → 4️⃣ HSTS (avec prudence) → 5️⃣ CSP (avec prudence). Les 3 premiers sont sûrs et peuvent être activés ensemble.