การรักษาความปลอดภัยเมธอดด้วย SpEL และผู้ลงคะแนนแบบกำหนดเอง

URL-based security (HttpSecurity matchers) guards entry points, but it cannot see the arguments a method receives or the object it returns. Method security closes that gap by enforcing rules right at the service layer.

• Defense in depth — protection survives even if a controller forgets a check.
• Fine-grained — decide based on parameters, return values, and the authenticated principal.
• Reusable — the same secured service can be called from REST, GraphQL, or a message listener and stays protected.

In this lesson we enforce access with @PreAuthorize, SpEL expressions, and a custom authorization manager.

In Spring Boot 4 / Spring Security 6, method security is opt-in. Add @EnableMethodSecurity to a configuration class. It activates the annotations through an AOP proxy.

• prePostEnabled defaults to true — @PreAuthorize and @PostAuthorize work out of the box.
• Set securedEnabled = true for the legacy @Secured, or jsr250Enabled = true for @RolesAllowed.

Note: the old @EnableGlobalMethodSecurity is removed — always use @EnableMethodSecurity.

@PreAuthorize evaluates a SpEL expression before the method runs. If it returns false, Spring throws AccessDeniedException and the body never executes.

• hasRole('ADMIN') — checks the ROLE_ADMIN authority (the prefix is added for you).
• hasAuthority('SCOPE_orders:write') — exact authority match, no prefix added.
• hasAnyRole('ADMIN','MANAGER') and the boolean operators and / or / !.

The real power of SpEL is reading method arguments. Prefix a parameter name with # to use it inside the expression. This lets you compare the principal's identity to the data being acted on.

• authentication — the current Authentication object.
• principal — the principal (often a UserDetails or JWT).
• #username, #order.ownerId — method arguments and their properties.

Argument names require parameters compiled with -parameters (Spring Boot enables this by default).

@PostAuthorize runs after the method returns and can inspect the result via returnObject. Use it when you must load the entity first to know who owns it.

• Good for “you can read this record only if it belongs to you.”
• The method body does execute, so avoid it for operations with side effects you must prevent.
• On denial, the return value is discarded and AccessDeniedException is thrown.

Filtering annotations prune collections element by element instead of throwing. They use a special variable filterObject bound to each element.

• @PreFilter — strips disallowed elements from a collection argument before the method runs.
• @PostFilter — strips disallowed elements from the returned collection.
• Use filterTarget when a method has more than one collection parameter.

Caution: post-filtering large result sets in memory can be costly — prefer filtering in the query when possible.

When logic gets complex, push it into a Spring bean and call it from the expression using @beanName.method(...). This keeps annotations readable and the rule unit-testable.

• The @ resolves a bean from the application context.
• Pass authentication and method arguments straight into the bean method.
• The method must return a boolean.

SpEL exposes hasPermission(target, permission), which delegates to a PermissionEvaluator bean. It is the canonical hook for domain-object (ACL-style) authorization without inlining logic in every annotation.

• hasPermission(#doc, 'WRITE') — passes the object and a permission key.
• hasPermission(#id, 'com.app.Document', 'READ') — passes an id plus the type.
• You register exactly one PermissionEvaluator via a MethodSecurityExpressionHandler.

To wire your PermissionEvaluator into SpEL, expose a DefaultMethodSecurityExpressionHandler bean and set the evaluator on it. Spring Security picks it up for all method annotations.

• The bean name is not important; the type is.
• You can also attach a custom RoleHierarchy here so hasRole respects inheritance.

Spring Security 6 replaced the legacy AccessDecisionVoter with the simpler AuthorizationManager<T>. For method security the type parameter is MethodInvocation. Implement check to return an AuthorizationDecision.

• Return new AuthorizationDecision(true|false) — or null to abstain and let other managers decide.
• Register it with @EnableMethodSecurity(prePostEnabled = false) plus an advisor, or combine managers with AuthorizationManagers.allOf(...).

Picking the wrong annotation either leaks data or blocks valid calls. A quick decision guide:

• Rule depends only on arguments + principal → @PreAuthorize (fast, no side effects).
• Rule depends on the loaded entity's ownership → @PostAuthorize.
• Trimming a collection per-element → @PostFilter (or filter in the query).
• Reusable domain-object rule → hasPermission + PermissionEvaluator.

Remember: @PostAuthorize and @PostFilter run the method body, so never rely on them to stop a mutating operation.

You now enforce fine-grained access at the method layer:

• @EnableMethodSecurity turns on annotation-driven checks (no more @EnableGlobalMethodSecurity).
• @PreAuthorize guards before execution using SpEL: hasRole, hasAuthority, #args, and authentication.
• @PostAuthorize inspects returnObject; @PreFilter/@PostFilter prune collections via filterObject.
• Push complex rules into a bean (@beanName.method(...)) or a PermissionEvaluator behind hasPermission.
• For cross-cutting policy, implement AuthorizationManager<MethodInvocation> — the modern replacement for voters.

Rule of thumb: prefer pre-checks for speed and safety; reach for post-checks only when the decision needs the loaded data.