CSP sur Entra ID : fin des scripts injectés dès mi-octobre 2026

Un admin IT installe une extension Chrome qui ajoute un bandeau d’avertissement sur la page de connexion de son organisation, histoire de rappeler aux utilisateurs de vérifier l’URL avant de taper leur mot de passe. Bonne intention, mauvais moment : à partir de la mi-octobre 2026, ce genre d’extension va simplement arrêter de fonctionner sur login.microsoftonline.com, sans message d’erreur visible pour l’utilisateur final. La page de connexion, elle, continuera de marcher normalement.

C’est l’effet de la nouvelle Content Security Policy (CSP) que Microsoft déploie sur l’expérience de connexion Entra ID. Le changement a été annoncé au Message Center en décembre 2025 (référence MC1191924) et son application globale démarre mi-à-fin octobre 2026, selon la documentation officielle Microsoft Learn. Si tu gères des tenants Entra ID, voici ce qui change concrètement et ce qu’il faut vérifier avant que ça tombe.

Ce durcissement s’inscrit dans une série de resserrements de la sécurité d’authentification Entra ID en 2026, après le passage des passkeys en méthode d’authentification par défaut cet été. Même logique de fond : réduire la surface d’attaque côté navigateur sans attendre que l’utilisateur agisse.

Le problème que Microsoft referme

La cible, c’est l’injection de scripts externes sur la page de connexion : attaque XSS classique, extension de navigateur malveillante, ou simplement un outil tiers qui modifie le DOM de la page pour y ajouter du contenu. Dans les trois cas, du code qui n’a pas été écrit par Microsoft s’exécute dans le contexte de la page où l’utilisateur tape son mot de passe. Les conséquences possibles sont connues : vol de identifiants ou de tokens, prise de contrôle de session, ou simplement perte de confiance si la page de connexion se comporte de façon inattendue.

Microsoft précise dans sa documentation que les mécanismes existants (filtrage côté navigateur, protections natives d’Entra ID) restent la première ligne de défense. La CSP s’ajoute en profondeur, pour les cas où un script arrive malgré tout à s’injecter — via une extension installée localement ou une faille zero-day. Le principe d’une CSP, détaillé par l’OWASP Cheat Sheet dédiée, est simple : une liste blanche de domaines et de scripts autorisés, tout le reste est bloqué par défaut, sans exception.

La presse spécialisée en sécurité a repris l’annonce quelques jours avant son entrée en vigueur — BleepingComputer note que la majorité des violations observées par Microsoft en amont provenaient d’extensions de navigateur tierces, pas d’attaques ciblées.

Ce qui change exactement

Concrètement, Microsoft Entra ID impose un en-tête CSP qui n’autorise à s’exécuter que les scripts provenant de domaines Microsoft de confiance. Trois précisions importantes, directement issues de la documentation officielle :

• L’application ne concerne que les connexions via navigateur, sur login.microsoftonline.com précisément. Les autres domaines ne sont pas touchés par ce changement.
• Les flux basés sur MSAL (Microsoft Authentication Library) qui interrogent directement les API du service de jetons de sécurité (STS) d’Entra ID ne sont pas affectés, puisque l’application se limite à l’URL de connexion navigateur.
• Les clients Microsoft Entra External ID utilisant un domaine personnalisé ou un domaine CIAM ne sont pas impactés non plus.

Si ton organisation n’utilise aucun outil ni extension qui injecte du code dans la page de connexion, l’expérience ne change strictement rien pour tes utilisateurs — Microsoft le dit explicitement, et c’est le cas de la grande majorité des tenants. Le changement vise les 10-15% de cas où un outil tiers s’appuie sur cette pratique, d’après l’analyse de Microsoft sur l’origine des violations qu’elle observe actuellement en amont du rollout.

Qui risque d’être concerné

D’après les retours déjà documentés, les cas les plus fréquents de script injecté sur une page de connexion sont :

• des extensions de navigateur de sécurité ou de productivité (gestionnaires de mots de passe tiers, outils de monitoring, bloqueurs de contenu) qui modifient le DOM des pages visitées ;
• des outils de supervision ou de test (certains frameworks d’automatisation UI, des extensions de débogage) laissés actifs en dehors d’un contexte de développement ;
• des solutions de marque blanche ou de personnalisation visuelle qui injectent du JavaScript plutôt que de passer par les mécanismes de branding natifs d’Entra ID (logo, bandeau, texte personnalisé — ces options-là restent disponibles et ne sont pas concernées par la CSP).

Le point à retenir : ce n’est pas ta personnalisation de marque qui casse, c’est tout ce qui s’exécute en JavaScript injecté par-dessus la page plutôt que configuré nativement.

Comment tester ton tenant avant le rollout

Microsoft Learn détaille une méthode de test simple, à faire dès maintenant plutôt que d’attendre le jour J :

1. Ouvre la console développeur de ton navigateur (F12 sous Chrome ou Edge) avant de lancer un flux de connexion vers ton tenant.
2. Déroule un parcours de connexion complet en gardant la console ouverte.
3. Repère les violations CSP, qui s’affichent en rouge dans la console et identifient précisément le script bloqué et son origine.
4. Répète le test avec les différents profils et postes utilisés dans ton organisation (extensions installées, outils de support, postes partagés) — une violation causée par l’extension d’une seule équipe ne remontera que sur les parcours de connexion de cette équipe.

Si un outil tiers déclenche une violation, la recommandation officielle est de contacter l’éditeur pour obtenir une version compatible avec la CSP, plutôt que de chercher un contournement — il n’y a pas d’option tenant pour désactiver cette CSP, contrairement à ce qu’on peut faire sur un site Power Pages par exemple.

FAQ

Est-ce que ça bloque la connexion des utilisateurs ?

Non. Les utilisateurs peuvent continuer à se connecter normalement même si un script tiers est bloqué par la CSP. Ce qui casse, c’est le comportement ajouté par ce script précis (bandeau, overlay, tracking) — pas le flux d’authentification lui-même.

Faut-il activer quelque chose dans le tenant ?

Non, l’application est activée par défaut, sans configuration côté tenant. C’est justement l’absence de bouton pour la désactiver qui en fait une protection fiable à l’échelle de tous les tenants Entra ID — mais ça veut aussi dire qu’il faut tester en amont, pas réagir après coup.

Mes personnalisations de marque (logo, couleurs) vont-elles disparaître ?

Non, les mécanismes de branding natifs d’Entra ID (Company Branding) ne passent pas par de l’injection de script et ne sont pas concernés.

Et si on utilise MSAL pour une appli custom ?

Pas d’impact. L’application de la CSP se limite à la page de connexion navigateur sur login.microsoftonline.com ; les flux MSAL qui parlent directement aux API du STS Entra ID restent inchangés.

Ce qu’il faut faire cette semaine

Si tu n’as encore rien testé, le test console décrit plus haut prend cinq minutes et peut t’éviter un ticket de support en pleine mi-octobre. Fais-le sur un compte de test avec les extensions réellement utilisées par tes équipes support et sécurité — c’est là que se cachent la plupart des violations, pas dans la configuration Entra ID elle-même. Si ton organisation personnalise déjà la page de connexion via les Conditional Access ou le Company Branding plutôt que du script injecté, cette échéance ne te concerne tout simplement pas.

Et si tes politiques de Conditional Access couvrent déjà des identités non humaines (agents IA, comptes de service), ça vaut le coup de revérifier leur posture pendant que tu y es — on a détaillé comment sécuriser les identités d’agents IA dans Entra ID dans un article précédent.