Spring Boot Method Security: Verify @PreAuthorize Is Active

A @PreAuthorize annotation in a Spring Boot service is not sufficient evidence that method authorization is running. Verify the configuration, Spring-managed invocation path, and rejected cases after a migration or generated change.

This guide replaces an unsupported model-failure headline with an inspectable security scenario. It is not a claim that one agent always removes a particular annotation.

Activate the intended mechanism

Spring’s method-security reference documents @EnableMethodSecurity and the supported annotations. The security starter does not by itself activate every method-level authorization feature.

For a typical configuration, the activation fragment is:

@Configuration
@EnableMethodSecurity
class MethodSecurityConfiguration {
}

Use the correct imports and configuration discovery for the project. Merely adding the source file does not prove it is included in the running application.

Test the managed service

Invoke the secured Spring-managed bean from the intended caller. A test that constructs the service directly can bypass the interceptor. Proxy-based mechanisms can also be bypassed by call paths that do not traverse the proxy.

Establish both a permitted identity and a denied identity. Assert the denied outcome and absence of the protected side effect. Testing only the successful administrator request cannot establish that ordinary users are rejected.

Keep role-versus-authority semantics aligned with the expression you use. An expression expecting ROLE_ADMIN is not interchangeable with every arbitrary authority string.

Separate request and method authorization

An HTTP security rule can reject a request before a service method runs. Conversely, another entry point can invoke a service without passing through a controller. Know which layer the test exercises.

If a request-level rule blocks both identities, a passing rejection test may say nothing about method interception. Use a focused method-security test alongside the appropriate HTTP integration check.

Record ownership checks separately from a role check. A user role can permit order access generally while still requiring the record to belong to that user. The ownership guide supplies that separate contract.

Review migration changes with a negative control

When replacing old configuration APIs, check the migration documentation and compare behavior before and after. Do not delete a deprecated activation annotation without verifying its replacement and scope.

In a disposable copy, temporarily remove or disable the relevant activation and confirm that the test designed to prove enforcement detects the difference. Restore the configuration before accepting the patch. This verifies the test harness rather than relying on a source grep.

Keep CSRF and authentication distinct

A 401 or 403 response can come from several layers. Identify the failing mechanism before attributing it to method security. The CSRF diagnostic guide explains why status alone is insufficient.

Use the Boot migration walkthrough for the wider upgrade sequence, the AI review guide for call-path checks, and the Java hub for related scenarios. The acceptance evidence is a protected operation rejected under the intended configuration, not an annotation present in a diff.