Risques liés à la sécurité des navigateurs : pourquoi le navigateur est le nouveau point d'accès

Le navigateur est le lieu de travail de vos collaborateurs. C’est là que les employés se connectent aux applications SaaS, collent des données clients dans des outils d’IA, téléchargent des fichiers sensibles, collaborent avec des partenaires externes et accèdent aux systèmes internes via l’authentification unique (SSO). Pourtant, la plupart des architectures de sécurité continuent de considérer le navigateur comme une application parmi tant d’autres sur le terminal — soumise aux mêmes politiques EDR génériques qu’un lecteur de PDF ou un client de messagerie. Cet écart entre la manière dont le travail s’effectue réellement et la manière dont la sécurité est appliquée constitue désormais le plus grand angle mort de la sécurité d’entreprise.

Les données de renseignement sur les menaces du secteur montrent que la grande majorité des intrusions survenues en 2024 ne faisaient pas appel à des logiciels malveillants, ce qui signifie qu’elles reposaient sur des identifiants légitimes, des flux d’identité fiables et des intégrations approuvées — des activités qui trouvent leur origine dans le navigateur et transitent par celui-ci. Si votre stratégie de sécurité s’arrête à l’agent de sécurité sur le terminal, vous défendez un périmètre qui ne correspond plus à la surface d’attaque.

La fuite de données en 90 secondes : un scénario que votre solution EDR ne détecte jamais

Imaginez un jeudi après-midi dans une entreprise de services financiers de taille moyenne. Une analyste senior ouvre Salesforce dans Chrome afin d’extraire les données trimestrielles relatives au chiffre d’affaires des clients en vue d’une analyse interne. Elle copie un tableau contenant 200 fiches clients — noms, montants des contrats, dates de renouvellement — et le colle dans ChatGPT, en lui demandant de rédiger un résumé pour sa réunion interfonctionnelle. Satisfaite du résultat, elle télécharge l’analyse générée par l’IA au format PDF et l’enregistre sur son OneDrive personnel afin de pouvoir la consulter sur son iPad pendant le week-end.

Toutes ces étapes se sont déroulées au cours d’une seule session de navigateur. L’agent de point de terminaison a détecté que Chrome effectuait des requêtes HTTPS. Le système DLP réseau a détecté un trafic chiffré vers des domaines autorisés. Aucun fichier n’a été enregistré sur le disque local avant le téléchargement final du PDF — moment auquel les données avaient déjà échappé au contrôle de l’entreprise dans deux directions : vers les serveurs de l’outil d’IA et vers un compte de stockage cloud personnel.

Il ne s'agit pas là d'un cas isolé hypothétique. C'est la réalité quotidienne au sein des organisations où le travail via navigateur a pris le pas sur les contrôles de sécurité liés au navigateur. Les attaquants utilisant l'intelligence artificielle ont considérablement intensifié leurs opérations d'année en année, et les intrusions s'effectuent désormais via des identités de confiance, des applications SaaS et l'infrastructure cloud. Lorsque le navigateur sert d'intermédiaire dans la quasi-totalité des interactions avec les données, et que votre infrastructure de sécurité n'a aucune visibilité sur ce qui se passe au sein de la session de navigation, vous agissez à l'aveuglette.

Pourquoi les anciennes approches échouent au niveau du navigateur

La plupart des infrastructures de sécurité d'entreprise ont été conçues pour un monde où les menaces se présentaient sous forme de fichiers, traversaient le réseau et atteignaient les terminaux. Cette architecture était efficace à l'époque où le travail s'effectuait dans des applications installées localement et où les données étaient stockées sur des serveurs de fichiers. Trois changements structurels ont bouleversé ce modèle.

Les agents de terminal ne peuvent pas accéder au contenu de la session du navigateur

Les outils EDR surveillent le comportement des processus, les écritures sur les fichiers et les appels système. Ils considèrent Chrome ou Edge comme un seul et même processus — et non comme les 30 onglets, les 5 applications SaaS et les 3 extensions de navigateur qui s’y exécutent. Lorsqu’un employé copie des données à caractère personnel d’un client depuis un onglet CRM et les colle dans un onglet d’assistant IA, l’agent de l’endpoint n’enregistre aucune activité suspecte. Il n’y a ni fichier, ni logiciel malveillant, ni processus anormal : il s’agit simplement d’une opération de presse-papiers entre deux contextes de navigateur.

Les solutions DLP réseau perdent en visibilité avec le chiffrement et le SaaS

Le chiffrement TLS et la transition vers le SaaS font que les appliances DLP réseau traditionnelles détectent du trafic chiffré vers des domaines autorisés. Elles ne peuvent pas faire la distinction entre un collaborateur qui télécharge une présentation marketing approuvée sur SharePoint et un autre qui télécharge une liste de clients sur son compte Dropbox personnel — dans les deux cas, cela ressemble à des requêtes POST HTTPS vers des services cloud reconnus. Le rapport DBIR 2025 de Verizon a confirmé que les identifiants volés constituaient le vecteur d’accès initial dans 22 % des violations de données, et que ces identifiants sont presque toujours saisis via un navigateur.

Les pare-feu basés sur les catégories d'URL ne tiennent pas compte des nuances

Les passerelles Web sécurisées traditionnelles, qui bloquent ou autorisent des domaines entiers, ne permettent pas d’appliquer les contrôles granulaires exigés par les flux de travail modernes des navigateurs. Bloquer purement et simplement ChatGPT risque d’aliéner les équipes soucieuses de leur productivité. L’autoriser ne permet quant à lui aucun contrôle sur les données que les employés y collent. Le modèle binaire « autoriser/bloquer » — conçu à une époque où « non sécurisé » signifiait « domaine malveillant connu » — est structurellement incapable de réguler l’utilisation des outils autorisés. Comprendre les différences entre les passerelles Web traditionnelles et celles de nouvelle génération constitue la première étape pour combler cette lacune.

Ce qui a changé : le navigateur est devenu le système d'exploitation professionnel

La convergence de trois tendances a transformé le navigateur, qui est passé d'un simple moteur de rendu à l'espace de travail principal de l'entreprise — et à sa surface d'attaque la plus exposée.

Le SaaS a pris le pas sur la pile applicative

Il y a cinq ans, les applications essentielles d’un employé du secteur des services comprenaient généralement des clients de messagerie installés localement, des suites bureautiques et des outils métier. Aujourd’hui, ce même employé accède à Salesforce, Microsoft 365, Workday, ServiceNow, Slack et Jira exclusivement via des onglets de navigateur. Chaque opération d’authentification, chaque interaction avec les données et chaque processus de collaboration passe par le navigateur. Les cybercriminels exploitent la confiance accordée aux systèmes d’identité dans le cloud, aux intégrations SaaS et aux flux d’authentification en tirant parti d’identifiants valides, de fournisseurs d’identité compromis et de jetons OAuth volés. Parmi les acteurs malveillants liés à des États, l’utilisation abusive de comptes valides représentait 35 % de l’ensemble des incidents liés au cloud, selon le rapport 2026 Global Threat Report de CrowdStrike.

GenAI a ouvert un nouveau canal d'exfiltration

Lorsqu’un collaborateur colle du code source propriétaire, des données clients ou des plans stratégiques dans un outil d’IA générative, c’est le navigateur qui sert de canal de transmission. Il n’y a aucun transfert de fichier que le système DLP au niveau des terminaux puisse inspecter, ni aucun e-mail sortant que la passerelle de messagerie puisse signaler. Les données transitent par un champ de texte du navigateur et, à moins que vous ne disposiez de contrôles au niveau de la session, elles circulent sans aucun contrôle de sécurité. À mesure que l’IA s’intègre aux plateformes SaaS et aux flux de travail opérationnels, les cybercriminels ont commencé à exploiter des outils GenAI légitimes au sein de dizaines d’organisations, en y injectant des invites malveillantes afin de voler des identifiants et des données.

Les accès non gérés et BYOD sont désormais la norme

La pandémie a banalisé l’utilisation d’ordinateurs portables de sous-traitants, d’appareils personnels et les modes d’accès via « votre propre navigateur », qui n’avaient jamais été couverts par les agents de sécurité des terminaux. Le rapport DBIR 2025 de Verizon a révélé que 46 % des appareils utilisant des identifiants d’entreprise dans les journaux des logiciels de vol d’informations n’étaient pas gérés — un écart dangereux entre le contrôle de l’entreprise et le comportement des utilisateurs. Lorsqu’un prestataire ouvre votre tenant Salesforce dans son navigateur personnel, votre agent EDR n’est pas en cours d’exécution, votre solution DLP réseau n’est pas activée en ligne et votre politique de catégorisation des URL n’est pas appliquée. La session de navigation est le seul point de contrôle dont vous disposez — et la plupart des organisations n’y ont mis en place aucune mesure.

Le manuel de l'adversaire : comment les risques liés aux navigateurs se concrétisent réellement

Pour bien comprendre les risques liés à la sécurité des navigateurs, il faut mettre en correspondance les techniques spécifiques utilisées par les attaquants avec la session de navigation. Deux catégories prédominent.

Vol d'identifiants et détournement de session

Le navigateur est le plus grand référentiel d’identifiants au monde. Les mots de passe enregistrés, les cookies de session, les jetons OAuth et les assertions SSO sont tous stockés dans le navigateur ou transitent par celui-ci. Les logiciels malveillants de type « infostealer » ciblent spécifiquement les référentiels d’identifiants des navigateurs, en récupérant les mots de passe enregistrés dans les profils Chrome, Edge et Firefox. Selon le rapport DBIR 2025 de Verizon, l’implication de tiers dans les violations de données a doublé pour atteindre 30 % de l’ensemble des incidents, souvent rendue possible par des identifiants volés lors de sessions de navigation sur des appareils non gérés. Prenons l’exemple d’un prestataire en marketing travaillant pour une entreprise du secteur de la santé qui réutilise son mot de passe SSO professionnel sur un site d’achats en ligne personnel. Ce site est piraté, le mot de passe apparaît dans une liste combinée, et un pirate se connecte au portail SSO du prestataire depuis un nœud de sortie VPN résidentiel. L’ensemble de la chaîne commence et se termine dans le navigateur.

Compromission de type « drive-by » et exploitation de failles de navigateur

La technique MITRE ATT&CK T1189, « Drive-by Compromise », décrit comment des attaquants peuvent accéder à un système par l’intermédiaire d’un utilisateur visitant un site web dans le cadre de sa navigation habituelle. Il ne s’agit pas d’une relique de l’époque d’Internet Explorer : 41 groupes malveillants et familles de logiciels malveillants connus ont été observés utilisant cette technique en conditions réelles. Les attaquants exploitent les mécanismes de notifications push des navigateurs pour diffuser des leurres de hameçonnage persistants et des redirections malveillantes qui survivent à la fermeture des onglets — car les autorisations de notifications push sont accordées au niveau du navigateur, et non au niveau de l’onglet. Contrairement aux exploits « drive-by » traditionnels, cette technique repose sur l’ingénierie sociale visant à inciter l’utilisateur à accorder les autorisations de notification, ce qui la rend efficace même contre des navigateurs entièrement mis à jour.

Les attaques de type « watering hole » modernes ciblent des sites web spécifiques à certains secteurs d’activité : elles consistent notamment à compromettre un portail fournisseur que votre équipe des achats consulte quotidiennement, à injecter du code JavaScript malveillant dans une page d’inscription à une conférence ou à diffuser des publicités malveillantes via des réseaux publicitaires légitimes. Gartner souligne que les correctifs « zero-day » pour Chromium peuvent mettre entre 24 et 72 heures à être déployés sur l’ensemble des navigateurs d’entreprise — une fenêtre d’exposition que les attaquants exploitent activement (Gartner, « Focus on Securing Browsers, Not Forcing a Secure Browser », octobre 2025). La technologie d’isolation des navigateurs existe précisément pour combler cette lacune en exécutant le contenu Web dans un environnement isolé avant de l’afficher à l’utilisateur.

L'ingénierie sociale à la vitesse d'un navigateur

Les opérations de hameçonnage vocal (vishing) ont connu une hausse spectaculaire en 2024 et jusqu’en 2025. Cisco Talos a ainsi indiqué que le vishing représentait plus de 60 % de l’ensemble des interventions liées à des incidents de hameçonnage au premier trimestre 2025, ce qui en fait le vecteur de hameçonnage le plus courant rencontré par son équipe. Bon nombre de ces campagnes redirigent les victimes vers des pages de collecte d’identifiants accessibles via un navigateur — des répliques parfaites, au pixel près, des écrans de connexion de Microsoft, Okta ou Google. Comme l’a récemment documenté Google Threat Intelligence (Mandiant), l’attaquant, se faisant passer pour un technicien du support informatique, redirige la victime vers un portail d’authentification unique (SSO) factice et capture en temps réel le mot de passe et le jeton d’authentification multifactorielle (MFA) au moment où la victime les saisit. L’ensemble de la chaîne d’attaque se déroule au sein du navigateur et ne laisse aucune trace de logiciel malveillant que l’agent de sécurité du terminal pourrait détecter.

Ce que les équipes de sécurité devraient faire dès maintenant

Pour combler cette lacune au niveau des navigateurs, il n’est pas nécessaire de supprimer l’infrastructure de sécurité existante ni d’imposer un navigateur propriétaire auquel les employés s’opposeraient. Il faut plutôt étendre les contrôles de sécurité éprouvés — DLP, CASB, SWG, RBI et ZTNA — à la session de navigation, là où les données circulent réellement.

Appliquez les contrôles des données au moment même où l'action est effectuée

Configurez des politiques DLP qui inspectent les opérations sur le presse-papiers, les téléchargements et les envois de fichiers, ainsi que les soumissions de champs de formulaire au cours des sessions de navigation. Lorsqu’un collaborateur copie une liste de clients depuis Salesforce et tente de la coller dans un outil d’IA non autorisé, la politique doit détecter le profil de données sensibles et bloquer le collage — et non pas simplement enregistrer l’événement trois jours plus tard. La plateforme SSE Skyhigh Security applique ces contrôles DLP en ligne sur les applications Web, SaaS et privées à partir d’un moteur de politiques unifié.

Isolez la navigation à haut risque sans la bloquer

Il n'est pas nécessaire de bloquer tous les sites web inconnus. Remote browser isolation affiche le contenu Web dans un conteneur cloud sécurisé et transmet une représentation visuelle au navigateur de l’utilisateur. Si un analyste des achats doit se rendre sur le portail d’un fournisseur qu’il ne connaît pas, l’isolation du navigateur à distance (RBI) lui permet de naviguer normalement tout en garantissant qu’aucun code malveillant n’atteigne son terminal. Il s’agit là de la réponse pratique à la norme MITRE ATT&CK T1189 : éliminer l’environnement d’exécution de l’exploit sans priver l’utilisateur de sa capacité à travailler.

Appliquer des contrôles au niveau de la session pour les appareils non gérés

Lorsque des sous-traitants, des partenaires ou des collaborateurs accèdent à des applications SaaS d’entreprise depuis leurs appareils personnels, mettez en place des contrôles de session basés sur un proxy inverse ou la technologie RBI qui empêchent les téléchargements, bloquent le copier-coller de contenus sensibles et apposent un filigrane sur les captures d’écran — le tout sans nécessiter d’agent sur le terminal. La norme NIST SP 800-207 définit le modèle « zero trust » comme une réponse aux évolutions des réseaux d’entreprise, notamment les utilisateurs à distance, le BYOD et les ressources basées sur le cloud, en mettant l’accent sur la protection des ressources plutôt que sur celle des segments de réseau. Les contrôles de session au niveau du navigateur constituent le point d’application qui rend ce principe opérationnel pour l’accès aux applications SaaS.

Obtenez une meilleure visibilité sur l'IA « fantôme » et les solutions SaaS non autorisées

Utilisez une combinaison CASB et SWG pour identifier et classer tous les outils d'IA et services cloud auxquels les collaborateurs accèdent via leur navigateur. Appliquez des politiques basées sur les risques : autorisez les outils GenAI approuvés avec contrôle DLP, accompagnez les utilisateurs concernant les services à risque moyen et bloquez les destinations à haut risque. Sans cette visibilité, chaque onglet de navigateur constitue un canal potentiel d'exfiltration.

Urgence et hiérarchisation des priorités : pourquoi cela ne peut pas attendre

Gartner prévoit que d’ici 2028, 25 % des organisations compléteront leurs outils existants d’accès à distance sécurisé et de sécurité des terminaux en déployant au moins une technologie de navigateur d’entreprise sécurisé. À l’heure actuelle, moins de 10 % d’entre elles ont adopté des navigateurs d’entreprise sécurisés. Cela signifie que la grande majorité des entreprises utilisent la même architecture de sécurité des navigateurs qu’il y a trois ans, alors que la surface d’attaque s’est considérablement élargie.

Le calcul est simple et défavorable. Selon le rapport 2025 de Verizon sur les enquêtes relatives aux violations de données (DBIR), l’utilisation abusive d’identifiants a constitué le principal vecteur d’accès initial aux violations : 22 % de toutes les violations confirmées, avec un chiffre stupéfiant de 88 % des attaques de base contre des applications web impliquant des identifiants volés. C’est souvent dans le navigateur que cet accès initial a lieu : via une page de hameçonnage, un flux OAuth compromis, une extension malveillante ou une attaque par « credential stuffing » contre une connexion SaaS. Le rapport DBIR a également fait état d’une recrudescence des méthodes de contournement de l’authentification multifactorielle (MFA), notamment l’interception de type « adversary-in-the-middle », le vol de jetons et le « prompt bombing », ce qui signifie que même les organisations ayant déployé la MFA ne sont pas à l’abri. Dès que l’attaquant dispose d’un jeton de session valide, il se trouve à l’intérieur de vos applications SaaS avec les mêmes droits d’accès que vos collaborateurs, et votre agent de terminal n’a rien à signaler.

Gartner souligne que les navigateurs basés sur Chromium représentent environ 75 % de la part de marché totale des navigateurs (« Focus on Securing Browsers, Not Forcing a Secure Browser », octobre 2025), ce qui fait du navigateur une surface d’attaque unique et dominante commune à presque toutes les entreprises. La question n’est pas de savoir s’il faut investir dans la sécurité des navigateurs. La question est de savoir s’il faut le faire dès maintenant — tant que vous avez encore le temps de mettre en place des mesures de contrôle — ou après qu’une violation liée à un navigateur vous y aura contraint.

Le modèle de maturité « Zero Trust » v2.0 de la CISA propose une approche permettant de mener à bien des efforts de modernisation continus liés au modèle « Zero Trust », articulés autour de cinq piliers : l’identité, les appareils, les réseaux, les applications et les charges de travail, ainsi que les données. Le navigateur se situe à la croisée de ces cinq piliers. C’est le terminal par lequel l’identité est vérifiée, l’application par laquelle on accède aux données, et la voie réseau par laquelle transite chaque transaction SaaS. La sécurisation de la session de navigation n’est pas un projet marginal : il s’agit d’une exigence fondamentale pour la maturité du modèle « Zero Trust ».

Élaborer une stratégie de sécurité pour les navigateurs : par où commencer ?

Les équipes de sécurité n'ont pas besoin de vouloir tout faire d'un coup. Établissez des priorités en fonction de l'exposition au risque et de la faisabilité opérationnelle.

Phase 1 — Visibilité (semaines 1 à 4). Activez la fonctionnalité de découverte CASB et la journalisation SWG afin d’identifier toutes les applications SaaS, tous les outils d’IA et tous les services cloud auxquels les collaborateurs accèdent via leur navigateur. Évaluez l’ampleur de l’utilisation de l’informatique parallèle et de l’IA parallèle. Identifiez les types de données sensibles qui transitent par les sessions de navigation.

Phase 2 — Contrôles en ligne (mois 2 à 3). Déployez les politiques DLP sur la secure web gateway afin d’inspecter les téléchargements, les opérations de copie/collage et les soumissions de formulaires. Commencez par les types de données présentant le plus grand risque : les informations personnelles identifiables (PII), les documents financiers, le code source et les données de santé soumises à une réglementation.

Phase 3 — Isolation et accès non gérés (mois 3 à 6). Activez remote browser isolation les catégories de sites Web à haut risque, les domaines non classés et les sessions SaaS sur des appareils non gérés. Mettez en œuvre des contrôles CASB par proxy inverse pour l'accès des prestataires et des utilisateurs BYOD aux applications SaaS critiques.

Phase 4 — Application continue (en cours). Intégrez les données télémétriques des sessions de navigateur à vos plateformes SIEM et XDR. Établissez des corrélations entre les événements liés au navigateur — lieux de connexion suspects, schémas d'accès inhabituels aux données SaaS, utilisation anormale des outils d'IA — et les signaux provenant des terminaux et des identités, afin de détecter les menaces de manière transversale.

Cette approche par étapes s'inscrit dans la lignée des recommandations de la norme NIST SP 800-207 et du modèle de maturité « Zero Trust » de la CISA, qui préconisent une progression progressive d'un niveau de maturité traditionnel vers un niveau optimal. Chaque étape réduit une surface de risque spécifique tout en contribuant à la mise en place d'une stratégie de sécurité globale pour les navigateurs.