The authoritative source for the definition, vulnerable patterns, example attack scenarios, and prevention guidance in this module. The three attack scenarios on slides 14–16 are drawn directly from the OWASP API3 page (dating app location leak, marketplace price manipulation, social media moderation bypass). CWE references: CWE-213 (Exposure of Sensitive Information Due to Incompatible Policies), CWE-915 (Improperly Controlled Modification of Dynamically-Determined Object Attributes). This course is an independent study companion — not affiliated with or endorsed by OWASP.

Developer Egor Homakov exploited Ruby on Rails' auto-binding (mass assignment) feature to associate his own SSH public key with the Ruby on Rails GitHub organization. He added a single extra parameter — public_key[user_id]=4223 — to a form POST. Rails' update_attributes() bound all incoming parameters to the model, including user_id, without restriction. Homakov then pushed a commit to the Rails master repository with a timestamp of the year 3012 to demonstrate write access. GitHub patched the endpoint within 1 hour; the Rails team added mass assignment protection (attr_accessible / strong parameters) within 5 hours. Homakov had reported the underlying Rails vulnerability before demonstrating it. Referenced in slides 1, 5, 13, 20, 26.

Security researcher Jan Masters at Pen Test Partners discovered that Peloton's user profile API endpoint returned the complete user object — including age, gender, city, weight, birthday, and workout statistics — regardless of whether the account was marked as private. The privacy setting only affected what the official Peloton app displayed; the API itself made no distinction between private and public accounts. Any authenticated Peloton user could enumerate other users' full profiles. Affected approximately 4 million users. Peloton was first notified in January 2021. Their initial fix (adding authentication) did not resolve the property-level exposure. Full remediation took over 90 days. Referenced in slides 11, 23, 26.

Official Rails documentation on mass assignment vulnerabilities and the Strong Parameters API (params.require().permit()) introduced in Rails 4 to replace the insecure attr_accessible approach. Background for slides 5, 13, and 20.

Framework-specific guidance on preventing mass assignment vulnerabilities in Node.js, Spring MVC, ASP.NET MVC, Laravel, Ruby on Rails, Grails, Play, and Django. Directly informs mitigations MIT 01 and MIT 02 in this module.

Guidance on identifying and protecting sensitive properties in API responses, including the use of response DTOs and schema-based validation to prevent excessive data exposure. Informs mitigations MIT 03, 05, 06, and 07 in this module.

Free interactive lab for practicing mass assignment attacks against an API. Recommended hands-on practice after completing this module — lets you experience exactly how adding an extra JSON field to a PATCH request can escalate your price to zero.

Homakov's own write-up of the GitHub mass assignment breach, explaining his motivation (he had reported the vulnerability and was ignored), the exact HTTP request he sent, and the timeline of events. One of the clearest first-person accounts of a responsible disclosure that escalated to a demonstration. Search for "homakov github mass assignment" to find archived copies.