Introduction

These two annotations solve different problems in Spring Security. @EnableWebSecurity turns on web-request security infrastructure, while @EnableGlobalMethodSecurity enables method-level annotations such as @PreAuthorize and @Secured. In current Spring Security, the method-security annotation is usually @EnableMethodSecurity, which supersedes @EnableGlobalMethodSecurity.

@EnableWebSecurity Is About HTTP Requests

@EnableWebSecurity activates the web security configuration that protects incoming HTTP requests. This is where you define things such as:

• which URLs require authentication
• which roles can access certain paths
• login, logout, and CSRF behavior
• which SecurityFilterChain beans apply

A modern example looks like this:

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

That configuration governs request-level authorization before controller methods even run.

Method Security Is a Different Layer

Method security protects individual Spring-managed methods, usually at the service layer. It answers questions like:

• can this method be called by the current user
• can this result be returned to the caller
• should a parameter list be filtered

Historically, this was enabled with @EnableGlobalMethodSecurity. In newer Spring Security versions, @EnableMethodSecurity is the recommended replacement.

1import org.springframework.context.annotation.Configuration;
2import org.springframework.security.config.annotation.method.configuration.EnableMethodSecurity;
3import org.springframework.security.access.prepost.PreAuthorize;
4import org.springframework.stereotype.Service;
5
6@Configuration
7@EnableMethodSecurity
8class MethodSecurityConfig {
9}
10
11@Service
12class InvoiceService {
13
14    @PreAuthorize("hasRole('ADMIN')")
15    public void deleteInvoice(Long id) {
16        // ...
17    }
18}

This protects the method no matter who calls it, including internal application code that bypasses the controller layer.

So Which One Do You Need

If you only secure HTTP routes, @EnableWebSecurity is the main switch. If you also want annotations on services or repositories, add method security too.

That means the real comparison is not "one versus the other" so much as "request-level security versus method-level security."

A common application uses both:

• '@EnableWebSecurity for URL rules and filter-chain behavior'
• '@EnableMethodSecurity for @PreAuthorize, @Secured, or JSR-250 annotations'

Why Method Security Still Matters

Relying only on URL rules is often not enough. The same service method may be called:

• from a REST controller
• from another internal component
• from scheduled jobs or messaging endpoints

Method security keeps the authorization rule attached to the business operation instead of assuming every path into the code comes through the same web controller.

Legacy Note: @EnableGlobalMethodSecurity

You will still see @EnableGlobalMethodSecurity(prePostEnabled = true) in older code:

@EnableGlobalMethodSecurity(prePostEnabled = true, securedEnabled = true)

That is the older mechanism. Current Spring Security documentation recommends @EnableMethodSecurity, which supersedes it and provides a more modern internal implementation.

Common Pitfalls

The biggest pitfall is expecting @EnableWebSecurity alone to activate @PreAuthorize and related method annotations. It does not.

Another common mistake is treating method security as a replacement for web security. The two layers protect different entry points and often complement each other.

In practice, teams usually get the most predictable results when request rules and service-method rules are aligned instead of treated as unrelated systems.

In modern projects, it is also easy to copy old @EnableGlobalMethodSecurity examples without realizing that @EnableMethodSecurity is now the preferred annotation.

Summary

• '@EnableWebSecurity enables request-level web security infrastructure.'
• '@EnableGlobalMethodSecurity was the older way to enable method-level annotations.'
• In current Spring Security, @EnableMethodSecurity is the preferred method-security annotation.
• Web security protects URLs and filter chains, while method security protects service and bean methods.
• Many real applications use both layers together.