Method Security

@PreAuthorize checks a rule before a method runs; @PostAuthorize checks after it returns. You enable them by adding @EnableMethodSecurity to a configuration class. If the rule is false, access is denied with an exception.

Both are method-level annotations that restrict who can call a method based on their roles. @RolesAllowed is a Java standard (JSR-250); @Secured is Spring's own. You list allowed roles and Spring blocks everyone else.

Implement the PermissionEvaluator interface (its two hasPermission methods) with your own logic, then publish a MethodSecurityExpressionHandler bean, calling setPermissionEvaluator() so @PreAuthorize's hasPermission() uses it.

You can reference method arguments by name (or #p0, #p1), the current user via authentication and principal, and — only in @PostAuthorize — the method's result via returnObject. You combine them with helpers like hasRole() and hasAuthority().

@RolesAllowed takes the bare role name ("ADMIN") and Spring adds the ROLE_ prefix. @Secured takes the full authority string, so you must write "ROLE_ADMIN" yourself. Forgetting the prefix on @Secured silently denies access.

Method security runs through a proxy that wraps the bean. When one method calls another method on the same object with this, the call never leaves the object, so the proxy is skipped and the @PreAuthorize check doesn't run. Call through the injected bean instead, or move the method to another bean.

hasPermission() is a SpEL check you write in @PreAuthorize/@PostAuthorize. It asks 'can this user do X on this object?'. Spring delegates the yes/no answer to a PermissionEvaluator bean you configure.

They remove elements from a collection based on a security rule. @PreFilter filters a collection method argument before the method runs; @PostFilter filters the collection the method returns. filterObject is each element being tested.

@PreAuthorize takes a full SpEL expression, so it can check roles, method arguments, and custom logic — the most powerful. @Secured and @RolesAllowed only take plain role-name strings for simple checks. Prefer @PreAuthorize unless you want a standard/simple role list.

Method security uses AOP proxies. The check only runs when the call comes through the proxy. Common misses: calling the method from within the same bean (self-invocation), the class isn't a Spring bean, the method is private/final, or you forgot @EnableMethodSecurity / the right flag.

@PreFilter removes elements in place, so the collection argument must be mutable — an immutable one (like List.of(...)) throws UnsupportedOperationException. When a method has multiple collection parameters, name the one to filter with the filterTarget attribute.

Multiple listed roles mean OR — having any one of them grants access. Neither annotation can express AND (require several roles at once), negation, or any condition based on method arguments. For those you need @PreAuthorize with SpEL.

@EnableMethodSecurity (Spring Security 5.6+) replaces the deprecated @EnableGlobalMethodSecurity. It's built on the newer, simpler AuthorizationManager API instead of the old AccessDecisionManager/voter machinery, defaults prePostEnabled to true, and supports meta-annotations and custom SpEL beans more cleanly.

spring-security-acl stores per-object, per-user permissions in four DB tables. AclPermissionEvaluator (a PermissionEvaluator) looks up an object's ACL via AclService and checks whether the current user's Sid was granted the requested Permission mask.

A method interceptor named AuthorizationManagerBeforeMethodInterceptor wraps the bean. Before the method runs it asks an AuthorizationManager (backed by a SpEL expression handler) to decide; if the decision is a deny, it throws AccessDeniedException. This replaces the old voter/AccessDecisionManager stack from @EnableGlobalMethodSecurity.

@PostFilter loads every row first, then discards the forbidden ones in memory — wasteful for big datasets and it breaks pagination (a page of 20 can shrink to fewer, and totals are wrong). Better: filter in the database query itself.

@PostAuthorize makes one keep-or-throw decision on the whole return value (via returnObject); @PostFilter prunes a returned collection element by element (via filterObject), never throwing. Filtering supports Collection, arrays, and Stream — not Map.

Use @Secured/@RolesAllowed for simple, static role-only checks — they are terser and less error-prone than a SpEL string. Prefer @RolesAllowed for portability. Switch to @PreAuthorize whenever you need SpEL: method arguments, combined conditions, or custom expressions.

Use @PostAuthorize when the decision depends on the object the method returns — for example an ownership check on the loaded entity. The risk is that the method body runs first: any side effects, expensive work, or data loading happen even when access is finally denied, and only the return value is thrown away.

@EnableMethodSecurity registers a set of AOP advisor beans (pointcut + interceptor pairs), one per annotation type. Spring proxies your secured beans; when a matching method is called, the advisor's interceptor runs an AuthorizationManager to allow or deny. Their run order is fixed by AuthorizationInterceptorsOrder.

Use spring-security-acl only when permissions are per-object, admin-managed, and change at runtime (Google-Docs-style sharing). For ownership or role rules, a small custom PermissionEvaluator — or filtering in the SQL query — is simpler and faster.

Use @PreFilter/@PostFilter only for small, per-element visibility rules on service methods. Prefer data-layer filtering for large or paged reads, keep authorization out of the persistence path for correctness, and watch for immutable-collection breakage, silent result-shrinking, and proxy/self-invocation gaps.

In Spring Security 6, @EnableMethodSecurity builds AOP interceptors backed by AuthorizationManager beans — SecuredAuthorizationManager for @Secured and Jsr250AuthorizationManager for @RolesAllowed. This replaced the old @EnableGlobalMethodSecurity model that used AccessDecisionManager and voters.