No customer support call. No re-verification.

Yet the name changes. The date of birth changes. The government ID number changes. But the eKYC status remains verified and every system that relies on that identity continue trusting the account as if nothing happened.

Mass Assignment happens when an application takes fields from a user-controlled request and applies them to an internal object without checking which fields are allowed to change.

A simple version looks like this:

{
"name": "Researcher",
"is_admin": true
}

The developer may have intended to update only the name. But if the backend assigns every submitted field into the user object, the extra is_admin value may be written too.

The important part is not the admin flag. The important part is the missing field-level decision. The server should ask “this user is allowed to update this object, but are they allowed to update this field?”

That question matters because one object can contain fields with very different levels of trust. A profile object can contain a nickname, height, weight, legal name, birthdate, government ID number, verification status, and insurance metadata. They may sit next to each other in JSON, but they do not mean the same thing.

Well, most people first meet Mass Assignment through the admin flag example. A request is supposed to update a name. The attacker adds is_admin. The backend saves it. The user becomes an admin. That example is useful because it is easy to remember. It is also cleaner than most real findings.

This one started in a quieter place: an edit profile endpoint.

Changing a first name is normal.

Changing a verified government ID number is not.

Changing identity itself after verification is definitely not.

Once an account has passed eKYC, attributes such as name, date of birth, gender, and government-issued identification become part of the trust model. They are no longer profile preferences. They are identity claims.

If those claims can be rewritten while the verification status remains intact, the problem is no longer profile editing. It becomes identity drift.

This writeup is about that chain: Mass Assignment, identity drift, and a second-order insurance impact.

The Profile

The target was a platform with web and mobile applications. It stored user profile data, supported verified identity, and allowed users to link a third-party insurance or benefit record to their account.

The profile had ordinary fields and sensitive identity fields. From the normal application flow, some of these fields were restricted after we completed the eKYC verification . If a user wanted to change them, the expected path was customer support or another verification process.

That business rule made sense. Once a field is used to represent identity, changing it should require more care than changing a preference.

The frontend understood this. The sensitive fields were not exposed as normal editable fields.

The backend did not enforce the same boundary.

The Request

The only attribute that could be edited directly through this flow was the phone number.

In simplified form, the request generated by the application looked like this:

PUT /api/v1/profile/{user_id}/phone HTTP/2
Host: api.[REDACTED]
Cookie: [REDACTED]
Content-Type: application/json
{
  "phone_number": "+628123456789"
}

The user was authenticated. The profile belonged to the user. The endpoint was meant to update a phone number and nothing more.

The test was simple: add fields the UI did not send in this flow.

PUT /api/v1/profile/{user_id}/phone HTTP/2
Host: api.[REDACTED]
Cookie: [REDACTED]
Content-Type: application/json
{
  "phone_number": "+628123456789",
  "first_name": "EditedFirstName",
  "last_name": "EditedLastName",
  "date_of_birth": "1990-01-01",
  "id_number": "0000000000000000",
  "nationality": "Indonesia"
}

The server returned success.

That was interesting, but it was not enough.

With Mass Assignment testing, 200 OK is only a signal. Some APIs accept a body, return success, and silently drop fields they do not want to save. If the value does not persist, the finding is much weaker.

So I read the profile back from the application.

It confirmed. The sensitive fields had changed.

The legal name changed. The birthdate changed. The gender changed. The government ID number changed. The secondary registry identifier changed.

And the account still appeared verified.

That combination is what made the finding important. The issue was not just that a user could edit their own profile. The issue was that a user could rewrite identity fields while keeping the trusted state attached to the account.

Identity Drift

The account was not stolen. The attacker did not access another user’s session. The object being edited still belonged to the current user.

But the identity attached to that object could move.

If a user can change legal name, birthdate, gender, government ID number, and registry identifiers without re-verification, the stored person can stop matching the person the platform originally verified.

That is a different kind of impersonation.

It is not impersonation by logging into the victim’s account. It is impersonation by rewriting the attacker’s own trusted profile until the platform’s records point to someone else.

If an attacker knows enough identity attributes for a real person, the attacker-controlled account can be made to look like that person while still carrying a verified state.

The Second Escalation

The platform also allowed users to link an insurance or benefit record to their profile.

That flow relied on information from two places:

• data supplied during the linking request, such as member or policy details
• identity data already stored in the profile, rely only on the date of birth

This kind of matching is actually common. A platform needs some way to decide whether an insurance or benefit record belongs to the current user.

The problem was not the comparison itself. The problem was what the comparison trusted. The date of birth was coming from a profile field that users could modify through the Mass Assignment vulnerability.

If the profile is verified and immutable, comparing against it has value. If the profile can be changed seconds before the comparison, the check becomes much weaker.

The Mass Assignment bug changed what the insurance flow was really asking. It was no longer only asking whether the insurance record matched the originally verified person. It was also asking whether the record matched the current profile values. Those values were attacker-controlled.

The Chain

The chain was straightforward.

First, use an attacker-controlled account.

Second, change the profile identity through the Mass Assignment bug. For the insurance path, date of birth was the useful field because it was part of the matching logic.

PUT /api/v1/profile/{attacker_user_id} HTTP/2
Host: api.[REDACTED]
Cookie: [REDACTED]
Content-Type: application/json
{
"date_of_birth": "[TARGET_DOB]"
}

Third, submit the linking request with the target insurance or benefit data.

PUT /api/v1/benefits/link/{provider_id} HTTP/2
Host: api.[REDACTED]
Cookie: [REDACTED]
Content-Type: application/json
{
"member_id": "[TARGET_MEMBER_ID]",
"date_of_birth": "[TARGET_DOB]"
}

The insurance record successfully linked to the attacker-controlled account.

That is where the second impact appeared. The first impact was verified identity mutation. The second impact was downstream financial access.

The vulnerable endpoint looked like profile editing. The risk lived in what trusted that profile later.

Re-Evaluation

There is a common misunderstanding around self-profile bugs: if the user is editing their own account, the impact must be low. That is not always true.

The better question is: “what do the edited fields prove elsewhere?”

If the field is a first name before verification process, the answer may be nothing important.

If the field is a birthdate used for eligibility or matching, the answer changes.

If the field is a government ID number used for identity verification, the answer changes again.

If the account keeps its verified status after those values change, the impact changes even more.

In this case, the platform’s own product flow showed that these fields were sensitive. The user was not supposed to change them freely through the normal interface. Customer support or re-verification was the intended path.

The API bypassed that path, and another workflow trusted the result.

That is what made the finding more than “I can edit my profile.” It became “I can rewrite identity fields on a trusted account, then let another workflow trust the rewritten identity.”

Remediation

The fix is server-side field allowlisting.

Each update flow should define exactly which fields it is allowed to modify. A normal profile update endpoint should update only normal profile fields. Sensitive identity fields should not be writable just because they appear in the request body.

A safer model separates the data by trust level:

• ordinary profile fields that users can edit directly
• sensitive identity fields that require support or re-verification
• verification records that preserve what was checked and when
• insurance or benefit-linking data that must be matched against trusted records

The frontend can make the experience clearer, but it cannot be the control. Hidden fields, disabled inputs, and missing buttons do not protect an API.

The linking flow also needs to trust the right source. If birthdate is part of the matching logic, it should come from a record the user cannot freely rewrite immediately before linking the policy. If identity changes are allowed after verification, dependent insurance or benefit links should be reviewed, invalidated, or rechecked.

do not treat a profile value as proof unless the system also protects how that value is created and changed.

Mass Assignment is easy to underestimate when the request only changes fields on non impactful fields. But the real question is not only who owns the object. The real question is what authority each field carries after it is saved.

A birthdate can become an eligibility check. A government ID number can become identity evidence. A legal name can become a payout or policy-matching input. When those fields move without re-verification, every workflow that trusts them moves with them.

In this case, identity moved first.

Insurance followed.

That was the bug.