Quando uma aplicação Spring retorna uma resposta 403 ou 401 antes de chegar a um ponto de interrupção dentro de um controlador ou serviço, o problema pode não estar na lógica que o desenvolvedor deseja examinar, mas na camada de autorização que precedeu a execução da solicitação. O IntelliJ IDEA oferece uma maneira de examinar as regras de proteção efetivas na aplicação em execução e, em seguida, conceder à solicitação uma identidade e permissões temporárias durante a sessão de depuração, sem modificar o SecurityConfig nem reiniciar a aplicação.
O recurso faz parte do plugin Spring Debugger no IntelliJ IDEA Ultimate e está disponível desde a versão 2026.2. Os Security inlays aparecem por padrão durante a execução do depurador, independentemente de a aplicação ser local ou estar sendo executada em uma JVM remota.
Comece descobrindo o que o caminho realmente exige
A interface dentro do editor ou do arquivo HTTP exibe os requisitos baseados em funções e permissões para o endpoint, incluindo regras baseadas em hasRole e hasAuthority. O IntelliJ IDEA não depende aqui apenas da leitura dos arquivos de configuração: ele examina o SecurityFilterChain efetivo dentro da JVM após a inicialização do contexto do Spring. Isso é importante quando vários SecurityFilterChain, a ordem dos matchers, os perfis ativos ou o registro condicional das configurações influenciam o resultado final.
Se uma determinada regra não puder ser convertida em uma lista de funções, como ocorre com algumas implementações personalizadas de AuthorizationManager, a regra será exibida como um estado desconhecido, com um link para o código de configuração de segurança relevante. Nesse caso, a abertura automática baseada na lista de funções não estará disponível, e ainda será necessário consultar o SecurityConfig.
Abertura temporária do caminho durante a sessão de depuração
A ação Unlock oferece duas opções. A primeira encaminha a solicitação como autenticada com o conjunto de funções exigido pelo caminho, o que é adequado quando o desenvolvedor deseja testar a lógica do controlador ou serviço por trás de um caminho protegido. A segunda permite especificar um nome de usuário e uma lista personalizada de permissões, como admin com ROLE_ADMIN e ROLE_MANAGER, para testar o comportamento da aplicação com um conjunto específico de permissões.
Ao executar a ação, o depurador cria um objeto TestingAuthenticationToken dentro do SecurityContext da aplicação em execução. As verificações hasRole e hasAuthority, bem como SecurityContextHolder.getContext().getAuthentication() e os parâmetros Principal ou Authentication, passam a enxergar a identidade e as permissões definidas pelo desenvolvedor. A ação não altera o código da aplicação nem os arquivos de configuração, e as aberturas desaparecem quando a aplicação é reiniciada, incluindo a reinicialização dentro do processo por meio do Spring Boot DevTools, ou quando o caminho é bloqueado manualmente.
O efeito não se limita à solicitação enviada pelo IntelliJ IDEA. A abertura de um GET para um caminho específico afeta qualquer cliente que acesse a mesma URI e o mesmo método HTTP, como curl, Postman ou um navegador. Se um padrão de caminho for aberto na definição do controlador, isso poderá incluir todos os valores correspondentes ao padrão. Portanto, o caminho deve ser bloqueado novamente ou a sessão de depuração encerrada assim que o trabalho terminar, especialmente se a aplicação estiver acessível pela rede.
O que o Unlock não contorna?
A ação não desativa completamente o Spring Security nem contorna a proteção CSRF. Se uma solicitação do tipo POST, PUT ou DELETE exigir um token CSRF válido, o CsrfFilter ainda poderá rejeitá-la. Além disso, seu escopo está limitado à autorização de endpoints por meio do AuthorizationFilter na pilha Servlet; o Spring WebFlux, que usa o AuthorizationWebFilter, não é compatível.
Também não há uma interface direta para exibir ou abrir requisitos de proteção no nível dos métodos, como @PreAuthorize, @PostAuthorize e @Secured. Ainda assim, as permissões injetadas no SecurityContext podem ser lidas posteriormente pelo interceptor de proteção de métodos; portanto, uma chamada de serviço protegida por @PreAuthorize poderá passar se as permissões concedidas atenderem à sua condição. Isso não significa que o IntelliJ IDEA tenha aberto a proteção do próprio método, mas que a verificação leu o mesmo contexto de autenticação artificial.
Limitações da identidade e integração com ferramentas de teste
A identidade criada pelo depurador é um nome de usuário textual dentro de um TestingAuthenticationToken, e não o UserDetails da aplicação nem um tipo personalizado de objeto de usuário. Por isso, um parâmetro anotado com @AuthenticationPrincipal pode retornar o valor null; esse é um problema conhecido, de número IDEA-389767, que afetava a versão 2026.2 no momento da publicação do material.
É possível usar Principal ou Authentication como tipo do parâmetro, mas depender de um tipo concreto, como JwtAuthenticationToken, pode causar uma IllegalStateException, pois o objeto injetado não pertence a esse tipo. Os resultados também podem variar ou falhar nas partes que dependem de claims, credentials ou de uma identidade vinculada a uma sessão ou a um tipo específico de token de autenticação.
A abertura funciona com solicitações provenientes do arquivo .http integrado, do curl, do Postman e de frameworks de teste, desde que a aplicação em execução seja a mesma na qual o caminho foi aberto. Já em fluxos de trabalho automatizados ou baseados em agentes de inteligência artificial, atualmente não há uma chave programática para executar a operação. A JetBrains planeja adicionar uma ferramenta MCP e uma skill relacionada na versão 2026.3, mas a versão atual exige um primeiro clique manual dentro do IDE.
Por que essa prática é importante?
O valor prático aqui não é desativar a proteção, mas isolar a camada de autorização da lógica que o desenvolvedor deseja testar sem deixar alterações temporárias nos arquivos de configuração que possam ser esquecidas e chegar a outro ambiente. Por outro lado, a abertura é uma alteração de segurança temporária no processo em execução, e não uma simulação local limitada à solicitação do IDE. Portanto, ela deve ser considerada uma ferramenta de depuração com escopo controlado, e não um substituto para testes reais de autenticação, verificando-se o caminho, o método e os clientes afetados antes de usá-la.
Também é preciso observar que o recurso não registra uma mensagem nos logs nem fornece um indicador via Actuator ao abrir um caminho em uma aplicação remota. De acordo com o material, o estado só pode ser verificado pela interface dentro do IDE conectado à aplicação. Os Security inlays podem ser desativados pela configuração spring.debugger.security.enabled no Registry do IntelliJ IDEA quando não forem necessários.