Broken Access Control
Echo's Wishlist
Echo keeps a wishlist app for the team. You can edit your name and bio — that's all the page lets you touch. But the server is less picky than the page about what it accepts, and Echo keeps the good gifts behind a members-only door.
Your profile only shows two editable fields. The API that saves them, though, trusts whatever you send it. Look closely at what your profile actually contains, then think about what else the save endpoint might happily accept.
Find the flag, in the format SPAM{this_is_an_example}. This container resets every 24 hours.
What's the vulnerability?
- Mass assignment: an endpoint copies every field from the request body onto a server object, trusting the client to only send "safe" ones.
- The UI showing just name and bio is not a security control — the API accepts far more than the form displays.
- Privileged fields like
roleortierbecome attacker-controlled.
Why does it matter?
A regular user can promote themselves, flip feature flags, or change ownership — whatever extra fields the model exposes — just by adding them to a normal save request the UI never meant to send.
How to fix it
Bind only an explicit allow-list of fields on the server (name, bio — nothing else). Never assign request bodies wholesale onto domain objects, and enforce authorization server-side for every privileged field.