Lorsqu’une application Spring renvoie une réponse 403 ou 401 avant d’atteindre un point d’arrêt dans un contrôleur ou un service, le problème ne vient peut-être pas de la logique que le développeur souhaite examiner, mais de la couche d’autorisation qui a précédé l’exécution de la requête. IntelliJ IDEA propose une méthode pour examiner les règles de sécurité effectives de l’application en cours, puis accorder temporairement à la requête une identité et des autorisations pendant la session de débogage, sans modifier SecurityConfig ni redémarrer l’application.
Cette fonctionnalité fait partie du plugin Spring Debugger d’IntelliJ IDEA Ultimate et est disponible depuis la version 2026.2. Les Security inlays s’affichent par défaut pendant l’exécution du débogueur, que l’application soit locale ou exécutée sur une JVM distante.
Commencer par déterminer ce que le chemin exige réellement
L’interface de l’éditeur ou du fichier HTTP affiche les exigences fondées sur les rôles et les autorisations pour le point de terminaison, notamment les règles basées sur hasRole et hasAuthority. IntelliJ IDEA ne se contente pas ici de lire les fichiers de configuration : il examine le SecurityFilterChain effectif à l’intérieur de la JVM après l’initialisation du contexte Spring. Cela est important lorsque plusieurs SecurityFilterChain, l’ordre des correspondances, les profils actifs ou l’enregistrement conditionnel de la configuration influencent le résultat final.
Lorsqu’une règle donnée ne peut pas être convertie en liste de rôles, comme dans certaines implémentations personnalisées d’AuthorizationManager, la règle apparaît dans un état inconnu, avec un lien vers le code de configuration de sécurité concerné. Dans ce cas, l’ouverture automatique fondée sur une liste de rôles n’est pas disponible et il reste nécessaire de consulter SecurityConfig.
Ouvrir temporairement le chemin pendant la session de débogage
L’action Unlock propose deux options. La première transmet la requête comme étant authentifiée avec l’ensemble des rôles requis par le chemin ; elle convient lorsque le développeur souhaite tester la logique du contrôleur ou du service derrière un chemin protégé. La seconde permet de définir un nom d’utilisateur et une liste d’autorisations personnalisés, par exemple admin avec ROLE_ADMIN et ROLE_MANAGER, afin de tester le comportement de l’application avec un ensemble précis d’autorisations.
Lors de l’exécution de l’action, le débogueur crée un objet TestingAuthenticationToken dans le SecurityContext de l’application en cours d’exécution. Les vérifications hasRole et hasAuthority, ainsi que SecurityContextHolder.getContext().getAuthentication() et les paramètres Principal ou Authentication, voient l’identité et les autorisations définies par le développeur. L’action ne modifie ni le code de l’application ni les fichiers de configuration, et les ouvertures disparaissent lorsque l’application est redémarrée, y compris lors d’un redémarrage dans le processus via Spring Boot DevTools, ou lorsque le chemin est verrouillé manuellement.
L’effet ne se limite pas à la requête envoyée depuis IntelliJ IDEA. L’ouverture d’un chemin GET donné affecte tout client qui accède au même URI avec la même méthode HTTP, comme curl, Postman ou un navigateur. Si un motif de chemin est ouvert dans une définition de contrôleur, cela peut inclure toutes les valeurs correspondant à ce motif. Il convient donc de reverrouiller le chemin ou de mettre fin à la session de débogage dès que possible, en particulier si l’application est accessible via le réseau.
Que ne contourne pas Unlock ?
L’action ne désactive pas entièrement Spring Security et ne contourne pas la protection CSRF. Si une requête de type POST, PUT ou DELETE nécessite un jeton CSRF valide, le CsrfFilter pourra toujours la rejeter. Sa portée se limite également à l’autorisation des points de terminaison via AuthorizationFilter dans une pile Servlet ; Spring WebFlux, qui utilise AuthorizationWebFilter, n’est pas pris en charge.
Il n’existe pas d’interface directe permettant d’afficher ou d’ouvrir les exigences de protection au niveau des méthodes, telles que @PreAuthorize, @PostAuthorize et @Secured. Cependant, les autorisations injectées dans le SecurityContext peuvent ensuite être lues par un intercepteur de protection des méthodes. Ainsi, un appel de service protégé par @PreAuthorize peut aboutir si les autorisations accordées satisfont sa condition. Cela ne signifie pas qu’IntelliJ IDEA a ouvert la protection de la méthode elle-même, mais que la vérification a lu le même contexte d’authentification synthétique.
Limites de l’identité et intégration avec les outils de test
L’identité créée par le débogueur est un nom d’utilisateur textuel dans TestingAuthenticationToken, et non le UserDetails de l’application ni un type personnalisé d’objet utilisateur. Par conséquent, un paramètre annoté avec @AuthenticationPrincipal peut renvoyer la valeur null ; il s’agit d’un problème connu sous le numéro IDEA-389767, qui affectait la version 2026.2 au moment de la publication de l’article.
Principal ou Authentication peut être utilisé comme type de paramètre, mais dépendre d’un type concret tel que JwtAuthenticationToken peut provoquer une IllegalStateException, car l’objet injecté n’est pas de ce type. Les résultats peuvent également différer ou certaines parties peuvent échouer lorsqu’elles dépendent de claims, de credentials, d’une identité liée à une session ou d’un type précis de jeton d’authentification.
L’ouverture fonctionne avec les requêtes provenant du fichier .http intégré, de curl, de Postman et des frameworks de test, à condition que l’application en cours soit la même que celle dans laquelle le chemin a été ouvert. En revanche, pour les flux de travail automatisés ou reposant sur des agents d’intelligence artificielle, il n’existe actuellement aucune clé programmable permettant d’exécuter l’opération. JetBrains prévoit d’ajouter un outil MCP et une compétence associée dans la version 2026.3, mais la version actuelle nécessite un premier clic manuel depuis l’IDE.
Pourquoi cette pratique est-elle importante ?
La valeur pratique ne réside pas dans la désactivation de la protection, mais dans l’isolation de la couche d’autorisation par rapport à la logique que le développeur souhaite tester, sans laisser de modifications temporaires dans les fichiers de configuration qui pourraient être oubliées et parvenir dans un autre environnement. En revanche, l’ouverture constitue une modification de sécurité temporaire dans le processus en cours, et non une simulation locale limitée à une requête de l’IDE. Elle doit donc être considérée comme un outil de débogage à portée contrôlée, et non comme un substitut aux tests d’authentification réels ; il faut vérifier le chemin, la méthode et les clients concernés avant de l’utiliser.
Il faut également noter que la fonctionnalité n’enregistre aucun message dans les journaux et ne fournit aucun indicateur via Actuator lorsqu’un chemin est ouvert dans une application distante. Selon l’article, l’état ne peut être vérifié que depuis l’interface de l’IDE connecté à l’application. Les Security inlays peuvent être désactivés à l’aide du paramètre spring.debugger.security.enabled dans le Registry d’IntelliJ IDEA lorsqu’ils ne sont pas nécessaires.