@Secured & @RolesAllowed

## What they are **Method security** means enforcing authorization at the method level rather than only on URLs. Spring Security intercepts calls to annotated methods (via a Spring AOP proxy) and checks the current user's *authorities* before letting the method execute. **@Secured** is a Spring Security annotation. It takes one or more authority strings and grants access if the user has *any* of them: ```java @Secured("ROLE_ADMIN") public void deleteUser(Long id) { ... } ``` Important: @Secured does **not** add the `ROLE_` prefix for you. You must write the *complete* authority name (`ROLE_ADMIN`, not `ADMIN`). **@RolesAllowed** is from **JSR-250** (the `jakarta.annotation.security` package, formerly `javax.annotation.security`). It is a Java-standard annotation, not Spring-specific, so it also works in Jakarta EE containers. It takes *role names* and Spring automatically prepends the `ROLE_` prefix: ```java @RolesAllowed("ADMIN") // matches authority ROLE_ADMIN public void deleteUser(Long id) { ... } ``` ## Key terms - **Authority**: a granted permission string on the user (e.g. `ROLE_ADMIN`, `SCOPE_read`). In Spring these are `GrantedAuthority` objects. - **Role**: by convention an authority that starts with `ROLE_`. "Role X" means authority `ROLE_X`. - **AccessDeniedException**: thrown when the check fails; results in HTTP 403 for web requests (or a redirect for anonymous users depending on config). ## How access is decided Both annotations do a simple membership test: does the user have at least one of the listed authorities? If yes, the method runs; if no, `AccessDeniedException` is thrown *before* the method body executes. Multiple values are **OR-ed**: ```java @Secured({"ROLE_ADMIN", "ROLE_AUDITOR"}) // admin OR auditor ``` There is **no way to express AND** with these annotations, and **no SpEL** — you cannot inspect method arguments or call `hasPermission`. ## Enabling them Neither is on by default. In Spring Security 6 use: ```java @Configuration @EnableMethodSecurity(securedEnabled = true, jsr250Enabled = true) public class SecurityConfig {} ``` `prePostEnabled` (for @PreAuthorize/@PostAuthorize) defaults to `true`; `securedEnabled` and `jsr250Enabled` default to `false`, so you must opt in. ## Gotchas - Writing `@Secured("ADMIN")` silently checks for authority `ADMIN`, which almost never exists — the user is denied. Always include `ROLE_`. - Writing `@Secured("hasRole('ADMIN')")` does **not** evaluate SpEL — the whole string is treated as a literal authority name and never matches. - The annotations only work through the Spring proxy: an internal `this.method()` self-call bypasses the check, and by default only `public` methods are advised. ## When to use Use @RolesAllowed or @Secured for simple, static, role-only checks where their brevity is a virtue. Reach for @PreAuthorize when you need SpEL — argument-based rules, combining conditions, or `hasAnyRole` plus custom logic.