Au-delà de l’injection de script, le navigateur expose une dernière surface d’attaque : celle de l’interface elle-même, et celle des ressources qu’il charge sans discernement suffisant. Une poignée d’en-têtes HTTP en referme la plus grande partie.
Le clickjacking
Le clickjacking (ou UI redressing) détourne l’interface utilisateur en superposant une iframe invisible, ou quasiment, contenant une action sensible. L’utilisateur croit cliquer sur un élément anodin — « Play video » — alors qu’il clique en réalité sur un bouton caché de l’application légitime, tel un « Confirmer le virement » positionné exactement au même endroit.
S’en protéger
Trois défenses se complètent, de la plus ancienne à la plus fine. L’en-tête historique X-Frame-Options accepte deux valeurs : DENY, qui interdit tout affichage en iframe, et SAMEORIGIN, qui ne l’autorise que depuis le même domaine.
La directive moderne frame-ancestors de la CSP la remplace avantageusement, avec une granularité plus fine :
Content-Security-Policy: frame-ancestors 'self' https://trusted-partner.com;
Enfin, le sandboxing d’iframe permet de restreindre précisément ce qu’une iframe intégrée peut faire — scripts, formulaires, popups, navigation :
<iframe sandbox="allow-forms"></iframe>Les en-têtes de sécurité HTTP
Une poignée d’en-têtes, spécifiés notamment dans les recommandations OWASP sur les en-têtes sécurisés, referment autant de surfaces d’attaque distinctes.
HSTS (Strict-Transport-Security) force le HTTPS sur l’ensemble du site, empêchant les attaques par rétrogradation vers HTTP en clair.
X-Content-Type-Options: nosniff empêche le navigateur de « deviner » le type MIME réel d’un fichier — un comportement qui, sans cet en-tête, peut transformer un fichier mal typé en vecteur de XSS.
Referrer-Policy contrôle ce que le navigateur transmet effectivement dans l’en-tête Referer, évitant la fuite de jetons ou d’identifiants exposés en clair dans une URL.
Permissions-Policy active ou désactive, à la granularité de la page, l’accès à des capacités sensibles du navigateur — caméra, micro, géolocalisation, plein écran, popups — réduisant d’autant la surface exposée à un script compromis.
Subresource Integrity (SRI) garantit qu’un script externe, chargé depuis un CDN, n’a pas été altéré entre sa publication et son chargement :
<script src="cdn.js" integrity="sha256-XYZ" crossorigin="anonymous"></script>Le navigateur calcule le hash du fichier reçu et refuse de l’exécuter s’il ne correspond pas à celui déclaré — une protection directe contre la compromission d’un CDN tiers.
Enfin, le blocage du contenu mixte empêche une page servie en HTTPS de charger silencieusement des ressources en HTTP, ce qui rouvrirait une fenêtre d’attaque de l’homme du milieu sur ces seules ressources.
Ce que ces en-têtes ont en commun
Aucun de ces mécanismes ne corrige une vulnérabilité applicative sous-jacente : ils réduisent, chacun à sa manière, ce qu’un navigateur est prêt à faire sans poser de question. C’est la même logique de moindre privilège qui traverse l’ensemble de la sécurité web — de la Same-Origin Policy à la défense contre le XSS en passant par ces en-têtes : ne jamais faire confiance par défaut, et rendre explicite chaque exception.