CSRFmedium0-2 years
A code review flags `csrf(csrf -> csrf.disable())` in two services. One is a stateless JSON API that authenticates with a bearer token in the `Authorization` header; the other is a server-rendered app that logs users in with a session cookie. Is the flag right for both, one, or neither?
Right for one. CSRF works because the browser attaches credentials automatically: a page on another site makes the victim's browser send a request to yours, the browser adds your session cookie, and your server sees a valid session. So the question is how each service authenticates. The session-cookie app is exactly the target: disabling CSRF there is a real vulnerability, and it should stay on. The bearer-token API is not exposed the same way, because a browser never adds an Authorization header by itself; an attacker's page would have to read the token and set the header, and a page that can read your token is an XSS problem, not a CSRF one. With SessionCreationPolicy.STATELESS beside it, disabling CSRF on that API is coherent, not lazy.
PreviousA security config has `requestMatchers("/api/**").authenticated()` followed by `requestMatchers("/api/admin/**").hasRole("ADMIN")`, and any signed-in user can call the admin endpoints. After reordering, admins get 403 too — their user records grant the authority `ADMIN`. What are the two bugs?Next A service method reads the current user with `SecurityContextHolder.getContext().getAuthentication()` and works in the request. The same method, called from an `@Async` method or inside `CompletableFuture.supplyAsync(...)`, sees no user. A teammate proposes `MODE_INHERITABLETHREADLOCAL`. Explain the empty context, and why that proposal can make things worse.