Cuando una aplicación Spring devuelve una respuesta 403 o 401 antes de alcanzar un punto de interrupción dentro de un controlador o servicio, el problema puede no estar en la lógica que el desarrollador quiere inspeccionar, sino en la capa de autorización que precedió a la ejecución de la solicitud. IntelliJ IDEA ofrece una forma de inspeccionar las reglas de seguridad efectivas de la aplicación en ejecución y, a continuación, conceder temporalmente a la solicitud una identidad y permisos durante la sesión de depuración, sin modificar SecurityConfig ni reiniciar la aplicación.
La función forma parte del plugin Spring Debugger de IntelliJ IDEA Ultimate y está disponible desde la versión 2026.2. Security inlays aparece de forma predeterminada al ejecutar el depurador, tanto si la aplicación es local como si se ejecuta en una JVM remota.
Empieza por saber qué exige realmente la ruta
La interfaz muestra dentro del editor o del archivo HTTP los requisitos basados en roles y permisos del endpoint, incluidas las reglas basadas en hasRole y hasAuthority. IntelliJ IDEA no se limita aquí a leer los archivos de configuración, sino que inspecciona el SecurityFilterChain efectivo dentro de la JVM después de inicializar el contexto de Spring. Esto es importante cuando varias SecurityFilterChain, el orden de las coincidencias, los perfiles activos o el registro condicional de la configuración influyen en el resultado final.
Si una regla concreta no puede convertirse en una lista de roles, como ocurre con algunas implementaciones personalizadas de AuthorizationManager, la regla aparece como un estado desconocido, con un enlace al código de configuración de seguridad relacionado. En ese caso, no está disponible la apertura automática basada en una lista de roles y sigue siendo necesario volver a SecurityConfig.
Apertura temporal de la ruta durante la sesión de depuración
La acción Unlock ofrece dos opciones. La primera procesa la solicitud como autenticada con el conjunto de roles requeridos por la ruta, lo que resulta adecuado cuando el desarrollador quiere probar la lógica del controlador o servicio situado detrás de una ruta protegida. La segunda permite especificar un nombre de usuario y una lista de permisos personalizada, como admin con ROLE_ADMIN y ROLE_MANAGER, para probar el comportamiento de la aplicación con un conjunto concreto de permisos.
Al ejecutar la acción, el depurador crea un objeto TestingAuthenticationToken dentro del SecurityContext de la aplicación en ejecución. Las comprobaciones hasRole y hasAuthority, así como SecurityContextHolder.getContext().getAuthentication() y los parámetros Principal o Authentication, ven la identidad y los permisos especificados por el desarrollador. La acción no modifica el código de la aplicación ni los archivos de configuración, y las aperturas desaparecen al reiniciar la aplicación, incluido el reinicio dentro del proceso mediante Spring Boot DevTools, o al bloquear manualmente la ruta.
El efecto no se limita a la solicitud enviada desde IntelliJ IDEA. La apertura de un GET para una ruta específica afecta a cualquier cliente que acceda al mismo URI y método HTTP, como curl, Postman o el navegador. Si se abre un patrón de ruta en la definición del controlador, puede incluir todos los valores que coincidan con el patrón. Por ello, conviene volver a bloquear la ruta o finalizar la sesión de depuración en cuanto se termine, especialmente si la aplicación está disponible a través de la red.
¿Qué no omite Unlock?
La acción no desactiva Spring Security por completo ni omite la protección CSRF. Si una solicitud de tipo POST, PUT o DELETE necesita un token CSRF válido, CsrfFilter seguirá pudiendo rechazarla. Además, su alcance se limita a la autorización de endpoints mediante AuthorizationFilter dentro de la pila Servlet; no admite Spring WebFlux, que utiliza AuthorizationWebFilter.
Tampoco existe una interfaz directa para mostrar o abrir requisitos de protección a nivel de métodos, como @PreAuthorize, @PostAuthorize y @Secured. No obstante, los permisos inyectados en el SecurityContext pueden ser leídos posteriormente por un interceptor de protección de métodos, por lo que una llamada a un servicio protegido con @PreAuthorize podría pasar si los permisos concedidos cumplen su condición. Esto no significa que IntelliJ IDEA haya abierto la protección del método en sí, sino que la comprobación leyó el mismo contexto de autenticación artificial.
Limitaciones de identidad e integración con herramientas de prueba
La identidad que crea el depurador es un nombre de usuario textual dentro de TestingAuthenticationToken, no el UserDetails de la aplicación ni un tipo personalizado de objeto de usuario. Por ello, un parámetro anotado con @AuthenticationPrincipal puede devolver null; era un problema conocido con el número IDEA-389767 que afectaba a la versión 2026.2 en el momento de publicación del artículo.
Se puede utilizar Principal o Authentication como tipo del parámetro, pero depender de un tipo concreto como JwtAuthenticationToken puede provocar IllegalStateException, porque el objeto inyectado no pertenece a ese tipo. También pueden variar los resultados o fallar las partes que dependen de claims, credentials o de una identidad vinculada a una sesión o a un tipo específico de token de autenticación.
La apertura funciona con solicitudes procedentes del archivo .http integrado, o de curl, Postman y marcos de prueba, siempre que la aplicación en ejecución sea la misma en la que se abrió la ruta. Sin embargo, en flujos de trabajo automatizados o basados en agentes de inteligencia artificial, actualmente no existe una clave programática para ejecutar la operación. JetBrains planea añadir una herramienta MCP y una habilidad asociada en la versión 2026.3, pero la versión actual requiere un primer clic manual desde el IDE.
¿Por qué es importante esta práctica?
El valor práctico no consiste en desactivar la protección, sino en aislar la capa de autorización de la lógica que el desarrollador quiere probar sin dejar modificaciones temporales en los archivos de configuración que puedan olvidarse y llegar a otro entorno. En cambio, la apertura es un cambio de seguridad temporal en el proceso en ejecución, no una simulación local limitada a una solicitud del IDE. Por ello, debe considerarse una herramienta de depuración con alcance controlado, no un sustituto de las pruebas de autenticación reales, y conviene verificar la ruta, el método y los clientes afectados antes de utilizarla.
También hay que tener en cuenta que la función no registra ningún mensaje en los logs ni ofrece un indicador mediante Actuator al abrir una ruta en una aplicación remota. Según el artículo, el estado solo puede comprobarse mediante la interfaz del IDE conectado a la aplicación. Security inlays se puede desactivar mediante spring.debugger.security.enabled en el Registry de IntelliJ IDEA cuando no sea necesaria.