Client Léger vs Client Lourd :
Cybersécurité en 2023–2025

Introduction

« Vous utilisez un navigateur pour travailler ? Vous êtes peut-être déjà une cible. »

Aujourd'hui, une grande partie des activités professionnelles repose sur des applications informatiques, accessibles soit via un navigateur web, soit via des logiciels installés localement.

Cette veille technologique a pour objectif de comparer les risques en cybersécurité selon deux architectures principales : le client léger (application web dans un navigateur) et le client lourd (logiciel installé localement).
Ces deux modèles présentent des différences majeures en termes de surface d'attaque, de vecteurs d'intrusion et d'impact en cas de compromission.

Problématique : Les risques de cybersécurité sont-ils identiques entre client léger et client lourd ?

Chiffres clés

+49 %

Attaques web en 2024 (Cloudflare)

62 M

Personnes exposées — MOVEit 2023

10 Md$

Coût estimé — MOVEit 2023

600 K

Entreprises exposées — 3CX 2023

Message clé : Le danger ne dépend pas du type de client lui-même, mais de la surface d'attaque exposée, de la qualité du code et de la gestion des mises à jour.

Définitions : Client Léger & Client Lourd

CLIENT LÉGER — Thin Client

Un client léger correspond à une application dont le traitement est majoritairement réalisé côté serveur. Le poste utilisateur agit principalement comme interface d'accès.

Caractéristiques :

  • ◈ Pas ou peu d'installation locale
  • ◈ Données hébergées côté serveur ou dans le cloud
  • ◈ Mises à jour centralisées et automatiques
  • ◈ Dépendance à une connexion réseau

Exemples :

  • ◈ Gmail, Google Docs, Salesforce
  • ◈ Applications web PHP (Laravel) ou Java (Spring Boot)
  • ◈ Terminaux virtuels: VDI, Citrix, accès distant via navigateur

CLIENT LOURD — Thick / Fat Client

Un client lourd est une application installée localement, contenant sa propre logique métier et pouvant fonctionner sans connexion permanente.

Caractéristiques :

  • ◈ Installation requise sur chaque poste
  • ◈ Données stockées localement ou synchronisées
  • ◈ Mises à jour dépendantes de l'utilisateur ou de l'administrateur
  • ◈ Fonctionnement possible hors ligne

Exemples :

  • ◈ Microsoft Office, Adobe, Visual Studio
  • ◈ Applications Java Swing / JavaFX
  • ◈ Outils de transfert: MOVEit Transfer, FileZilla, Outlook

Résultats de la veille technologique

Comparaison cybersécurité : différences clés
Critère Client Léger Client Lourd
Surface d'attaque Navigateur + serveur web + API App locale + OS + fichiers locaux
Vecteur s'attaque XSS, SQLi, vol de session, CSRF Failles logicielles, désérialisation, RCE
Impact Une faille serveur impacte tous les utilisateurs Impact local, mais persistant
Mise à jour Centralisées et immédiates Dépendantes de chaque poste
Surveillance Logs centralisés — SIEM facile Logs distribués — difficile à centraliser
Exemples Laravel web, Spring Boot MVC Application Java Swing / Log4j, MOVEit installé
Critère Client Lourd
Surface d'attaque App locale + OS + fichiers locaux
Vecteur d'attaque Failles logicielles, désérialisation, RCE
Impact Impact local, mais persistant
Mise à jour Dépendantes de chaque poste
Surveillance Logs distribués — difficile à centraliser
Exemples Application Java Swing / Log4j, MOVEit installé

Point clé : Le client léger centralise le risque côté serveur, tandis que le client lourd le distribue sur chaque poste.

1. Risques du Client Léger — Failles & Exemples

Les clients légers exposent principalement les serveurs et les sessions utilisateurs. Une vulnérabilité côté serveur peut affecter l'ensemble des utilisateurs simultanément.

Injections web

XSS, SQL, CSRF : failles liées à des entrées non sécurisées.

Exemple PHP : utilisation de $_GET sans requêtes préparées → injection SQL

Vol de session

Cookies ou tokens interceptés dans le navigateur.

Exemple : attaque Okta 2023 — 134 clients impactés via un cookie volé dans le navigateur d'un technicien.

Mauvaise configuration des API

Endpoints sensibles accessibles sans authentification.

Exemple : endpoint /actuator Spring Boot laissé ouvert sans Spring Security.

Attaques réelles — Client Léger (2023–2024) :

Attaque Type Vecteur / Impact
Okta (2023) SaaS / Navigateur Cookie de session volé → accès à Cloudflare, 1Password, BeyondTrust.
134 clients impactés. Okta gère +17 000 entreprises.
CitrixBleed CVE-2023-4966 VDI / Client léger Fuite mémoire → vol de tokens actifs. Contourne le MFA. Exploité par LockBit, Medusa.
+10 000 serveurs exposés. Boeing, ICBC victimes.
Magecart / Magento (2024) App web PHP JS malveillant injecté dans pages de paiement PHP.
CosmicSting : 75 % des plateformes touchées. 70 000+ boutiques, 380 000 clients British Airways.
2. Risques du Client Lourd — Failles & Exemples

Les clients lourds distribuent le risque sur chaque poste individuel. Chaque machine non mise à jour représente une porte d'entrée indépendante, potentiellement ouverte indéfiniment.

Patch non appliqué

Faille connue, correctif disponible, mais non installé sur le poste.

Exemple : MOVEit 2023 — le patch existait avant l'exploitation

Version End of Life

L'éditeur arrête les correctifs → toute nouvelle CVE reste non corrigée.

Exemple : PHP 7.4 encore utilisé après fin de support

Dépendances non mises à jour

Librairies vulnérables intégrées à l'application.

Exemple : Log4j 2.14 → Log4Shell CVSS 10/10, encore actif en 2024.

Supply Chain

La mise à jour officielle elle-même est compromise par un attaquant.

Exemple : 3CX 2023 (Lazarus) — 600 000 entreprises exposées.

Attaques réelles — Client Lourd (2023–2024) :

Attaque Type Vecteur / Impact
MOVEit CVE-2023-34362 Logiciel installé Injection SQL → accès sans authentification. Patch disponible le jour J.
+2 500 organisations touchés, 62 M personnes exposées, +10 Md$. BBC, Shell, gouvernement Canada.
3CX Supply Chain (2023) Mise à jour compromise Lazarus Group compromet le build officiel de 3CX. La mise à jour contenait un malware.
600 000 entreprises potentiellement exposées.
Log4Shell CVE-2021-44228 Java client lourd CVSS 10/10. App Java avec Log4j 2.14 → prise de contrôle complète.
En 2024 : 37 % des téléchargements Log4j = version vulnérable. Apple, Amazon, Tesla touchés.
3. Java : Client Léger ET Client Lourd — Log4Shell illustre les deux

Log4Shell (CVE-2021-44228 — CVSS 10/10) illustre parfaitement l'impact différent selon l'architecture.

Java — Client Léger (web)

Spring Boot MVC servi via navigateur.

  • ◈ Faille Log4Shell côté serveur
  • 1 patch serveur = tous les utilisateurs sont protégés instantanément
  • ◈ Correction rapide et centralisée
  • ◈ Exemple : API REST Java en production avec Log4j → patch en 1 seul déploiement

Java — Client Lourd (installé)

App Java Swing / JavaFX installée localement.

  • ◈ Faille Log4Shell sur chaque poste
  • Chaque poste doit être mis à jour individuellement
  • ◈ Un poste oublié = faille ouverte des mois
  • ◈ En 2024 : 37 % des téléchargements Log4j = version vulnérable

Conclusion : Une même faille peut avoir un impact radicalement différent selon l'architecture.

4. Tableau de synthèse des attaques récentes
Attaque Type client Année Impact
Okta Léger (SaaS) 2023 134 clients
CitrixBleed CVE-2023-4966 Léger (VDI) 2023 +10 000 serveurs
Magecart / Magento Léger (PHP) 2024 70 000+ boutiques
MOVEit CVE-2023-34362 Lourd (installé) 2023 62 M personnes, 10 Md$
3CX Supply Chain Lourd (installé) 2023 600 000 entreprises
Log4Shell (Java local) Lourd (Java) 2021–24 CVSS 10/10, millions postes

Observation : Dans tous ces cas, la cause racine est la même — code vulnérable, dépendances non mises à jour ou absence de patch.
Le type de client ne détermine pas la gravité d'une faille, mais la manière dont elle se propage.

Bonnes pratiques — Client Léger & Client Lourd
Domaine Client Léger Client Lourd
Mises à jour Patch serveur immédiat → tous protégés Automatisation du patch poste
End of Life Vérification du support PHP/Java (EOL = danger) Changement de version avant fin de support
Dépendances composer audit, npm audit OWASP Dependency-Check Java/Maven
Authentification MFA + gestion sessions, OAuth scopes minimaux MFA + credentials forts, pas de comptes partagés
Moindre privilège RBAC, pas d'endpoint sensible exposé (/actuator) Pas d'admin local inutile, droits utilisateurs limités
Surveillance WAF + logs centralisés (SIEM) EDR sur chaque poste + centralisation logs
Chiffrement HTTPS / TLS obligatoire (HSTS) Chiffrement disque (BitLocker, FileVault)
Domaine Client Lourd
Mises à jour Automatisation du patch poste
End of Life Changement de version avant fin de support
Dépendances OWASP Dependency-Check Java/Maven
Authentification MFA + credentials forts, pas de comptes partagés
Moindre privilège Pas d'admin local inutile, droits utilisateurs limités
Surveillance EDR sur chaque poste + centralisation logs
Chiffrement Chiffrement disque (BitLocker, FileVault)
Conclusion — 3 messages à retenir
1

Client Léger

Le risque est centralisé : une seule faille serveur peut impacter tous les utilisateurs.

2

Client Lourd

Le risque est distribué : chaque poste non mis à jour reste vulnérable.

3

La vraie protection

  • ◈ Patch management
  • ◈ Gestion des dépendances
  • ◈ MFA
  • ◈ Surveillance

« La sécurité n'est pas une caractéristique du logiciel. C'est une pratique continue, quel que soit le type de client. »

Un développeur qui connaît les failles de son environnement vaut mieux que n'importe quel antivirus.
Glossaire des termes techniques
  • API permet à des applications de communiquer entre elles.
  • API REST utilise le protocole HTTP et des méthodes standards (GET, POST, etc.) pour échanger des données.
  • CSRF — Cross-Site Request Forgery : Le pirate fait exécuter une action à la victime sans qu'elle le sache (exemple : transfert bancaire automatique depuis un site piégé).
  • CVSS : notation de 0 à 10 de la gravité d'une faille.
  • CVE : répertoire officiel des failles connues (exemple : CVE-2023-34362).
  • End of Life (EOL) : Quand un éditeur arrête le support d'une version, toute nouvelle CVE découverte après cette date ne sera jamais corrigée.
  • HTTPS : protocole sécurisé utilisant TLS pour chiffrer les communications.
  • HSTS force l'utilisation exclusive de connexions sécurisées.
  • MVC : Architecture qui sépare les données, l'interface utilisateur et la logique de traitement pour mieux organiser une application.
  • MFA : Méthode d'authentification qui combine plusieurs facteurs (mot de passe, code, biométrie) pour renforcer la sécurité des accès.
  • Patch : Mise à jour logicielle visant à corriger des vulnérabilités ou des failles de sécurité.
  • RCE — Remote Code Execution : Le pire scénario c'est quand un attaquant peut exécuter du code sur la machine victime à distance. Souvent noté CVSS 9 ou 10/10.
  • SaaS : Modèle où une application est accessible via Internet sans installation locale, généralement via un navigateur.
  • SQLi : Injection de code malveillant dans une requête vers une base de données.
  • WAF : pare-feu applicatif web.
  • SIEM : centralise et analyse les logs.
  • EDR : détection et réponse sur chaque poste
  • XSS — Cross-Site Scripting : Injection de code JavaScript malveillant dans une page web, exécuté dans le navigateur d'autres utilisateurs.

Alertes et CVE officielles

  • ◈ CERTFR-2023-ALE-012 – Vulnérabilité CitrixBleed (CVE-2023-4966). URL
  • ◈ CERTFR-2023-ALE-005 – Vulnérabilités MOVEit Transfer. URL
  • ◈ CERTFR-2023-ALE-003 – Vulnérabilités 3CX Desktop App. URL
  • ◈ CISA – Cybersecurity and Infrastructure Security Agency. URL
  • ◈ MITRE – Base officielle des CVE. URL
  • ◈ NVD – National Vulnerability Database. URL

Attaques et analyses

  • ◈ Ransomware LockBit et faille CitrixBleed. URL
  • ◈ Analyse de l'attaque Okta 2023. URL
  • ◈ Log4Shell – Sophos. URL
  • ◈ Sansec (sécurité e-commerce / Magecart). URL
  • ◈ Emsisoft – Rapport MOVEit. URL

Documentation officielle

  • ◈ Apache Software Foundation : Log4j Security Vulnerabilities. URL
  • ◈ Spring Boot : Documentation officielle Actuator. URL
  • ◈ Magento / Adobe Commerce. URL
  • ◈ OWASP (vulnérabilités XSS, CSRF, etc.). URL
  • ◈ Cloudflare Radar (statistiques attaques web). URL