HighIDOR (write)· 3 min read

Editing a Stranger's Identity by Changing One Field

The profile-update request carried the account's own ID. Swap it, and you overwrite someone else's name, phone and documents.

Target anonymized · an e-commerce grocery chain

Read-IDOR gets the headlines, but write-IDOR is often nastier: instead of seeing someone's data, you change it. This grocery platform let me rewrite other people's identities.

The spark

The request that saved my billing and profile details was a PATCH that carried my account's ID in the body. It matched my account — but it was still client-controlled, which is the tell.

Digging in

I ran the checks that separate a real write-IDOR from a mirage. A garbage ID was rejected — good, the endpoint resolves the target rather than ignoring it. Then the important one, the persistence check: I sent a PATCH with a victim test-account's ID and attacker values, then logged in as the victim to confirm the change actually stuck to their record.

It did. Their name, phone, document number and birth date were now whatever I'd typed.

A 200 OK only means the server accepted the request. The bug is only real once the victim's own view shows your write.

The exploit

PATCH /api/profile HTTP/2
Host: shop.example.com
Content-Type: application/json

{ "id": "<victim-id>", "firstName": "changed", "phone": "...", "document": "..." }

Impact

Any user could overwrite another user's personal and billing details. Beyond the privacy violation, tampering with billing/invoice identity data opens the door to fraud and repudiation.

The fix

Resolve the record to update from the authenticated session, not from an id in the payload, and authorize the write server-side before persisting.

idormass-assignmentintegritypii

All identifiers, targets and payloads in this post are anonymized or defanged. Findings were reported and resolved through responsible disclosure.