When the Admin Panel Forgot About Authentication

Challenge

This started like most of my web security testing does: understand the target before trying to break anything.

The application was built using Next.js 14, so the first goal was simply to map out what was exposed. I spent some time understanding the application's structure, technologies, routes, and general behavior before moving into deeper testing.

I started with basic reconnaissance and subdomain enumeration, hoping there might be additional applications, staging environments, APIs, or forgotten services worth investigating.

That didn't lead anywhere interesting.

So instead of spending too much time forcing that direction, I moved on to the application itself.

And that's where things got interesting.

Approach

Since this was a Next.js application, I started looking through the JavaScript chunks delivered to the browser.

Frontend bundles can reveal quite a lot about how an application is structured. Route names, API paths, feature flags, internal components, and sometimes functionality that isn't directly linked anywhere in the UI can still end up inside client-side JavaScript.

While going through the chunks, I found something that immediately stood out:

/admin/users

Naturally, I tried opening it.

I expected one of three things:

• a redirect to the login page,
• a 401 Unauthorized,
• or a 403 Forbidden.

Instead, the admin dashboard loaded.

No admin session. No authorization check. Nothing stopping an ordinary visitor from accessing functionality that clearly belonged behind an administrative boundary.

At that point, the issue had moved beyond an accidentally exposed frontend route. The next question was much more important:

Was the backend actually enforcing authorization?

Following the API

I opened Burp Suite and started observing the requests generated by the admin interface.

One request immediately caught my attention:

/api/users/all

The endpoint returned a paginated list of application users.

More importantly, the response exposed information that should never have been available to an unauthenticated user, including sensitive account and profile data such as:

• names,
• email addresses,
• phone numbers,
• addresses,
• password hashes,
• and additional user information.

The password values were hashed, but that doesn't make exposing them acceptable.

Password hashes should still be treated as sensitive authentication material. An attacker obtaining them could attempt offline cracking, credential analysis, or use the data as part of a larger attack.

At this point, it became clear that this wasn't just an exposed admin page.

The application's authorization model itself was broken.

Going Deeper

I continued mapping the APIs used by the dashboard.

Several other administrative endpoints appeared to have the same problem: they trusted requests without consistently verifying whether the person making them was actually authorized to perform the operation.

A few endpoints did perform role checks, which initially looked like a stronger boundary.

There was just one problem.

Another exposed API allowed modification of user privileges.

That meant the authorization boundary could effectively be bypassed by changing the account's own role.

The attack path became something like:

Unauthenticated Access → User Data Exposure → Role Modification → Administrative Access

Through the vulnerable authorization flow, an ordinary account could potentially elevate itself to a highly privileged administrative role.

Once that level of access was obtained, functionality intended exclusively for administrators became reachable, including administrative account-management operations.

In practical terms, the vulnerability had escalated from information disclosure into privilege escalation and potential administrative account takeover.

That changed the severity considerably.

Technical Concepts

The main vulnerability here was Broken Access Control.

One of the easiest mistakes to make when building modern web applications is treating frontend restrictions as security controls.

For example, an application might contain logic similar to:

if user is admin:
    show admin dashboard

That can improve the user experience, but it does not provide meaningful security.

An attacker doesn't need to use the application's intended interface. They can discover routes, inspect JavaScript bundles, intercept requests, and communicate with backend APIs directly.

The actual security boundary must therefore exist on the server:

request
   ↓
authentication
   ↓
authorization
   ↓
permission / ownership validation
   ↓
business logic
   ↓
database

Every sensitive endpoint needs to independently answer two questions:

Who is making this request?

and

Is this user actually allowed to perform this specific action?

If either check is missing, the fact that the frontend hides a button or page is irrelevant.

Another important concept demonstrated here was privilege escalation.

Even when some administrative endpoints correctly required an admin role, allowing users to modify their own roles destroyed that protection.

Authorization controls are only as strong as the weakest path capable of modifying the authorization state.

Tools

Burp Suite

Burp Suite was the main tool used for inspecting application traffic.

Once the admin interface was discovered, intercepting and reviewing its requests made it possible to understand which APIs powered the dashboard and what authorization controls existed behind them.

Browser DevTools

Browser DevTools helped with understanding the application structure, loaded resources, network activity, and JavaScript chunks.

JavaScript Analysis

Analyzing the Next.js client bundles turned out to be one of the most valuable parts of the process.

The /admin/users route wasn't discovered through brute force or a massive wordlist. It was found by understanding what the application itself was shipping to the browser.

That is an important distinction.

Sometimes reconnaissance isn't about sending more requests.

Sometimes the application has already handed you the map.

Lessons

The biggest lesson from this research was that authentication and authorization cannot be treated as frontend features.

Protecting an /admin page in the UI means very little if /api/admin/* accepts requests without performing equivalent server-side checks.

The second lesson was about chaining vulnerabilities.

Finding /admin/users was interesting.

Finding /api/users/all made it significantly worse.

Discovering that sensitive user information was exposed increased the impact again.

Finding a path to manipulate privileges turned several individual weaknesses into a much more serious attack chain.

That's something I've started paying much more attention to during security testing:

Don't only ask what one vulnerability can do. Ask what it allows you to reach next.

The research also changed how I look at my own projects.

When you're building an application, especially when moving quickly with frameworks, generated code, or AI-assisted development, it's surprisingly easy to think:

"The admin page is protected, so we're good."

But the page isn't the security boundary.

The APIs are.

Every sensitive backend operation should enforce authentication and authorization independently. Role changes should be heavily restricted. Sensitive fields should never be returned unless absolutely necessary, and password hashes should never be included in ordinary API responses.

A useful rule I took away from this is:

Assume the attacker already knows every frontend route and every API endpoint.

Then design the backend so that knowing those endpoints gives them absolutely nothing they aren't authorized to access.

This started as basic reconnaissance on a Next.js application and ended up being one of those findings that reinforces why access-control testing matters so much.

Sometimes the interesting vulnerability isn't hidden behind some complicated exploit.

Sometimes you find /admin/users, open it...

and it just works.

That's when you know it's going to be an interesting day.