Unique Username Validation Bypass to a Stored Open Redirect: How I Escalated a Bug Bounty Finding

Introduction

In bug bounty hunting, finding a vulnerability is only the first step.

Sometimes, the initial behavior you discover doesn't immediately reveal its real security impact. The interesting part begins when you ask:

"What else can I do with this?"

WhoAmI

I am Ankit Rathva and i am a student of MCA 2nd year, I am an ethical hacker and security researcher with a passion for finding logic, authorization, and data-integrity flaws in web applications. As a bug bounty hunter and red teamer, he combines hands-on testing, forensic analysis, and careful disclosure to help teams fix impactful issues while protecting users. He publishes clear, developer-friendly writeups and practical mitigation advice — connect to follow his work or collaborate on security research.

Connect with me: https://linkedin.com/in/ankitrathva

During a security assessment of Skillmate, I discovered that the username field on the profile page had client-side restrictions. The application told users that usernames could contain only lowercase letters, numbers, and underscores.

At first glance, this looked like a straightforward client-side input validation bypass.

However, I didn't stop there.

I tested whether the backend was actually enforcing the same restriction. Using Burp Suite, I was able to modify the request and submit characters that the frontend rejected.

That confirmed that the backend was accepting invalid usernames.

But the real impact appeared during deeper testing.

I discovered that I could set my username to a URL such as:

https://evil.com

When another user viewed my profile, they could be redirected to that attacker-controlled URL.

This transformed the finding from simply "invalid characters can be stored" into a much more meaningful stored malicious redirect scenario, with potential phishing and social-engineering implications.

Eventually, Skillmate accepted the report and recognized the finding on their Hall of Fame page.

The Initial Discovery

While testing the Skillmate profile functionality, I noticed that the username field had input restrictions.

The application displayed an error similar to:

Username can only contain small letters, numbers, and underscores

For example, if I entered:

test@123

test@123

the frontend rejected the value.

The expected format appeared to be something similar to:

^[a-z0-9_]+$

^[a-z0-9_]+$

So initially, everything seemed to be working correctly.

But whenever I see an important validation rule implemented on the frontend, I ask myself:

Is the backend enforcing the same rule?

That's where Burp Suite became useful.

Bypassing the Frontend Validation

I entered a valid username and clicked Save Changes while intercepting the request using Burp Suite.

The request contained the username parameter.

Instead of changing the value through the frontend, I modified the request directly.

For example:

username=testuser

username=testuser

was changed to:

username=@!@#$%

username=@!@#$%

I then forwarded the modified request.

The backend accepted the request.

After returning to the profile page, the username had been updated despite the frontend explicitly stating that these characters were not allowed.

Steps to reproduce

1. Entering @!@#$% into the username field.
2. Frontend displaying the validation error.
3. Entering a valid username.
4. Intercepting the request in Burp Suite.
5. Modifying the username parameter.
6. Forwarding the request.
7. Showing the invalid username saved successfully.

Suggested caption: Bypassing client-side username validation using Burp Suite

Initial Report

I reported the issue as a Client-Side Input Validation Bypass.

The initial report explained that:

• The frontend restricted usernames to lowercase letters, numbers, and underscores.
• The restriction could be bypassed by modifying the request.
• The backend accepted and stored characters that were rejected by the frontend.
• This could potentially create problems wherever usernames were trusted or processed elsewhere in the application.

I also recommended that the validation should be enforced server-side rather than relying solely on client-side controls.

The Response From Skillmate

Skillmate responded professionally and asked some important questions.

They wanted to understand:

What the broader security impact could be.

They specifically asked how the issue could affect areas such as:

• Authentication
• Rendering
• Search functionality
• Other application logic

This was an important moment in the investigation.

Instead of simply arguing that the validation bypass was impactful, I decided to investigate further.

Going Beyond the Validation Bypass

This is one of the biggest lessons I learned from this report:

Don't stop when you prove that a security control can be bypassed. Find out where the resulting data goes.

I started testing different values in the username field.

Instead of using only special characters such as:

@!@#$%

@!@#$%

I tested a URL-like value:

https://evil.com

https://evil.com

The backend accepted it.

That immediately raised another question:

How does the application handle this value when another user views the profile?

The Interesting Behavior

I saved:

https://evil.com

https://evil.com

as my username.

Then I accessed the profile from another account.

This is where the behavior became significantly more interesting.

When the other user attempted to view my profile, the application redirected the user to:

https://evil.com

https://evil.com

The stored username was therefore not simply being displayed as text.

It was being interpreted in a way that could cause navigation to an external attacker-controlled domain.

1. Setting the username to [https://evil.com](https://evil.com.).
2. Saving the profile.
3. Opening the profile from another account/browser session.
4. Showing the browser navigating to the external domain.

Suggested caption: A malicious URL stored as the username causes a profile visitor to be redirected

Why This Changed the Severity of the Finding

The original finding was about bypassing an input validation rule.

But the deeper test demonstrated something much more important.

An attacker could potentially:

1. Create or control an account.
2. Set the username to an attacker-controlled URL.
3. Have that value stored by the application.
4. Share or expose the attacker profile to other users.
5. Cause profile visitors to navigate to the attacker-controlled destination.

For example:

Attacker Profile
       ↓
Username = https://evil.com
       ↓
Victim visits profile
       ↓
Application processes stored username
       ↓
Victim is redirected
       ↓
Attacker-controlled website

Attacker Profile
       ↓
Username = https://evil.com
       ↓
Victim visits profile
       ↓
Application processes stored username
       ↓
Victim is redirected
       ↓
Attacker-controlled website

This creates a potential phishing and social-engineering attack path.

An attacker could potentially host a convincing login page or another malicious landing page on the destination and attempt to trick users into entering sensitive information.

I did not attempt to collect credentials or perform any destructive actions. The goal was simply to demonstrate that the stored value could cause navigation to an attacker-controlled domain.

The Follow-Up Report

I went back to Skillmate with the additional evidence.

I explained that the impact was not limited to storing invalid characters.

The important proof of concept was:

Username:
https://evil.com

Username:
https://evil.com

After saving the value, another user visiting the profile could be redirected to the attacker-controlled domain.

I included a video PoC demonstrating the behavior.

This provided the security team with a much clearer understanding of the practical impact.

The Final Outcome

After I submitted the additional proof of concept and demonstrated the real-world behavior, Skillmate accepted the report.

What started as:

"The username field accepts invalid characters."

turned into a much more meaningful security finding:

"An attacker-controlled URL can be stored as a username and can cause profile visitors to be redirected to an attacker-controlled domain."

Skillmate ultimately recognized the contribution on their Hall of Fame page.

For me, the most valuable part wasn't simply receiving recognition.

It was learning how important it is to investigate the impact chain rather than stopping at the first vulnerability you discover.

Final Thoughts

This finding reminded me of one of the most important principles in bug bounty hunting:

Finding the bug is only half the job. Understanding the impact is the other half.

A username field looked like a simple validation issue.

But by bypassing the frontend restriction, tracing how the value was stored, and testing how it was handled when another user viewed the profile, I was able to uncover a much more interesting attack scenario.

The biggest lesson for me was simple:

Don't stop at "I can bypass it."

Ask:

"What happens next?"

That question can make all the difference.

Thanks for Reading!

If you found this write-up useful, feel free to share it with other security researchers.

I'll be sharing more of my bug bounty findings, methodologies, and lessons learned from real-world web application security testing.

Keep learning. Keep testing. Keep hacking responsibly. 🔐

#BugBounty #CyberSecurity #WebSecurity #EthicalHacking #BurpSuite #ApplicationSecurity #PenetrationTesting #InfoSec #ResponsibleDisclosure