Why can a @PreAuthorize on a method be silently bypassed when another method in the same class calls it, and how do you fix that?

**Why it happens.** `@EnableMethodSecurity` works by wrapping each bean that has security annotations in a **Spring AOP proxy** (JDK dynamic proxy if the bean has an interface, CGLIB subclass proxy otherwise). The security interceptor lives *on the proxy*. When Spring injects `DocumentService` into a controller, the controller actually holds a reference to the proxy, so every call it makes is intercepted and `@PreAuthorize` runs. But *inside* the bean, `this` refers to the **raw target object**, not the proxy. So when one method calls another method on the same instance: ```java public void batch() { // called through the proxy — intercepted for (Long id : ids) { this.deleteSecured(id); // 'this' = raw target — proxy skipped } } @PreAuthorize("hasRole('ADMIN')") public void deleteSecured(Long id) { ... } ``` The `deleteSecured` call goes straight to the target; the proxy — and therefore the `AuthorizationManagerBeforeMethodInterceptor` — is never on the call stack. The check is **silently skipped**, which is a security hole, not just a bug. (The exact same mechanism causes `@Transactional`, `@Cacheable`, and `@Async` to be ignored on self-invocation.) **Note on scope of this leaf:** the AOP proxy *mechanism* itself (how proxies are created/chosen) belongs to Spring AOP; here the point is the security-visible *consequence* — the interceptor never runs. **Fixes, roughly in order of preference:** 1. **Redesign so the boundary is external.** Keep authorization on the public entry point and don't call other guarded methods internally. If `batch()` is the entry point, guard `batch()` itself. This avoids proxies-within-proxies entirely and is the clearest design. 2. **Move the secured method to a different bean.** Extract `deleteSecured` into `SecuredDeleteService`, inject it, and call `securedDeleteService.deleteSecured(id)`. Now the call crosses a bean boundary and passes through that bean's proxy. 3. **Self-injection.** Inject the bean into itself and route the call through the proxy reference: ```java @Autowired private DocumentService self; // the proxy public void batch() { ids.forEach(id -> self.deleteSecured(id)); } ``` Spring resolves `self` to the proxy, so the interceptor fires. (Constructor self-injection can cause a circular reference; field/setter or `@Lazy` avoids it.) 4. **AopContext.currentProxy().** Enable it with `@EnableMethodSecurity` combined with proxy exposure (`@EnableAspectJAutoProxy(exposeProxy = true)` / `proxyTargetClass` config), then call `((DocumentService) AopContext.currentProxy()).deleteSecured(id)`. Works but couples code to AOP internals — least preferred. **Related gotchas.** - Annotating a **non-public** method: with Spring AOP CGLIB proxies, private methods can't be advised at all, and even protected/package methods are inconsistent — put security annotations on **public** methods. - Marking a method `final` (or a `final` class) prevents CGLIB from subclassing it, so the proxy — and the security check — silently can't apply. - Calling a secured method from the bean's **constructor** or `@PostConstruct` also bypasses the proxy (the proxy isn't in the picture yet). **How to detect it** — enable proxy-mode debugging or simply write an integration test that calls the *public entry point* as an unprivileged user and asserts `AccessDeniedException`. A unit test that calls the method directly on the raw instance will never catch the bypass because it also skips the proxy.