- Ya
- 2 Agosti 2026, 18:21 UTC
- Mwandishi
- Kamo
- Ahadi ya
- f344bef
PUT and DELETE on /api/security/job-titles/{id} and /api/security/departments/{id} resolved no session at all — they read a UUID off the path and called straight through to the service. Because ResourceServerConfig permits every request and APIService relays /api/security/** without gateway auth, both were reachable unauthenticated from the internet. UpdateJobTitleRequest and UpdateDepartmentRequest both carry rights[] and roleIds[], so the PUT was a remote privilege-escalation primitive; the DELETE destroyed another tenant's access-control objects. Apply the same ladder the sibling GET /{id} handlers in these files already used: no session => 401, unknown id => 404, row outside the caller's org => 403, and in every negative case the service is never reached. Not addressed here: an authenticated member of the org can still edit their own org's job titles without a dedicated right, because no such right exists in RoleRightType. Introducing one needs a KamoInitializer run plus a grant, so it belongs with the deny-by-default authorization work, not this fix.