# Qu’est-ce que la sécurité côté client ? La moitié de votre surface d’attaque que vous n’hébergez pas

> La sécurité côté client protège ce qui se passe dans le navigateur de vos visiteurs : XSS, compromission de scripts tiers, vol de session, clickjacking. Tour d’horizon des familles d’attaques et des défenses qui les couvrent : CSP, SRI, attributs de cookies et rapports de violation.

- Canonical: https://info.centralcsp.com/fr/articles/what-is-client-side-security/
- Published: 2026-08-09
- Language: fr
- Publisher: CentralCSP (https://centralcsp.com)

La **sécurité côté client** désigne la protection de tout ce qui se passe après que votre serveur a envoyé sa réponse : le JavaScript qui s’exécute dans le navigateur du visiteur, les scripts tiers que la page charge, les cookies que le navigateur détient et les contextes dans lesquels d’autres sites peuvent encadrer vos pages. Une part croissante des attaques réelles ne touche jamais votre infrastructure. Le code malveillant s’exécute sur une machine que vous n’avez jamais vue, dans un navigateur que vous n’opérez pas, contre un utilisateur que vous devez pourtant protéger.

## Sécurité navigateur contre sécurité serveur

La sécurité côté serveur, c’est la partie que tout le monde budgète : patcher l’OS, durcir le framework, scanner les dépendances, poser un WAF devant. Nécessaire, et aveugle à la suite.

Dès que la réponse quitte votre serveur, l’exécution change de mains. La page s’assemble dans le navigateur du visiteur, au milieu des scripts de votre CDN, de votre outil d’analytics, de votre prestataire de paiement. Vos logs affichent un 200 et un corps de réponse propre. Que cette page ait ensuite exécuté un script injecté, laissé fuiter un cookie de session ou envoyé des numéros de carte vers un serveur à l’étranger, vous ne le verrez pas de votre côté : aucun de ces flux ne passe par vous.

Cette asymétrie résume tout le sujet. Vous configurez le comportement du navigateur par des en-têtes et des attributs, mais vous ne l’opérez jamais.

## Les familles d’attaques qui vivent dans le navigateur

Quatre familles couvrent l’essentiel de ce que nous observons dans les données de violation.

### Le cross-site scripting : du code injecté qui s’exécute comme le vôtre

Un attaquant trouve un moyen de placer son script dans votre page, le plus souvent via une entrée réaffichée sans échappement correct. Le navigateur n’a aucun moyen de distinguer ce script du vôtre : il s’exécute avec toute l’autorité de votre origine, lit le DOM, observe les champs de formulaire, récupère les cookies non protégés par `HttpOnly` et envoie des requêtes au nom de l’utilisateur connecté. Le XSS trône en tête des statistiques de vulnérabilités depuis vingt ans : un seul oubli quelque part suffit. Nous détaillons le mécanisme dans [comment fonctionnent les attaques XSS](/fr/articles/how-xss-attacks-work/).

### La compromission de la chaîne d’approvisionnement : un script de confiance devient hostile

Ici, personne n’a rien injecté. Un script que vous chargez légitimement a changé sous vos pieds : CDN compromis, éditeur piraté, balise ajoutée dans un tag manager par quelqu’un du marketing. Les groupes Magecart ont industrialisé ce schéma contre les pages de paiement, en aspirant les numéros de carte à la saisie : British Airways a perdu environ 380 000 cartes en 2018 à cause d’un skimmer de ce genre. Vu du navigateur, le skimmer est une ressource autorisée comme une autre. Un scénario de détection concret est décrit dans [détecter une attaque Magecart avec la CSP](/fr/articles/catch-magecart-attack-csp/).

### Les attaques de session : le cookie est le butin

Souvent, le script n’est qu’un moyen. Ce que veut l’attaquant, c’est la session de votre utilisateur : un cookie lisible en JavaScript, un token posé dans le localStorage. Exfiltré une fois, il se rejoue depuis n’importe quelle machine, déjà authentifié, MFA déjà validée, sans un seul mot de passe à casser. Détails et parades dans [vol de cookies et détournement de session](/fr/articles/cookie-theft-session-hijacking/).

### Le clickjacking : votre interface dans la page de quelqu’un d’autre

La plus discrète des quatre familles, puisqu’aucun code n’est injecté. L’attaquant charge votre page dans une iframe invisible sur son propre site et superpose un appât : la victime clique sur votre vrai bouton « confirmer le virement » en croyant cliquer sur autre chose. Votre application se comporte exactement comme prévu. C’est bien le problème. Explication complète dans [le clickjacking expliqué](/fr/articles/clickjacking-explained/).

## La boîte à outils défensive, et ce que chaque pièce couvre

Aucun de ces outils ne couvre tout. Ensemble, ils couvrent beaucoup.

La [Content Security Policy](/fr/articles/what-is-a-content-security-policy/) est l’outil le plus large : un en-tête HTTP qui déclare depuis quelles sources la page peut charger scripts, styles et frames, et vers où elle peut envoyer des données. Un script inline injecté la viole. La requête d’exfiltration d’un skimmer vers une origine inconnue la viole aussi.

La Subresource Integrity (SRI) fige le contenu exact d’un script tiers grâce à un hash dans l’attribut `integrity`. Si le fichier sur le CDN change d’un octet, le navigateur refuse de l’exécuter. Parfait pour une bibliothèque statique, inutilisable pour un script qui évolue légitimement chaque semaine ([le fonctionnement des hashes SRI](https://centralcsp.com/fr/blog/subresource-integrity-sri)).

Les attributs de cookies limitent ce qu’un script hostile peut voler. `HttpOnly` rend le cookie invisible au JavaScript, `Secure` l’interdit hors HTTPS, et `SameSite` empêche la plupart des requêtes cross-site de l’emporter. Trois attributs, et le vol de cookie devient nettement plus difficile.

`frame-ancestors`, une directive CSP, contrôle qui a le droit de mettre vos pages dans une frame. Réglée sur `'self'` ou `'none'`, elle tue le clickjacking net. Elle remplace le vieil en-tête `X-Frame-Options`, en mieux.

Reste la surveillance, l’étape que la plupart des équipes sautent. Tout ce qui précède est de la configuration posée une fois, en espérant qu’elle tienne encore six mois plus tard. On ne corrige pas ce qu’on ne voit pas, et les navigateurs sont prêts à raconter ce qu’ils voient : le reporting de violations CSP est un canal de télémétrie natif, sans agent à installer. CentralCSP existe précisément pour cette couche : un endpoint managé vers lequel pointer un en-tête, des violations indexées par directive, origine et page, un inventaire de scripts construit depuis les rapports navigateur et des alertes quand un script inconnu apparaît là où il ne faudrait pas.

## Par où commencer

L’ordre des opérations, vécu : posez les attributs de cookies cet après-midi, ils ne cassent presque rien. Ajoutez `frame-ancestors`. Déployez ensuite une CSP en mode report-only avec le reporting pointé vers [CentralCSP](https://centralcsp.com), observez quelques semaines de trafic réel, construisez la politique à partir de ce qui se charge vraiment, puis passez en mode strict. La surveillance, elle, reste allumée : le côté client de votre site change à chaque mise en production d’un fournisseur, et désormais vous le saurez.

## Questions fréquentes

### Un site peut-il être piraté alors que le serveur est parfaitement sécurisé ?

Oui. Le XSS, le skimming Magecart ou le clickjacking se déroulent entièrement dans le navigateur du visiteur. Le serveur continue de renvoyer des réponses propres pendant que la page, une fois assemblée côté client, exécute du code hostile ou se retrouve encadrée sur le site d’un attaquant. Les logs serveur ne montrent rien d’anormal.

### Quelle différence entre sécurité côté client et sécurité côté serveur ?

La sécurité côté serveur protège une infrastructure que vous opérez : OS, framework, base de données. La sécurité côté client protège un environnement que vous ne faites que configurer : le navigateur du visiteur, où votre code s’exécute à côté de scripts tiers sur une machine que vous ne verrez jamais. Les outils diffèrent aussi : des en-têtes et des attributs plutôt que des correctifs et des pare-feu.

### Par quelle défense côté client commencer ?

Par une Content Security Policy, déployée d’abord en mode report-only. Elle couvre plusieurs familles d’attaques à la fois (scripts injectés, origines inconnues, exfiltration de données, framing via frame-ancestors) et ses rapports de violation vous montrent ce qui se charge réellement sur vos pages avant de bloquer quoi que ce soit.

### Faut-il un agent JavaScript sur mes pages pour surveiller les attaques côté client ?

Non. Les navigateurs remontent nativement les violations CSP via les mécanismes report-to et report-uri. Un seul en-tête HTTP pointant vers un endpoint de collecte suffit, sans aucun script ajouté à la page. Sur une page de paiement, où chaque script supplémentaire est lui-même un risque, ce détail compte.