The Frontend Hid It, The API Didn’t

A few years back, after a super hectic week in the office, I was just chilling on a weekend My plan was simple get some rest, watch a few videos, and do absolutely nothing security related for a day :)

Then one of my friends called me.

He was a member of Synack Red Team (SRT) and had received an invitation to hunt on a private program. Since he was busy with some other work, he asked me if I wanted to take a look at it.

I was free anyway, so I said:

"Why not? 😄"

A few minutes later he shared the scope details with me.

The scope was pretty small. In fact, there was only the main application in scope. The application was related to forex trading.

Usually when I get access to a new target, the first thing I do is click around randomly and try to understand how the application works before looking for anything specific.

So I opened my laptop, started Burp Suite in the background, logged into the application, and began exploring different functionalities.

For almost an hour I found nothing interesting.

Everything looked normal.

Profile page.

Dashboard.

Settings.

Notifications.

The usual stuff.

Then I landed on the My Account page.

I started checking what information a user could modify.

Name? Yes.

Phone number? Yes.

Profile details? Yes.

Email address? No.

There was no option to change the email address.

Normally I would have moved on and looked elsewhere, but for some reason I started wondering:

"If users can't change their email address from the UI, does the backend actually block it as well?"

That simple question eventually led me to discover a vulnerability that could turn a temporary session compromise into a full account takeover.

Taking a Closer Look

The application allowed users to update their profile information through the My Account section.

I updated some random profile details and intercepted the request responsible for saving account information.

The request was sent to:

PUT /api/v1/profile

I sent the request to Burp Repeater and started reviewing the parameters.

At first glance, everything looked normal.

Then I noticed something interesting.

Even though the email address wasn't editable from the frontend, I wondered what would happen if I manually added an email parameter to the request.

So I modified the request and inserted my own email address.

Something like:

{
  "email": "attacker@example.com"
}

{
  "email": "attacker@example.com"
}

I clicked Send.

The response came back successfully.

No validation error.

No warning message.

No access restriction.

Nothing.

At this point I wasn't sure whether the email had actually changed or not.

So I decided to verify it.

Confirming the Finding

I logged out of the application and clicked on the password reset functionality.

Instead of entering the original email address associated with the account, I entered the email address that I had injected through Burp Suite.

A few seconds later I received a password reset email.

That was the moment I realized the application had actually accepted the email modification.

The frontend was hiding the functionality. The API wasn't. And that difference was enough to create a security issue. But things got even more interesting. :)

The Unexpected Twist

I clicked the password reset link expecting to land on a reset password page. Instead, I was welcomed by a beautiful 404 page.

For a few seconds I thought the attack chain had reached a dead end.

Then I started looking at the URL more carefully.

The reset link pointed to:

www.target.com

While exploring the application earlier, I remembered seeing another subdomain:

app.target.com

Out of curiosity, I replaced the domain in the password reset URL.

I pressed Enter.

And suddenly the password reset page loaded successfully.

At that point I couldn't help but laugh a little.

Sometimes the best findings appear right after the moment you convince yourself there's nothing left to test.

Exploitation Flow

The complete attack chain looked like this:

1. Obtain access to an active user session.
2. Navigate to the My Account section.
3. Intercept the profile update request.
4. Send the request to Burp Repeater.
5. Add an email parameter containing an attacker-controlled email address.
6. Submit the modified request.
7. Log out of the application.
8. Trigger the password reset functionality.
9. Enter the attacker-controlled email address.
10. Receive the password reset email.
11. Replace the domain in the reset URL.
12. Set a new password.
13. Log in to the account.

The account was now under the attacker's control.

Why Did This Happen?

The root cause was surprisingly simple.

The developers had removed the email change functionality from the frontend, probably because users were not supposed to modify their email addresses. However, the backend API still accepted email updates.

As a result, anyone capable of modifying requests could update the email address directly through the API.

To make matters worse, there was no verification process for the newly supplied email address.

The application simply trusted whatever email address was provided.

Impact

The vulnerability required access to an active user session, which reduced the severity of the finding.

However, once an attacker obtained a session through another attack vector, they could use this issue to establish persistent control over the account.

An attacker could:

• Replace the victim's email address.
• Receive password reset emails.
• Reset account credentials.
• Maintain long-term access to the account.

What initially looked like a temporary session compromise could therefore become a much more persistent account takeover scenario.

Lessons Learned

One lesson that applies equally to bug hunters and developers is this:

The frontend should never be treated as a security boundary.

For bug hunters, hidden functionality is often worth investigating because what is removed from the interface isn't always removed from the backend.

For developers, hiding a feature in the UI doesn't automatically make it inaccessible if the underlying API still supports it.

The real source of truth is always the server-side logic and the controls enforcing it.

In this case, the email change option was absent from the user interface, giving the impression that users could not modify their email addresses.

However, the backend API continued to accept email updates without proper restrictions or verification.

That gap between what the frontend exposed and what the backend allowed created the vulnerability.

It's a good reminder that security controls should be enforced where they matter most: on the server, not in the interface.

Just because a feature isn't visible on the frontend doesn't mean it doesn't exist.

Hope you enjoyed the write-up.

Happy hunting!