A municipal API accepts a hidden role field from the client JSON body and grants admin features when it is set. What flaw theme should the tester call out?
Select an answer to reveal the explanation.
Short Explanation
If the name tag on the badge comes from the visitor's pocket, anyone can write Admin. Client-supplied roles and privileged fields are not evidence of authority. The server must decide roles from its own session and datastore.
Full Explanation
Trusting client-controlled privileged parameters is a mass-assignment / broken access control theme. When a municipal API accepts a hidden role field from client JSON and grants admin features if set, the server is letting the caller choose privilege instead of binding roles from authoritative server-side session or identity data—an invitation to privilege escalation on citizen services.
Perfect server-side role binding would ignore client role fields. Missing favicons and long Cache-Control headers are not privilege themes.
Exam caveat: never take role, isAdmin, accountId, or price fields from the client as authoritative; bind them server-side. CPTS API testing systematically tampers with privileged JSON fields.
Operational check: submit role-tampering requests with a low-privilege civic test user, ensure server ignores client role claims, derive authorization from session/IdP claims, and add tests that fail the build if privileged fields are client-writable. Strip unknown privileged properties from municipal API DTOs at the binder and log tampering attempts on role-like fields for SOC visibility. Mass-assignment tests belong in municipal API CI alongside schema validation. Cite the control owner in the civic remediation plan.