Introduction

If your IDE or compiler says it cannot resolve antMatchers, you are usually mixing older Spring Security examples with the newer authorization API. In current Spring Security configuration, antMatchers is gone from the modern DSL and has been replaced by requestMatchers inside authorizeHttpRequests.

Why the method is missing

Older Spring Security code often looked like this:

1http
2    .authorizeRequests()
3    .antMatchers("/public/**").permitAll()
4    .anyRequest().authenticated();

That style belongs to the older configuration model. In current Spring Security versions:

• 'authorizeRequests() became authorizeHttpRequests()'
• 'antMatchers(...) became requestMatchers(...)'
• 'WebSecurityConfigurerAdapter is no longer the standard approach'

So the unresolved method is usually a version mismatch between the code sample and the libraries in your project.

The modern configuration style

Use a SecurityFilterChain bean.

1import org.springframework.context.annotation.Bean;
2import org.springframework.context.annotation.Configuration;
3import org.springframework.security.config.annotation.web.builders.HttpSecurity;
4import org.springframework.security.web.SecurityFilterChain;
5
6@Configuration
7public class SecurityConfig {
8
9    @Bean
10    SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
11        http
12            .authorizeHttpRequests(auth -> auth
13                .requestMatchers("/public/**", "/health").permitAll()
14                .requestMatchers("/admin/**").hasRole("ADMIN")
15                .anyRequest().authenticated()
16            )
17            .formLogin(login -> login.permitAll());
18
19        return http.build();
20    }
21}

This is the baseline style expected in Spring Boot 3 and Spring Security 6 era projects.

Matching by HTTP method

requestMatchers also supports HTTP method-specific rules.

1import org.springframework.http.HttpMethod;
2
3.requestMatchers(HttpMethod.GET, "/api/public/**").permitAll()
4.requestMatchers(HttpMethod.POST, "/api/admin/**").hasRole("ADMIN")

That covers one of the common old antMatchers use cases without needing the removed method.

What about Ant-style patterns

A common misunderstanding is thinking antMatchers was removed because Ant-style path patterns are no longer supported. That is not the right conclusion.

The change is mostly about the configuration API. You still express URL rules, but you do it through the newer request-matching entry points that fit the current authorization model.

The point is that the DSL method changed. You now express path matching through requestMatchers, and the framework chooses the appropriate matcher implementation based on what you provide and what infrastructure is available.

So the migration is more about API shape than about abandoning path-based matching altogether.

Check your dependency versions

If your code sample and project dependencies disagree, fix the version mismatch before fighting the IDE.

Practical checks:

• Spring Boot 3 projects should use the modern DSL
• Spring Security 6 projects should use requestMatchers
• older tutorials showing antMatchers are likely written for previous major versions

This is why blindly copying security snippets from older answers often fails.

Do not use outdated configuration patterns

If you still have code built around WebSecurityConfigurerAdapter, it is a strong signal that the example is from an older Spring Security generation.

That does not mean the project is wrong by definition, but it does mean migration guidance should be read as a full configuration update rather than as a one-word method rename.

Modern configuration is bean-based and more explicit. Migrating the method calls without migrating the overall style can leave you in an awkward in-between state.

Common Pitfalls

A common mistake is assuming the IDE is broken when the real issue is that the tutorial targets an older Spring Security version.

Another mistake is trying to replace only antMatchers while keeping the rest of an outdated configuration style unchanged.

A third mistake is assuming requestMatchers means the path matching behavior has disappeared rather than just being expressed through a newer API.

Summary

• 'antMatchers is not part of the modern Spring Security authorization DSL.'
• Use requestMatchers inside authorizeHttpRequests.
• Prefer a SecurityFilterChain bean instead of older adapter-based configuration.
• Check your Spring Boot and Spring Security versions before copying examples.
• The usual fix is API migration, not IDE troubleshooting.
• In most projects, the missing method is a version-signal, not a typo.
• Treat old security snippets with suspicion if they still rely on removed DSL methods.