Gitlab has a backend, which runs on a server, and a frontend, which runs in all the user's browsers. When the user does anything it sends some network requests to the backend in order to save the changes the user has made, send the necessary emails or create a session, etc.

The thing with this architecture is the backend and frontend are effectively separate apps. Also as the frontend is running remotely on the attacker's computer the attacker can change it to behave however they want. The backend can't trust the frontend to "do the right thing", ever. The backend needs to assume the frontend will do every bad and silly thing possible, and treat anything coming from the frontend with maximum suspicion.

So you simply can't allow the frontend code to provide a list of email addresses to send an email to, because it'll allow the attacker to send emails to anywhere. Where the email goes to needs to be determined by the backend. The frontend should only be concerned with hiding and showing stuff in the UI, and pretty much all intelligence and business logic needs to reside on the server where we control the code and environment. A good understanding of the roles and responsibilities of the front vs back is a fundamental concept and if the developer hasn't grasped this then they're going to introduce security problems everywhere they go.

This is one of many pitfalls of the "frontend + backend" architecture. I vastly prefer to build monoliths instead.

Not the commenter but it seems like the parameters of the HTTP Get/Post weren't protected/checked. The API was likely something like: Email to reset: string(email account to reset) But it accepted something like: [string(email account to reset), string (email to which the reset mail is sent to)]