Mass Assignment: The Silent Killer of Application Security
In March 2012, Egor Homakov performed one of the most famous exploits in application security history: he acquired write rights to Ruby on Rails's GitHub repository and committed directly to its master branch. The commit is still visible for all to see (here). How was Homakov able to do this? He exploited a vulnerability in GitHub's API that allowed him to overwrite arbitrary server-side properties. Specifically, he bound his own SSH key to the profile of another user with commit rights to Ruby on Rails's repository.
A mass assignment request looks like an ordinary profile update. The injected role: admin field rides along with the legitimate fields and never trips a signature-based defence.
The vulnerability Homakov exploited is known as mass assignment, and it's one of the leading categories in the OWASP API Security Top 10 (API3:2023, folded under Broken Object Property Level Authorization or BOPLA). Mass assignment happens when a user can modify object properties they shouldn't be able to change. Typically, we call those properties server-side or read-only fields. For example, we shouldn't be able to modify the price of a basket when placing an order online, elevate our privileges by overriding our user role, or change the visibility of a document that doesn't belong to us. All of these are examples of mass assignment. I go deeper into the technical aspects of mass assignment in my book Secure APIs (Manning Publications, 2025, chapter 4.6). In this article, we look at the current cybersecurity landscape regarding this type of exploit.
Homakov's exploit happened fourteen years ago. But make no mistake. Mass assignment is as critical today as it was in 2012. For example, a bounty report from 2024 found that users of the bounty management platform HackerOne could upgrade their pentest opportunities to a premium package by overriding the package_name field on the AutosavePentestOpportunity mutation[1].
Mass assignment is a silent killer in application security. Why is that? Because requests carrying mass assignment attacks look like normal, legitimate requests. For example, imagine an endpoint PUT /profile that allows a user to update their personal details, such as their name, surname, age, email address, and more. If the endpoint were vulnerable to mass assignment, a user could escalate their privileges by sending a perfectly fine-looking request like this:
PUT /profile
{"name": "Sarah", "surname": "Connor", "role": "admin", ...}
Requests like this don't contain a clear attack fingerprint, the way SQL injection and similar attacks do. They look perfectly normal, which is why they sneak under the radar. Web Application Firewalls (WAFs) are blind to these attacks, and even the best real-time monitoring systems fail to detect them. The effective strategy is robust schema validation at the gateway, before data enters the controller. However, that requires clear-cut, well-defined API specifications that many organisations simply lack.
Mass assignment today
How bad does it get in the real world? The OWASP API Security Top 10 ranks mass assignment (the write half of BOPLA) among the top three categories. We see the same in practice: mass assignment is a routine detection in the APIs we scan at APIsec, not an exotic edge case. But detections are cheap, and that's where most tooling stops. The challenge is confirming which detections are exploitable, and that's where APIsec comes in.
From a technical point of view, mass assignment is a vulnerability that allows threat actors to override server-side fields. From a business perspective, the consequences are atrocious. Mass assignment leads to exploits such as privilege escalation, account takeover, resource hijacking, and more. Let's look at some examples (in the examples below, the incident date given is the disclosure date).
In 2024, MTN Group was found vulnerable to account takeover by overriding the server-side property gateway and setting it to true, which would cause the server to bypass password validation on login (POST /app/login)[2].
In 2022, GitLab was vulnerable to resource hijacking by overriding server-side properties like issue_ids, merge_request_ids, note_ids, and board_ids on its /import/gitlab_project endpoint, allowing a threat actor to attach other projects' private records[3].
Also in 2024, Rocket.Chat was found vulnerable to privilege escalation via the insertOrUpdateUser method, which allowed guest users to assign themselves a bot role by overriding the roles field, and after a series of iterations, escalate to full admin role[4].
Why is mass assignment a problem?
Mass assignment has tremendous consequences for businesses. Identity takeover, resource hijacking, and privilege escalation are bad enough, but mass assignment also enables exploits where threat actors can take advantage of your business at your expense. For example, a HackerOne report found that threat actors could self-approve and activate ad campaigns on Reddit, bypassing both the payment and the due review process. This was possible due to a mass assignment vulnerability on the PATCH /accounts/{id}/ads/{id} endpoint, by overriding server-side properties like admin_approval, effective_status, and configured_status[5].
The nature of the vulnerability makes it difficult to test. You have to understand the internal application model to target the right fields in the test. A standard fuzzer won't do. You need a system that can build a model of your application to craft carefully targeted attacks.
And it needs sophisticated exploit validation techniques. If we've learned something at APIsec, it's that a 200 response status code to a mass assignment test isn't proof of exploit. Even when the injected fields are reflected in the response with the overridden values, we are still far from confirming that the exploit worked. A robust confirmation process requires the testing framework to read back the details of the overridden resource, often via a separate endpoint, or to put the resource to work in an unrelated business flow.
For example, in the Reddit report we discussed earlier[5], the mass assignment request on the PATCH /accounts/{id}/ads/{id} endpoint may come back with a 200 status code, but the job isn't done until we've retrieved the details of the ad campaign through the GET /accounts/{id}/ads/{id} endpoint, or even better, until we confirm that the campaign is indeed operative. These are complex tasks that most other platforms can't handle right out of the box.
The alternative is to do this manually, which is inefficient and doesn't scale well. Or to use LLMs to surface mass assignment sinks from code. However, code analysis isn't the full story, and runtime validation is required to verify that the code-level findings are indeed exploitable. That's where APIsec's Application Exploit Validation (AEV) methodology comes in.
Fixing mass assignment isn't easy either. For example, GitLab addressed the vulnerability we discussed earlier where a threat actor could take over other projects' private records. The fix consisted of a blocklist of forbidden fields. However, a later report found it was possible to bypass GitLab's fix by injecting the server-side properties as nested attributes of the request payload, as in attributes.issue_ids[6].
Wrapping up
The examples we've discussed bring valuable lessons:
- Mass assignment is a vulnerability that critically compromises your cybersecurity posture and your business cashflow.
- You can't WAF your way out of mass assignment. To discover and address this type of vulnerability, you must proactively test your applications.
- You can't blocklist your way out of mass assignment. Preventing it requires using robust data validation and transfer patterns within the application.
- Mass assignment is difficult to test reliably at scale.
For all those reasons, mass assignment remains one of the most prevalent and critical problems in the modern application security landscape, and it shows no signs of going away.
What about you? How confident are you in your application's ability to fend off mass assignment attacks? Scan your API on APIsec for mass assignment vulnerabilities to find the answer.
References
package_name override on the AutosavePentestOpportunity mutation. [Online]. Available: https://hackerone.com/reports/2431495gateway field to bypass login password validation. [Online]. Available: https://hackerone.com/reports/1709881bot and then admin via the roles field on insertOrUpdateUser. [Online]. Available: https://hackerone.com/reports/501081admin_approval, effective_status, and configured_status. [Online]. Available: https://hackerone.com/reports/1543159attributes.issue_ids. [Online]. Available: https://hackerone.com/reports/767770