@PreAuthorize vs @Secured vs @RolesAllowed

Direct Answer

@PreAuthorize is the most powerful — accepts SpEL and can inspect method arguments, return values, and Spring beans (@authService.canAccess(#id, authentication)). @Secured accepts a list of role strings only and predates SpEL. @RolesAllowed is the JSR-250 standard, also role-string only. For any non-trivial logic — ownership, parameter checks, custom evaluators — @PreAuthorize is the modern default. Combine with @PostAuthorize for return-value checks and @PreFilter/@PostFilter for collection element filtering. Enable with @EnableMethodSecurity in Spring Security 6 (replaces deprecated @EnableGlobalMethodSecurity).

Code Example

All three annotations gate method calls, but they differ in expressiveness and origin.

@Configuration
@EnableMethodSecurity(
    prePostEnabled = true,     // enables @PreAuthorize, @PostAuthorize (Spring)
    securedEnabled = true,     // enables @Secured             (Spring, legacy)
    jsr250Enabled  = true      // enables @RolesAllowed         (Jakarta / JSR-250)
)
public class MethodSecurityConfig {}

@Service
public class DocumentService {

    // @Secured — simple, role list only, no SpEL
    @Secured({"ROLE_ADMIN", "ROLE_EDITOR"})
    public void publish(Long id) { ... }

    // @RolesAllowed — identical semantics, JSR-250 standard, works in non-Spring EE code
    @RolesAllowed({"ADMIN", "EDITOR"})
    public void archive(Long id) { ... }

    // @PreAuthorize — full SpEL: arguments, return value, bean methods, authentication principal
    @PreAuthorize("hasRole('ADMIN') or (#doc.ownerId == authentication.name and #doc.draft)")
    public void edit(@P("doc") Document doc) { ... }

    @PostAuthorize("returnObject.ownerId == authentication.name or hasRole('ADMIN')")
    public Document load(Long id) { return repo.findById(id).orElseThrow(); }

    // Custom permission bean referenced via @acl
    @PreAuthorize("@acl.canDelete(#id, authentication)")
    public void delete(Long id) { ... }
}

• Use @PreAuthorize by default — it supports argument-level checks, bean references (@acl.canDo(...)), and SpEL on authentication and principal.
• Pick @Secured or @RolesAllowed only if your team prefers plain role lists or you target a non-Spring runtime.
• Enable only the flags you use (prePostEnabled, securedEnabled, jsr250Enabled) — each one adds an AOP advisor to every secured bean.
• Remember the proxy rule: these annotations work only on public methods of Spring-managed beans, called through the proxy.

Common Mistakes & Pitfalls

Using @Secured or @RolesAllowed and then discovering they cannot express 'only the owner of this resource can edit it' — that requires SpEL in @PreAuthorize.