June 3, 2026
No Username. No Password. Just a Header — A $3,000 Authentication Bypass
First of all, Alhamdulillah. Every finding teaches something new, and this one reminded me that sometimes the most critical vulnerabilities…
ALR
2 min read
First of all, Alhamdulillah. Every finding teaches something new, and this one reminded me that sometimes the most critical vulnerabilities can be discovered through simple curiosity and a willingness to question assumptions.
Introduction
While performing reconnaissance on a target, I came across an interesting authentication bypass vulnerability that ultimately resulted in a Critical severity report and a $3,000 bounty.
The issue was discovered through a combination of JavaScript analysis, API endpoint enumeration, and understanding how the authentication mechanism was implemented behind the application.
This write-up explains the discovery process and the root cause of the vulnerability.
Testing and thinking
This finding started during a normal reconnaissance session.
While enumerating subdomains, I came across a subdomain that immediately redirected users to another website for authentication. At first, it looked like a standard login flow, so before allowing the redirect to complete, I opened the page source to see if there was anything interesting exposed.
Inside the source code, I found a JavaScript file being loaded by the application. Since JavaScript files often contain useful information, I downloaded it and started reviewing its contents.
My first goal was to extract any API endpoints used by the application.
After some quick analysis, I found several API endpoints and immediately opened Burp Suite to start testing them.
Unfortunately, every request returned the same response:
At that point, the endpoints appeared to be properly protected.
However, while looking at the responses, a question came to mind:
How does the application know that a user is authenticated?
Instead of continuing to test the endpoints blindly, I went back to the JavaScript file and started tracing the authentication logic used by the application.
After searching through the code, I found the following snippet:
a1&&n1.set(
"Authorization",
"Basic " +
btoa(
(a1.username || "") +
":" +
(a1.password
? unescape(encodeURIComponent(a1.password))
: "")
)
)a1&&n1.set(
"Authorization",
"Basic " +
btoa(
(a1.username || "") +
":" +
(a1.password
? unescape(encodeURIComponent(a1.password))
: "")
)
)This immediately caught my attention.
The application was using HTTP Basic Authentication and expected requests to contain an Authorization header built from a username and password.
My first thought was to search for valid credentials.
- I checked GitHub.
- I checked URLScan.
I searched for configuration files, leaked credentials, historical data, and anything that might reveal a username or password for the application.
After spending some time searching, I found nothing.
At that point, a different idea came to mind…………
Instead of trying to find valid credentials, what if the backend only checked whether the Authorization header existed?
To test this theory, I sent the same request again but added the following header:
Authorization: BasicAuthorization: BasicAfter send the request, the response came back:
The most interesting part was that the issue was not limited to a single endpoint. After discovering that simply adding the Authorization: Basic header bypassed authentication, I tested the same behavior across nearly 50 API endpoints extracted from the JavaScript file. The bypass worked consistently, providing access to functionality related to viewing, creating, modifying, and deleting customer data, as well as various internal system settings. No valid username or password was required — only the presence of the Authorization header.
This ultimately resulted in a Critical severity report and a bounty of $3,000.
Root Cause
The issue was caused by improper validation of HTTP Basic Authentication. The backend checked for the presence of the Authorization header but failed to properly validate the supplied credentials. As a result, requests containing Authorization: Basic without a valid username or password were incorrectly treated as authenticated.