JetBrains’ IntelliJ IDEA introduces a runtime security inlay feature for Spring-based apps. When a request to a secured HTTP endpoint returns a 403 (or 401, or a redirect to a login page), you can now inspect the actual security requirements and proceed with debugging without editing SecurityConfig or restarting the application.
The inlay helps answer the core question developers face at that moment: which roles or authorities does the endpoint require? It is designed to reduce the temptation to disable security temporarily just to observe the underlying logic.
Security inlays are intended to let you inspect and adjust runtime security directly inside the IDE, rather than proceeding with code changes or external tooling.
WHAT THE INLAY REVEALS ABOUT ENDPOINT SECURITY
The inlay displays the role-based requirements for an endpoint, reflecting the hasRole/hasAuthority checks that govern most HTTP authorization. It also notes that not every rule can be shown—some custom rules may appear as unknown—so developers are encouraged to read the actual security configuration code behind the endpoint when needed. TechStaged has also covered Google teams with Cathay Pacific to expand AI-powered contrail avoidance in Asia-Pacific.
Reading the live SecurityFilterChain in a running application provides a real view of what an endpoint requires, beyond what is visible in source code alone.
UNLOCKING AN ENDPOINT FOR THE CURRENT DEBUG SESSION
Beyond observation, the feature lets you unlock a specific endpoint for the duration of the current debug session. Unlocking simulates authentication with a chosen username and authority set, applied to the exact request URI and HTTP method.
The mechanism inserts a TestingAuthenticationToken into Spring Security’s context, enabling you to test how controllers and downstream code behave under various authority configurations without touching production configuration or test data.
Unlocking does not modify the application code or permanently disable security; it only applies to the current debug session and to the selected URI/method.
LIMITATIONS AND CAVEATS
Unlocking targets the Servlet stack via Spring Security’s AuthorizationFilter; Spring WebFlux is not supported. Methods guarded by @PreAuthorize or other method-security checks may also be influenced by the same injected authentication, but unlocking does not target those annotations directly.
The scope is narrow: it applies to the exact request URI and method, and the lifetime lasts only for the running debug session. Restarting the application resets unlocked paths.
Security inlays are designed as a debugging aid, not a production control. They require the Spring Debugger to be active and can be turned off via a registry flag (spring.debugger.security.enabled). The feature also works with remote JVMs, with the caveat that there is no explicit production log or actuator indicator when an endpoint has been unlocked on a remote system.
WHAT THIS MEANS FOR DEVELOPERS
For developers debugging Spring Security-protected endpoints, the inlays offer a way to determine required roles quickly and test logic paths without modifying SecurityConfig or restarting services. This can streamline investigations into authorization failures and aid smoke testing of protected routes.
The documentation notes a known issue: in some cases, a controller parameter annotated with @AuthenticationPrincipal may resolve to null for inlay-unlocked requests (a bug tracked as IDEA-389767, with status referenced for 2026.2 at the time of writing).
As a caution, unlocking is a debugging aid and does not bypass CSRF protection for state-changing requests; valid tokens or exemptions remain necessary.
RELATED COVERAGE
- Google teams with Cathay Pacific to expand AI-powered contrail avoidance in Asia-Pacific
- JetBrains Rider 2026.3 EAP Opens with Rainbow Brackets, Data Breakpoints, and Game-Development Enhancements
- Kotlin 2.4.20 Released with Multiplatform Studio of Updates
- Claude Fable 5.1 lands on AWS amid AL2027 preview and new AI-focused credentials
- Software articles
SOURCES
- The JetBrains Blog: Debug Past an HTTP 403 Without Breaking Spring Security Published · Primary source
