Tag Archives: clickjacking DOM

Historique du Clickjacking (2002–2025)

Définition du clickjacking d’extensions basé sur le DOM

Le DOM-based extension clickjacking détourne une extension (gestionnaire de mots de passe ou wallet) en abusant du Document Object Model du navigateur. Une page trompeuse enchaîne iframes invisibles, Shadow DOM et un appel focus() malveillant pour déclencher l’autofill dans un formulaire invisible. L’extension « pense » être sur le bon champ et y déverse des secrets — identifiants, codes TOTP/HOTP, passkeys, voire clés privées. Parce que ces secrets touchent le DOM, ils peuvent être exfiltrés silencieusement.

Quel est le niveau de dangerosité ?

Ce vecteur n’est pas une variante mineure : il exploite la logique même de l’autofill et agit à l’insu de l’utilisateur. L’attaquant ne se contente pas de superposer un élément ; il force l’extension à remplir un faux formulaire comme si de rien n’était, rendant l’exfiltration indétectable par une observation superficielle.

Déroulé type de l’attaque

1. Préparation — la page malveillante intègre une iframe invisible et un Shadow DOM qui camoufle le vrai contexte ; des champs sont rendus non visibles (opacity:0, pointer-events:none).
2. Appât — la victime clique sur un élément anodin ; des redirections et un focus() malveillant redirigent l’événement vers un champ contrôlé par l’attaquant.
3. Exfiltration — l’extension croit interagir avec un champ légitime et injecte automatiquement identifiants, TOTP, passkeys ou clés privées dans le DOM factice ; les données sont aussitôt exfiltrées.

Cette mécanique trompe les indices visuels, contourne des protections classiques (X-Frame-Options, Content-Security-Policy, frame-ancestors) et transforme l’autofill en un canal d’exfiltration invisible. Les overlays de type Browser-in-the-Browser (BITB) ou les manipulations de Shadow DOM aggravent encore le risque, rendant les passkeys synchronisées et les credentials phishables.

Historique du Clickjacking (2002–2025)

Le clickjacking est devenu le parasite persistant du web moderne. Le terme apparaît au début des années 2000, lorsque Jeremiah Grossman et Robert Hansen décrivent la tromperie consistant à pousser un internaute à cliquer sur quelque chose qu’il ne voit pas réellement. Une illusion appliquée au code, vite devenue une technique d’attaque incontournable (OWASP).

• 2002–2008 : émergence du “UI redressing” : calques HTML + iframes transparentes piégeant l’utilisateur (Hansen Archive).
• 2009 : Facebook victime du Likejacking (OWASP).
• 2010 : apparition du Cursorjacking : décalage du pointeur pour tromper le clic (OWASP).
• 2012–2015 : exploitation via iframes, publicité et malvertising (MITRE CVE).
• 2016–2019 : le tapjacking sévit sur mobile (Android Security Bulletin).
• 2020–2024 : montée du “hybrid clickjacking” mêlant XSS et phishing (OWASP WSTG).
• 2025 : à DEF CON 33, Marek Tóth dévoile un nouveau palier : DOM-Based Extension Clickjacking. Cette fois, ce ne sont plus seulement les sites web mais les extensions navigateur (gestionnaires, wallets) qui injectent des formulaires invisibles.

Gestionnaires vulnérables & divulgation CVE (instantané — 2 oct. 2025)

Mise à jour : 2 octobre 2025 Depuis la divulgation DEF CON 33 par Marek Tóth, plusieurs éditeurs ont déployé des correctifs ou atténuations, mais la réactivité varie fortement. La nouvelle colonne indique le délai estimé entre la présentation (8 août 2025) et la sortie d’un patch/atténuation.

Technologies de correction mises en œuvre

Depuis la divulgation publique du DOM Extension Clickjacking à DEF CON 33, des éditeurs ont publié des correctifs. Toutefois ces correctifs restent inégaux et se limitent souvent à des ajustements d’UI ou des vérifications contextuelles. Aucun fournisseur n’a jusqu’ici refondu le moteur d’injection.

Avant d’examiner les méthodes, voici une vue d’ensemble visuelle des principales technologies déployées : du pansement cosmétique aux solutions souveraines Zero-DOM.

Objectif

Expliquer comment les éditeurs ont tenté de corriger la faille, distinguer patchs cosmétiques et corrections structurelles, et mettre en lumière les approches souveraines Zero-DOM hardware.

Méthodes observées (août 2025)

📉 Limites observées

• Les patchs ne changent pas le moteur d’injection, ils en limitent seulement le déclenchement.
• Aucune séparation structurelle interface ↔ flux de secrets.
• Tant que l’injection reste liée au DOM, de nouvelles variantes de clickjacking demeurent possibles.

Technologies de correction — Analyse technique & doctrinale

Constat Le clickjacking d’extensions DOM n’est pas un bug ponctuel mais une erreur de conception : injecter des secrets dans un DOM manipulable sans séparation structurelle ni contrôle contextuel robuste rend l’architecture vulnérable.

Ce que les correctifs actuels n’adressent pas

• Aucun éditeur n’a reconstruit son moteur d’injection.
• Les correctifs limitent l’activation (désactivation, filtrage, détection partielle) plutôt que de changer le modèle d’injection.

Ce qu’exigerait une correction structurelle

• Supprimer la dépendance au DOM pour l’injection de secrets.
• Isoler le moteur d’injection hors du navigateur (matériel ou processus sécurisé séparé).
• Imposer une authentification matérielle (NFC, PGP, enclave) et une validation physique explicite.
• Interdire toute interaction avec des champs invisibles/encapsulés par défaut.

Typologie des correctifs

Tests doctrinaux pour vérifier un correctif

• Injecter un champ invisible (opacity:0) dans une iframe et observer le comportement d’injection.
• Simuler un Shadow DOM encapsulé et vérifier si l’extension injecte malgré tout.
• Vérifier si l’action d’autofill est tracée/auditable ou correctement bloquée en cas de mismatch de contexte.

Absence de norme industrielle

Aucune norme (NIST/OWASP/ISO) n’encadre aujourd’hui : (1) la logique d’injection des extensions, (2) la séparation UI ↔ flux de secrets, (3) la traçabilité des auto-remplissages.

Risques systémiques & vecteurs d’exploitation

Le DOM-based extension clickjacking n’est pas un bug isolé : c’est une faille systémique. Lorsqu’un flux d’injection d’extension est compromis, l’impact dépasse le simple mot de passe volé : il peut entraîner une cascade d’effets sur l’authentification et l’infrastructure.

Scénarios critiques

• Accès persistant — un TOTP cloné permet d’enregistrer un appareil « de confiance » et de maintenir l’accès après réinitialisation.
• Rejeu de passkeys — une passkey exfiltrée peut servir de jeton réutilisable hors de tout contrôle.
• Compromission SSO — fuite de tokens OAuth/SAML via une extension entreprise = brèche SI complète.
• Chaîne d’approvisionnement — extensions faibles ou malveillantes deviennent une surface d’attaque structurelle pour les navigateurs.
• Vol d’actifs crypto — les wallets qui s’appuient sur l’injection DOM peuvent fuir seed phrases ou clés privées, ou signer des transactions malveillantes.

Le clickjacking d’extensions DOM révèle ainsi la fragilité des modèles de confiance logicielle.

Exposition régionale & impact linguistique — sphère francophone

Le clickjacking d’extensions DOM frappe différemment selon les régions. Ci-dessous l’exposition estimée des populations francophones en Europe et dans la francophonie globale, là où les risques numériques sont concentrés et où les réponses souveraines doivent être priorisées.

Exposition estimée — Aire francophone (août 2025)

Sources : OIF, données Europe, WorldData.

Extensions crypto-wallets exposées

Les gestionnaires de mots de passe ne sont pas les seuls à tomber : les wallets (MetaMask, Phantom, TrustWallet) reposent souvent sur l’injection DOM pour afficher ou signer des transactions. Un overlay bien placé ou une iframe invisible peut amener l’utilisateur à croire qu’il valide une opération légitime alors qu’il signe un virement malveillant ou révèle sa seed phrase.

Implication directe : contrairement aux credentials, ici il s’agit d’actifs financiers immédiats. Des milliards de dollars reposent sur ces extensions. Le DOM devient donc un vecteur d’exfiltration monétaire.

Sandbox navigateur faillible & attaques BITB

Les navigateurs présentent leur sandbox comme un rempart, pourtant le DOM-based extension clickjacking et le Browser-in-the-Browser (BITB) démontrent le contraire. Un simple overlay et un faux cadre d’authentification suffisent à tromper l’utilisateur : il croit interagir avec Google, Microsoft ou sa banque alors qu’il livre ses secrets à une page frauduleuse. Même frame-ancestors ou certaines règles CSP ne suffisent pas toujours à empêcher ces forgeries d’interface.

C’est ici que les technologies souveraines modifient la donne. Avec EviBITB (IRDR), Freemindtronic intègre dans PassCypher HSM PGP un moteur de détection et destruction d’iframes de redirection, capable de neutraliser en temps réel les tentatives de BITB. Activable en un clic, utilisable en mode manual, semi-automatique ou automatique, il fonctionne sans serveur, sans base de données et agit instantanément. (explications · guide détaillé)

La clé de voûte reste le sandbox URL. Chaque identifiant ou clé est lié à une URL de référence stockée chiffrée dans le HSM. Lorsqu’une page tente un autofill, l’URL active est comparée à celle du HSM. En cas de non-correspondance, aucune donnée n’est injectée. Ainsi, même si un iframe franchit des contrôles visuels, le sandbox URL bloque l’exfiltration.

Cette double barrière s’étend aux usages desktop via l’appairage sécurisé NFC entre un smartphone Android NFC et l’application Freemindtronic intégrant PassCypher NFC HSM : les secrets restent chiffrés dans le HSM et ne sont déchiffrés que quelques millisecondes en RAM, juste le temps nécessaire à l’auto-remplissage — sans jamais transiter ni résider dans le DOM.

Passkeys phishables — Overlays observés à DEF CON 33

À DEF CON 33, une démonstration indépendante a montré que des passkeys synchronisées — souvent présentées comme « résistantes au phishing » — peuvent être exfiltrées silencieusement via un simple overlay + redirection. Contrairement au DOM-based extension clickjacking, ce vecteur n’exige aucune injection DOM : il abuse de la confiance UI et des frames rendues par le navigateur pour leurrer l’utilisateur et récolter des credentials synchronisés.

Fonctionnement (résumé)

• Overlay / redirection : un faux cadre d’authentification imitant un portail légitime est affiché.
• Trust navigateur abusé : l’UI semble légitime ; l’utilisateur approuve des actions/boîtes de dialogue qui libèrent les passkeys synchronisées.
• Export synchronisé : une fois l’accès obtenu, les passkeys et credentials synchronisés peuvent être exportés et réutilisés.

Synch vs lié à l’appareil — différence clé

• Passkeys synchronisées : stockées/répliquées via cloud / gestionnaire — pratiques mais point de défaillance unique et phishables par usurpation UI.
• Passkeys liées à l’appareil : stockées dans un élément sécurisé matériel et ne quittent pas l’appareil — non soumises à l’export cloud, donc beaucoup plus résistantes aux overlays.

Preuves & sources

• Démonstration Allthenticate et dépôt vivant : yourpasskeyisweak.com.
• Slides techniques DEF CON : Passkeys Pwned — DEF CON 33 (PDF).
• Couverture presse : MENAFN / PR Newswire.

BitUnlocker — Attaque sur BitLocker via WinRE

À DEF CON 33 et Black Hat USA 2025, l’équipe STORM a présenté une attaque critique contre BitLocker nommée BitUnlocker. La technique contourne certaines protections de BitLocker en exploitant des faiblesses logiques dans l’environnement de récupération Windows (WinRE).

Vecteurs d’attaque

• Parsing de boot.sdi — manipulation du processus de chargement
• ReAgent.xml — modification de la configuration de récupération
• BCD altéré — exploitation des Boot Configuration Data

Méthodologie

Les chercheurs ont ciblé la chaîne de démarrage et ses composants de récupération pour :

• Identifier des faiblesses logiques dans WinRE ;
• Développer des exploits capables d’exfiltrer des secrets BitLocker ;
• Proposer des contre-mesures pour renforcer BitLocker / WinRE.

Impact stratégique

Cette attaque montre que même des systèmes de chiffrement réputés peuvent être contournés via des vecteurs indirects — ici la chaîne de récupération. Elle souligne la nécessité d’une approche « défense en profondeur » protégeant non seulement les primitives cryptographiques mais aussi l’intégrité du boot/recovery.

Passkeys phishables @ DEF CON 33 — Attribution & note technique

Signaux stratégiques DEF CON 33

DEF CON 33 cristallise un changement d’hypothèses sur la sécurité navigateur. Points d’action :

• Les navigateurs ne sont plus des zones de confiance. Le DOM n’est pas un sanctuaire des secrets.
• Passkeys synchronisées & secrets injectés dans le DOM sont phishables.
• Réponses éditeurs hétérogènes ; correctifs structurels rares.
• Prioriser les approches Zero-DOM matérielles. Les flux hardware hors-ligne réduisent l’exposition et doivent figurer dans les feuilles de route.

Contre-mesures souveraines (Zero-DOM)

Les correctifs éditeurs réduisent le risque immédiat mais ne suppriment pas la cause : les secrets qui transitent par le DOM. Zero-DOM signifie que les secrets ne doivent jamais résider, transiter ou dépendre du navigateur. La défense durable est architecturale — garder credentials, TOTP, passkeys et clés privées dans du matériel hors-ligne et ne les exposer qu’éphémèrement en mémoire volatile après activation explicite.

Dans une conception Zero-DOM, les secrets sont stockés dans des HSM hors-ligne et ne sont libérés qu’après une action physique explicite (tap NFC, appairage HID, confirmation locale). Le déchiffrement a lieu en RAM volatile pour l’intervalle minimal nécessaire ; rien ne persiste dans le DOM ou sur disque.

Cette approche supprime la surface d’injection au lieu de la masquer : pas de serveur central, pas de mot de passe maître extractible et pas de cleartext persistant dans le navigateur. Les implémentations doivent combiner sandbox URL, fenêtres mémoire minimales et journaux d’activation auditables.

PassCypher HSM PGP — Technologie Zero-DOM brevetée & gestion souveraine des clés anti-phishing

Longtemps avant que le DOM Extension Clickjacking ne soit exposé publiquement à DEF CON 33, Freemindtronic a adopté une autre approche. Depuis 2015, notre R&D suit un principe fondateur : ne jamais utiliser le DOM pour transporter des secrets. Cette doctrine Zero-Trust a produit l’architecture Zero-DOM brevetée de PassCypher HSM PGP, qui maintient identifiants, TOTP/HOTP, passkeys et clés cryptographiques confinés dans des conteneurs HSM matériels — jamais injectés dans un environnement navigateur manipulable.

Un progrès unique pour la gestion des secrets

• Zero-DOM natif — aucune donnée sensible ne touche le navigateur.
• HSM-PGP intégré — conteneurs AES-256-CBC chiffrés + protection par segmentation de clés brevetée.
• Souveraineté opérationnelle — zéro serveur, zéro base centrale, zéro dépendance cloud.

Protection BITB renforcée (EviBITB)

Depuis 2020, PassCypher HSM PGP intègre EviBITB, un moteur serverless neutralisant en temps réel les attaques Browser-in-the-Browser : détection et destruction d’iframes malveillants, identification d’overlays frauduleux et validation anonyme du contexte UI. EviBITB peut fonctionner en mode manuel, semi-automatique ou automatique pour réduire drastiquement le risque BITB et le détournement invisible du DOM.

EviBITB intégré : détection et destruction en temps réel des iFrames et overlays malveillants.

Pourquoi résiste-t-il aux attaques type DEF CON ?

Rien ne transite par le DOM, il n’existe pas de mot de passe maître à extraire et les conteneurs restent chiffrés au repos. La déchiffrement s’opère uniquement en RAM volatile, pour l’instant minimal requis pour assembler des segments de clés ; après l’autofill, tout est effacé sans trace exploitable.

Fonctionnalités clés

• Auto-remplissage blindé — autofill en un clic via sandbox URL, jamais en clair dans le navigateur.
• EviBITB embarqué — neutralisation d’iframes/overlays en temps réel (manuel / semi / automatique), 100 % serverless.
• Outils crypto intégrés — génération et gestion de clés segmentées AES-256 et gestion PGP sans dépendances externes.
• Compatibilité universelle — fonctionne avec n’importe quel site via logiciel + extension ; pas de plugins additionnels requis.
• Architecture souveraine — zéro serveur, zéro DB centrale, zéro DOM : résilience par design.

Mise en œuvre immédiate

Aucune configuration complexe : installez l’extension PassCypher HSM PGP (Chrome Web Store / Edge Add-ons), activez l’option BITB et sandbox URL dans les paramètres, et bénéficiez instantanément d’une protection Zero-DOM souveraine.

PassCypher NFC HSM — Gestionnaire passwordless souverain

Quand les gestionnaires logiciels se font piéger par une simple iframe, PassCypher NFC HSM suit une autre voie : vos identifiants et mots de passe ne transitent jamais par le DOM. Ils restent chiffrés dans un nano-HSM hors-ligne et n’apparaissent qu’un instant en RAM volatile — juste le temps strict nécessaire à l’authentification.

Fonctionnement côté utilisateur :

• Secrets intouchables — stockés et chiffrés dans le NFC HSM, jamais visibles ni extraits.
• TOTP/HOTP — générés et affichés à la demande via l’application PassCypher NFC HSM (Android) ou sur desktop via PassCypher HSM PGP.
• Saisie manuelle — l’utilisateur saisit PIN ou TOTP directement ; l’app PassCypher affiche le code généré par le NFC HSM.
• Auto-remplissage sans contact — présentation du module NFC HSM au smartphone ou ordinateur ; autofill sans contact, même appairé à PassCypher HSM PGP.
• Auto-remplissage desktop — avec PassCypher HSM PGP, clic sur un bouton intégré au champ pour remplir login/mot de passe.
• Anti-BITB distribué — appairage NFC ↔ Android ↔ navigateur déclenchant EviBITB pour neutraliser les iframes en temps réel.
• Mode HID BLE — émulation de clavier Bluetooth injectant hors DOM, neutralisant keyloggers et DOM-attacks.

SeedNFC + HID Bluetooth — Injection sécurisée des wallets

Les wallets web reposent sur le DOM — et c’est précisément là qu’on les piège. Avec SeedNFC HSM, la logique s’inverse : les clés privées et seed phrases ne quittent jamais l’enclave. Pour initialiser ou restaurer un wallet, l’entrée se fait via une émulation HID Bluetooth — comme un clavier matériel — sans presse-papier, sans DOM, sans trace pour saisir les clés privées, publiques ou credentials de hot wallets.

Flux opérationnel (anti-DOM, anti-clipboard) :

• Custodie : la seed/clé privée est chiffrée et stockée dans SeedNFC HSM (jamais exportée).
• Activation physique : présentation sans contact via l’appli Freemindtronic (Android NFC).
• Injection HID BLE : la seed est dactylographiée directement dans le champ du wallet, hors DOM et hors clipboard, résistante aux keyloggers logiciels.
• Protection BITB : EviBITB peut être activé côté appli pour neutraliser overlays lors de l’onboarding.
• Éphémérité : les données résident seulement en RAM volatile durant la frappe HID puis sont effacées.

Cas d’usage :

• Onboarding / recovery de wallets (MetaMask, Phantom) sans exposer la clé privée au navigateur.
• Opérations sensibles sur poste (air-gap logique) avec validation physique par l’utilisateur via NFC.
• Sauvegarde multi-actifs : seed phrases et clés conservées offline, activation exclusivement physique et traçable.

Scénarios d’exploitation & voies de mitigation

Les révélations de DEF CON 33 ne sont pas une fin : plusieurs évolutions sont probables :

• Clickjacking piloté par IA : LLMs génèrent des overlays DOM en temps réel, rendant les hameçonnages DOM + Shadow-DOM plus scalables et crédibles.
• Tapjacking mobile hybride : superposition d’apps et gestes invisibles pour valider des transactions ou exfiltrer OTP.
• HSM post-quantique : mitigation long terme via ancrage matériel et gestion de clés résistantes au quantique — déplacer la frontière de sécurité dans des HSM certifiés plutôt que dans le navigateur.

Synthèse stratégique

Le clickjacking d’extensions DOM démontre que navigateurs et extensions ne sont pas des zones de confiance pour les secrets. Les correctifs réduisent le risque mais n’éliminent pas l’exposition structurelle.

La voie souveraine — trois priorités

• Gouvernance : traiter extensions et moteurs d’autofill comme infrastructure critique — contrôles de dev, audits obligatoires, règles de divulgation d’incident.
• Changement d’architecture : adopter Zero-DOM pour que les secrets ne transitent jamais par le navigateur ; exiger activation physique pour opérations sensibles.
• Résilience matérielle : investir dans ancrages hardware et roadmaps HSM post-quantique pour éliminer les points de défaillance cloud/sync.

Glossaire

DOM (Document Object Model)

Représentation en mémoire de la structure HTML/JS d’une page web ; permet aux scripts d’accéder et de modifier les éléments de la page.

Shadow DOM

Sous-arbre DOM encapsulé utilisé pour isoler des composants (web components) ; il peut masquer des éléments au reste du document.

Clickjacking

Technique consistant à tromper un utilisateur pour qu’il clique sur des éléments masqués ou superposés (UI redressing).

DOM-Based Extension Clickjacking

Variante où une page malveillante combine iframes invisibles, Shadow DOM et redirections (ex. focus()) pour forcer une extension à injecter des secrets dans un formulaire factice.

Autofill / Auto-remplissage

Mécanisme des gestionnaires (extensions/applications) qui insère automatiquement identifiants, mots de passe ou codes dans des champs web.

Passkey

Clé d’authentification WebAuthn (basée sur clé publique) censée être résistante au phishing lorsqu’elle est stockée en local ou dans un secure element.

WebAuthn / FIDO

Standard d’authentification par clé publique (FIDO2) permettant des logins sans mot de passe ; son niveau de sécurité dépend du modèle de stockage (synchrone vs. device-bound).

TOTP / HOTP

Codes temporaires (OTP) générés par algorithme temporel (TOTP) ou compteur (HOTP) pour l’authentification à deux facteurs.

HSM (Hardware Security Module)

Module matériel sécurisé pour générer, stocker et utiliser des clés cryptographiques sans jamais exposer les clés en clair hors de l’enclave.

PGP (Pretty Good Privacy)

Standard de chiffrement hybride utilisant clés publiques/privées ; ici employé pour conteneurs chiffrés AES-256 CBC protégés par PGP.

AES-256 CBC

Algorithme de chiffrement symétrique (mode CBC) avec clé 256 bits — utilisé pour chiffrer les conteneurs de secrets.

Clés segmentées

Approche de fragmentation des clés (segments) pour renforcer la résistance aux attaques et faciliter l’assemblage sécurisé en RAM éphémère.

Mémoire volatile (RAM éphémère)

Zone où les secrets sont brièvement déchiffrés pour l’opération d’autofill, puis immédiatement effacés — aucune persistance sur disque ou DOM.

NFC (Near Field Communication)

Technologie sans contact utilisée pour activer physiquement un HSM et autoriser la libération d’un secret de manière locale et physique.

HID-BLE (Bluetooth Low Energy HID)

Mode d’émulation d’un clavier via BLE pour injecter des données directement dans un champ sans passer par le DOM ni le presse-papier.

Sandbox URL

Mécanisme liant chaque secret à une URL attendue stockée dans l’HSM ; si l’URL active ne correspond pas, l’autofill est bloqué.

Browser-in-the-Browser (BITB)

Attaque par imitation d’une fenêtre de navigateur (overlay) dans une iframe — trompe l’utilisateur en simulant un site ou une boîte d’authentification.

EviBITB

Moteur anti-BITB (serverless) qui détecte et détruit en temps réel iframes/overlays malveillants et valide le contexte UI de façon anonyme.

SeedNFC

Solution HSM matérielle pour la conservation des seed phrases/cles privées ; effectue l’injection hors-DOM via HID/NFC.

Iframe

Cadre HTML embarquant une autre page ; les iframes invisibles (opacity:0, pointer-events:none) sont souvent utilisées dans les attaques d’UI redressing.

focus()

Appel JavaScript qui place le focus sur un champ. Utilisé malicieusement pour rediriger des événements utilisateur vers des champs contrôlés par l’attaquant.

Overlay

Superposition visuelle (fenêtre/faux cadre) qui masque l’interface réelle et peut tromper l’utilisateur sur l’origine d’une action.

Exfiltration

Extraction non autorisée de données sensibles hors du dispositif ciblé (identifiants, TOTP, passkeys, clés privées).

Phishable

Qualifie un mécanisme (ex. passkeys synchronisées) susceptible d’être compromis par usurpation d’interface ou overlay — donc sujet au phishing.

Content-Security-Policy (CSP)

Politique web contrôlant ressources et origines ; utile mais insuffisante seule contre variantes avancées de clickjacking.

X-Frame-Options / frame-ancestors

En-têtes HTTP / directives CSP destinées à limiter l’inclusion en iframe ; contournables dans certains scénarios d’attaque avancés.

Keylogging

Capture malveillante des frappes clavier ; contournée par les injections HID sécurisées (pas de clavier logiciel ni de presse-papier).

Remarque : ce glossaire vise à uniformiser le vocabulaire technique employé dans la chronique. Pour les définitions normatives et les références standardisées, consultez OWASP, NIST et les RFC/standards FIDO/WebAuthn.