- Shipped
- 3 Agosti 2026, 03:39 UTC
- Author
- Kamo
- Commit
- 8eb4164
ResourceServerConfig is anyRequest().permitAll() and @EnableMethodSecurity appears nowhere in this service, so every @PreAuthorize is inert and public is the default. Authorization is a per-handler convention, which means a handler that forgets it is reachable without credentials through APIService's unauthenticated /api/security/** relay. Five instances of exactly that were fixed this week — **************** took no HttpServletRequest at all, and the JobTitle/Department PUT and DELETE handlers accept rights[]. Fixing instances does not fix the class. A scan finds 406 of 1034 mapped endpoints in this service with no session-resolution or rights helper anywhere in the handler body. This baselines those and fails the build on any NEW one, so the count can only fall. A second test fails when a baseline entry no longer matches an unguarded endpoint. Fixing a handler therefore requires deleting its line, which is what makes the number actually move rather than letting the file rot into a graveyard that everyone stops reading. Proven by mutation in both directions: adding an unguarded endpoint fails and names it; adding a guard to a baselined handler without removing its line fails and names that too. Deliberately coarse, and it is NOT an authorization audit. A body counts as guarded if it mentions a known helper, so absence from the baseline means "reviewed once", never "proven safe". Some baselined entries are correctly public (login, password recovery, webhooks, SSR org lookup), some delegate the check into a service, and an unknown number are genuinely unauthenticated. Triage is WS-1 in kamo-internal **************** The value here is the ratchet, not the verdict.