When a Spring application returns a 403 or 401 response before reaching a breakpoint inside a controller or service, the problem may not be in the logic the developer wants to inspect, but in the authorization layer that preceded request execution. IntelliJ IDEA provides a way to inspect the actual security rules in the running application and then temporarily grant the request an identity and permissions during a debugging session, without modifying SecurityConfig or restarting the application.
The feature is part of the Spring Debugger plugin in IntelliJ IDEA Ultimate and has been available since version 2026.2. Security inlays appear by default while the debugger is running, whether the application is local or running on a remote JVM.
Start by Finding Out What the Path Actually Requires
The editor or HTTP file interface displays the endpoint's role- and permission-based requirements, including rules based on hasRole and hasAuthority. IntelliJ IDEA does not rely here only on reading configuration files; it inspects the actual SecurityFilterChain inside the JVM after the Spring context has been initialized. This is important when multiple SecurityFilterChain instances, matcher ordering, active profiles, or conditional configuration registration affect the final result.
If a particular rule cannot be converted into a list of roles, as happens with some custom AuthorizationManager implementations, the rule appears as an unknown state, with a link to the relevant security configuration code. In this case, automatic opening based on a role list is unavailable, and referring back to SecurityConfig remains necessary.
Temporarily Open the Path During a Debugging Session
The Unlock action provides two options. The first forwards the request as authenticated with the set of roles required by the path, which is suitable when the developer wants to test the controller or service logic behind a protected path. The second allows specifying a username and a custom list of authorities, such as admin with ROLE_ADMIN and ROLE_MANAGER, to test application behavior under a particular set of permissions.
When the action is executed, the debugger creates a TestingAuthenticationToken object inside the SecurityContext of the running application. Checks such as hasRole and hasAuthority, as well as SecurityContextHolder.getContext().getAuthentication() and Principal or Authentication parameters, see the identity and permissions specified by the developer. The action does not change application code or configuration files, and unlocks disappear when the application is restarted, including an in-process restart through Spring Boot DevTools, or when the path is manually locked again.
The effect is not limited to the request sent from IntelliJ IDEA. Unlocking a GET request for a specific path affects any client that reaches the same URI and uses the same HTTP method, such as curl, Postman, or a browser. If a path pattern is opened in a controller definition, this may include all values matching the pattern. Therefore, the path should be locked again or the debugging session ended as soon as the work is complete, especially if the application is accessible over the network.
What Does Unlock Not Bypass?
The action does not disable Spring Security completely and does not bypass CSRF protection. If a POST, PUT, or DELETE request requires a valid CSRF token, CsrfFilter can still reject it. Its scope is also limited to endpoint authorization through AuthorizationFilter within the Servlet stack; it does not support Spring WebFlux, which uses AuthorizationWebFilter.
There is no direct interface for displaying or opening method-level security requirements such as @PreAuthorize, @PostAuthorize, and @Secured. Nevertheless, the permissions injected into the SecurityContext can later be read by method-security interceptors, so a service call protected with @PreAuthorize may pass if the granted permissions satisfy its condition. This does not mean that IntelliJ IDEA opened the method's own protection; rather, the check read the same synthetic authentication context.
Identity Limitations and Integration with Testing Tools
The identity created by the debugger is a textual username inside TestingAuthenticationToken, not the application's UserDetails or a custom user object type. Therefore, a parameter annotated with @AuthenticationPrincipal may return null, a known issue tracked as IDEA-389767 that affected version 2026.2 when the article was published.
Principal or Authentication can be used as the parameter type, but relying on a concrete type such as JwtAuthenticationToken may result in IllegalStateException because the injected object is not of that type. Results may also differ or parts may fail when they depend on claims, credentials, or an identity associated with a session or a specific type of authentication token.
Unlock works with requests coming from the embedded .http file or from curl, Postman, and testing frameworks, provided that the running application is the same application in which the path was opened. However, for automated workflows or workflows based on AI agents, there is currently no programmatic key for performing the operation. JetBrains plans to add an MCP tool and an associated skill in version 2026.3, but the current version requires an initial manual click from inside the IDE.
Why Does This Practice Matter?
The practical value here is not disabling security, but isolating the authorization layer from the logic the developer wants to test without leaving temporary modifications in configuration files that could be forgotten and reach another environment. At the same time, unlocking is a temporary security change in the running process, not a local simulation limited to an IDE request. It should therefore be treated as a narrowly scoped debugging tool, not a replacement for real authentication testing, with the path, method, and affected clients verified before use.
It is also important to note that the feature does not log a message or provide an indicator through Actuator when a path is opened in a remote application. According to the article, the state can be verified only through the interface in the IDE connected to the application. Security inlays can be disabled using spring.debugger.security.enabled in IntelliJ IDEA's Registry when they are not needed.