O Spring Security 7.0 GA entrou no release train de junho de 2026 junto com o Spring Boot 4.0. E tem um detalhe que ninguem te avisou no calendario: o Spring Boot 3.5 perde suporte OSS em 30 de junho de 2026. Ou seja, o relogio da migracao ja esta correndo, e o seu SecurityConfig e a primeira coisa que vai quebrar no build.
Se voce ja tentou subir um projeto pro Boot 4 e tomou uma chuva de erros de compilacao no filtro de seguranca, este artigo e pra voce. Bora destrinchar, na pratica, tudo que mudou no Security 7 e montar um checklist de migracao com codigo antes e depois, do jeito que os seniores fazem.
O Spring Security 7.0 GA entrou no release train de junho de 2026 junto com o Spring Boot 4.0. E tem um detalhe que ninguem te avisou no calendario: o Spring Boot 3.5 perde suporte OSS em 30 de junho de 2026. Ou seja, o relogio da migracao ja esta correndo, e o seu SecurityConfig e a primeira coisa que vai quebrar no build.
Se voce ja tentou subir um projeto pro Boot 4 e tomou uma chuva de erros de compilacao no filtro de seguranca, este artigo e pra voce. Bora destrinchar, na pratica, tudo que mudou no Security 7 e montar um checklist de migracao com codigo antes e depois, do jeito que os seniores fazem.
Por que o Spring Security 7 quebra seu build
A versao 7 nao introduziu uma sintaxe nova de ultima hora. Ela apenas removeu de vez tudo que ja estava marcado como deprecated desde o Security 6.0. Se o seu codigo ignorou aqueles warnings amarelos por dois anos (e seja sincero, ignorou), a conta chegou agora. Os tres protagonistas dessa quebra sao:
- O metodo
.and()para encadear configuracoes: removido. - O
authorizeRequests()e oantMatchers(): removidos em favor deauthorizeHttpRequests()erequestMatchers(). - A anotacao
@EnableGlobalMethodSecurity: removida em favor de@EnableMethodSecurity.
O Lambda DSL, que era opcional no Security 5 e recomendado no 6, agora e obrigatorio. Nao existe mais o estilo encadeado com .and(). A documentacao oficial de migracao do projeto (Spring Security Migration Guide) lista a quebra inteira, mas vamos ao que interessa: como sair do jeito antigo pro jeito novo sem perder a cabeca.
Antes de qualquer coisa, confirme que voce esta no patch mais recente. O Spring Boot 4.0.7, liberado em 10 de junho, ja traz o Security 7 alinhado e corrige dois CVEs do autoconfig. Comecar a migracao por um patch antigo e pedir pra retrabalhar.
SecurityFilterChain: o antes e o depois
Aqui mora 90% da dor. Veja a configuracao classica que rodava liso no Spring Boot 3 com o estilo encadeado. Esse codigo nao compila mais no Boot 4:
// JEITO ANTIGO (Spring Security 5/6) - NAO COMPILA no Security 7
@Configuration
@EnableWebSecurity
public class SecurityConfig {
@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
http
.csrf().disable()
.authorizeRequests()
.antMatchers("/api/publico/**").permitAll()
.antMatchers("/api/admin/**").hasRole("ADMIN")
.anyRequest().authenticated()
.and()
.httpBasic();
return http.build();
}
}
Agora o mesmo filtro, reescrito no Lambda DSL obrigatorio do Security 7. Repare que cada bloco vira uma lambda e o .and() desaparece, porque o encadeamento agora e implicito:
// JEITO NOVO (Spring Security 7) - Lambda DSL obrigatorio
@Configuration
@EnableWebSecurity
public class SecurityConfig {
@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
return http
.csrf(AbstractHttpConfigurer::disable)
.authorizeHttpRequests(auth -> auth
.requestMatchers("/api/publico/**").permitAll()
.requestMatchers("/api/admin/**").hasRole("ADMIN")
.anyRequest().authenticated()
)
.httpBasic(Customizer.withDefaults())
.build();
}
}
Tres mudancas mecanicas resolvem a maioria dos casos: troque authorizeRequests por authorizeHttpRequests, troque antMatchers por requestMatchers e remova todos os .and(), abracando cada configurador numa lambda. Na empresa em que trabalhei como Tech Leader, a gente fez essa troca num monolito com 14 SecurityFilterChain usando um find-and-replace assistido pela IDE em menos de uma tarde. O segredo e nao tentar reescrever a logica, so a sintaxe.
Method Security e o 403 fantasma
A segunda quebra e na seguranca por metodo. A anotacao @EnableGlobalMethodSecurity com prePostEnabled sumiu. O substituto e mais enxuto:
// ANTES - removido no Security 7
@EnableGlobalMethodSecurity(prePostEnabled = true)
public class MethodSecurityConfig { }
// DEPOIS - Security 7
@EnableMethodSecurity // prePostEnabled = true ja e o padrao
public class MethodSecurityConfig { }
Mas a pegadinha de verdade, o famoso 403 fantasma, mora no dispatch-type authorization. No Security 7, a autorizacao passa a avaliar os dispatch types FORWARD e ERROR por padrao. Traducao pratica: a sua pagina de erro customizada, que era servida via forward interno, agora cai na regra anyRequest().authenticated() e devolve 403 pro usuario deslogado que deveria ver um 404 amigavel. O app compila, sobe, passa nos testes felizes e quebra so em producao. O fix cabe em poucas linhas:
// Liberar os dispatch types internos para a pagina de erro voltar a funcionar
import static org.springframework.security.web.util.matcher.DispatcherTypeRequestMatcher...;
import jakarta.servlet.DispatcherType;
http.authorizeHttpRequests(auth -> auth
.dispatcherTypeMatchers(DispatcherType.FORWARD, DispatcherType.ERROR).permitAll()
.requestMatchers("/api/publico/**").permitAll()
.anyRequest().authenticated()
);
Esse e o tipo de detalhe que separa quem leu o changelog de quem so rodou o build. Se voce ja migrou a base pro Boot 4 no ciclo passado, vale revisitar: a gente cobriu o panorama do Spring Boot 4.0 GA e os 26 CVEs do release train de junho e tambem o novo modelo de tool calling do Spring AI 2.0, que tambem entrou nessa mesma leva.
O que muda na sua rotina (e nos seus prazos)
A parte boa: a migracao do Security 7 e previsivel. Diferente de quebras de runtime silenciosas como a do Jackson 3, aqui o compilador e seu amigo. Ele aponta cada ponto que precisa mudar, e a maioria e substituicao mecanica. Em projetos medios, da pra fechar a migracao do filtro numa unica sessao de foco.
A parte que aperta e o calendario. Veja os numeros concretos pra dimensionar o risco:
- 30 de junho de 2026: fim do suporte OSS do Spring Boot 3.5. Depois dessa data, sem patch de seguranca gratuito.
- Boot 3.4 e anteriores: ja estao fora do suporte OSS. Patches so via assinatura comercial.
- Security 7 + Boot 4.0.7: o combo atual, com os dois CVEs recentes do autoconfig ja corrigidos.
Quando usar a urgencia a seu favor: se voce tem uma janela de manutencao agendada antes do fim do mes, encaixe a migracao do Security ali. O custo de migrar agora, com o ecossistema estabilizado no GA, e muito menor do que migrar as pressas em julho depois de um boletim de seguranca novo. Quando NAO ter pressa cega: nao migre direto pra producao numa sexta a noite. Teste o fluxo de login, os endpoints protegidos e, principalmente, as paginas de erro, que e onde o dispatch-type morde.
Checklist e proximos passos
Resumo do que voce precisa tocar pra sair do Security 6 pro 7 sem drama:
- Troque o DSL encadeado por lambdas: adeus
.and(), olaauthorizeHttpRequests(auth -> ...). - Atualize os matchers:
antMatchersvirarequestMatchers,authorizeRequestsviraauthorizeHttpRequests. - Troque a anotacao de method security:
@EnableGlobalMethodSecurityvira@EnableMethodSecurity. - Libere os dispatch types FORWARD e ERROR pra nao tomar 403 na pagina de erro.
- Suba pro Boot 4.0.7 antes de comecar, pra ja pegar os CVEs corrigidos.
Voce ja comecou a migracao do seu SecurityFilterChain pro Boot 4? Travou em algum ponto que nao listei aqui? Conta nos comentarios, quero saber como esta sendo na sua stack, no mercado de hoje isso virou filtro de entrevista pra vaga senior.
Na proxima materia da serie de migracao Boot 4, vou pegar o vilao silencioso que o compilador NAO te avisa: o Jackson 3 mudando o formato das suas datas em JSON sem soltar um unico erro de build. Fica de olho.