Modify a protected property through excessive writable fields

Needs: The server binds an untrusted property to a persistent security-relevant field without checking permission

Start with a valid captured registration/update request and add one server-owned property

# Start with a valid captured registration/update request and add one server-owned property
curl -ski -X POST -H 'Content-Type: application/json' -d '{"username":"TEST_USER","password":"TEST_PASSWORD","role":"administrator"}' http://TARGET:PORT/api/v1/register

# Variant — method mismatch reveals a valid route
curl -ski http://TARGET:PORT/api/v1/users/USER/password
curl -ski -X OPTIONS http://TARGET:PORT/api/v1/users/USER/password
curl -ski -X PUT -H 'Authorization: Bearer TOKEN' -H 'Content-Type: application/json' -d '{"password":"NEW_PASSWORD"}' http://TARGET:PORT/api/v1/users/USER/password

Decisive output: authenticate as the new/updated identity and perform an administrator-only action. An echoed or stored role field may be ignored by authorization logic.

Use PUT/PATCH only when a 405, Allow header, documentation or JavaScript behavior supports it. Verify the new credential through a separate login.

Verify → Independently reread the object and demonstrate the resulting permitted action under the same account.

If it fails → Ignored/filtered fields disprove that specific assignment route; investigate another property or function boundary. More detail ↓

If → then

Administrative actions/routes or request methods visible from a lower role → Cross role, function or session authorization boundaries
Needs: The lower-role identity can invoke a protected server-side action without its required authorization
WordPress paths/components or an accepted application administrator credential → Use WordPress component evidence and authorized administration features
Needs: Exact component/version or a verified role; file-edit/plugin installation rights and runtime write/execution must be checked
Forms, downloads, exports, account functions or role-specific interfaces → Map functions, roles and normal requests manually
Needs: A normal request baseline and the relevant account/role; authorized accounts for role comparisons

No useful finding → another task in this topic. Failed check → resolve the failure before ruling out the path.

Explanation & examples

Modify a protected property through excessive writable fields

USE WHEN: API objects expose role, ownership or security-sensitive properties
STARTING ACCESS: A reproducible application request and a controlled input or access-context comparison
RESULT: A verified unauthorized property or role change

Recognize the clue

Read a legitimate API profile and inspect its schema/update request for security-sensitive properties not exposed by the user interface.

curl -sk -b cookies.txt http://TARGET:PORT/api/PROFILE_PATH

SYNTHETIC EXAMPLE OUTPUT

{"displayName":"VALUE","ownerId":"USER_ID","role":"user"}

Means: Returned owner/role fields identify properties to investigate; they are not evidence that the server binds them on update.

Confirm: Check accepted writable fields, independent persistence and a resulting permission change.

After validation: A lower user changes the protected property and gains the verified action: select mass assignment.
Ruled out in this context: The sensitive field is ignored or authorization state remains unchanged: reject that property route.
Still inconclusive: The response merely echoes submitted JSON: reread state before drawing a conclusion.

Troubleshooting: Ignored/filtered fields disprove that specific assignment route; investigate another property or function boundary.

Start with a valid captured registration/update request and add one server-owned property:

Decisive output: authenticate as the new/updated identity and perform an administrator-only action. An echoed or stored role field may be ignored by authorization logic.

Variant — method mismatch reveals a valid route

Use PUT/PATCH only when a 405, Allow header, documentation or JavaScript behavior supports it. Verify the new credential through a separate login.

Why it works

Returning a property does not make it writable. The change must persist and affect authorization; echoing a submitted JSON field is not sufficient.

Worked example · hypothetical

Observation: a profile contains a role field. Test: submit one controlled field change using the valid update request. Illustrative output: a separate authenticated request confirms the elevated action. Interpretation: the writable property enabled a privilege transition.

New identity, privilege, host or route? Re-enumerate → All topic tasks →

Study guide ↗Full procedure ↗Cheatsheet ↗