Clickjacking et en-têtes de sécurité HTTP (CSP, X-Frame-Options)

Certaines failles ne s’attaquent ni au serveur ni aux scripts : elles jouent sur ce que l’utilisateur voit. C’est le cas du clickjacking, où l’on pousse quelqu’un à cliquer sur un bouton légitime sans qu’il s’en rende compte. La bonne nouvelle : une famille d’en-têtes HTTP, ajoutés par le serveur, offre une défense efficace contre cette faille et contre beaucoup d’autres du chapitre. Cette leçon boucle le chapitre 4 en vous les présentant.

Le clickjacking : le principe

Les navigateurs permettent à une page d’en inclure une autre dans un cadre (une iframe). C’est utile : vidéos intégrées, cartes, formulaires de paiement. Mais cela ouvre une possibilité : une page piégée peut inclure le vrai site dans un cadre transparent, placé au-dessus d’un faux contenu attractif (« Cliquez pour gagner »). La victime croit cliquer sur le faux bouton, mais son clic atterrit sur un vrai bouton du site, par exemple « Supprimer le compte » ou « Autoriser ».

Analogie : une vitre transparente posée sur un distributeur de billets. Vous croyez appuyer sur la touche « Valider » du dessin, mais votre doigt appuie sur la vraie touche de la machine en dessous.

Comme dans le CSRF, la victime est connectée et le site reçoit une action légitime en apparence. Mais ici, l’action est réellement cliquée par l’utilisateur : un jeton anti-CSRF ne protège donc pas contre le clickjacking. Il faut une défense spécifique.

Comment tester si un site peut être mis en cadre

Le test ne nécessite aucune page piégée : il suffit d’examiner les en-têtes de la réponse HTTP. Deux mécanismes interdisent à d’autres sites d’inclure la page :

Si aucun des deux n’est présent sur une page sensible, la page peut être incluse n’importe où : constat de clickjacking potentiel. Les pages sans action sensible (page d’information statique) sont moins préoccupantes.

La Content-Security-Policy (CSP)

La CSP est l’un des outils les plus puissants du web moderne. C’est une liste de règles, envoyée par le serveur dans un en-tête, qui indique au navigateur ce qu’il a le droit de charger et d’exécuter : d’où viennent les scripts, les images, les feuilles de style, quels sites peuvent inclure la page… Une règle simple :

Content-Security-Policy: default-src 'self'; script-src 'self'; frame-ancestors 'none'; object-src 'none'; base-uri 'self'

Cette politique dit : par défaut, ne charger des ressources que depuis le site lui-même ; n’exécuter de scripts que ceux du site ; interdire toute mise en cadre ; interdire les objets embarqués ; restreindre l’adresse de base. Une page protégée ainsi empêche, en pratique, l’exécution de scripts injectés (XSS) venant d’une source non autorisée.

Points d’attention pour l’auditeur :

• Une CSP qui autorise les scripts « en ligne » sans restriction ('unsafe-inline') perd l’essentiel de son intérêt contre le XSS.
• Une CSP qui autorise des domaines très larges (ou « tout », avec une étoile) est très peu protectrice.
• La CSP est une défense en profondeur : elle ne remplace pas l’encodage de sortie.
• Un mode « rapport seul » permet de tester une politique sans bloquer, utile lors d’un déploiement progressif.

La documentation complète figure sur developer.mozilla.org, rubrique des en-têtes HTTP.

Les autres en-têtes de sécurité à connaître

Ces en-têtes ne corrigent pas une faille du code, mais ils réduisent la surface d’attaque et l’impact d’éventuelles failles. Un audit vérifie leur présence et leur pertinence, sans les surévaluer : l’absence d’un en-tête est rarement un constat « critique » à elle seule, mais s’inscrit dans une approche de défense en profondeur.

Auditer les en-têtes en pratique

1. Chargez une page de votre application d’entraînement avec le proxy actif.
2. Dans l’historique, ouvrez la réponse et lisez ses en-têtes.
3. Pour chaque en-tête du tableau ci-dessus, notez : présent ou absent ; si présent, valeur et pertinence.
4. Vérifiez aussi les en-têtes inutiles qui divulguent des informations (version du serveur, technologie), dont nous reparlerons au chapitre 6.

Voici un extrait d’en-têtes de réponse bien configurés, à titre d’exemple générique :

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Content-Security-Policy: default-src 'self'; frame-ancestors 'none'
Referrer-Policy: strict-origin-when-cross-origin

Les valeurs dépendent de chaque application : une CSP trop stricte peut casser des fonctionnalités légitimes. Elle se met donc au point en testant, d’abord en mode rapport.

À vous de jouer

1. Relevez les en-têtes de réponse de trois pages de votre application d’entraînement (accueil, connexion, une page de modification).
2. Complétez un tableau avec les en-têtes du chapitre : présent, absent, valeur.
3. Choisissez la page où l’absence de protection contre la mise en cadre est la plus préoccupante, et expliquez pourquoi.
4. Rédigez une CSP minimale que vous recommanderiez pour cette application, et expliquez ce que chaque directive apporte.

Les failles côté client n’ont plus de secret pour vous. Le chapitre suivant aborde une question plus subtile : l’application vérifie-t-elle bien que chacun ne fait que ce qu’il a le droit de faire ?