Bypassing Client-Side Authentication and Authorization

Hello! In our last lesson, we delved into bypassing Multi-Factor Authentication, exploring techniques like brute-forcing OTPs and manipulating server responses. That final technique—intercepting a response and changing a failure message to a success message—is a perfect gateway to today's topic.

This lesson focuses on a fundamental principle of web security: never trust the client. We will explore the learning outcome: Exploit insecure client-side controls that attempt to enforce authentication or authorization.

Many applications attempt to enforce security rules in the user's browser (the client-side) for a smoother user experience. For example, hiding an "Admin Panel" button from regular users or disabling a "submit" button until a form is filled correctly. However, these are merely suggestions. As an attacker, you have complete control over the client and can ignore, modify, or bypass these controls. True security must be enforced on the server.

Today, we'll examine how to identify and exploit vulnerabilities that arise when an application improperly delegates security decisions to the client. We'll cover everything from manipulating prices in an e-commerce site to escalating your privileges to an administrator, and we'll cap it off with a deep dive into a recent, real-world vulnerability in a popular web framework.

1. The Core Flaw: Misplaced Trust

Before we start exploiting, it's crucial to understand why these vulnerabilities exist. They all stem from a developer making security decisions based on data that the client provides or controls, without validating it on the server. Since you, the attacker, control the client, you can tamper with this data.

Your Computer Science background gives you a solid understanding of the client-server architecture. This entire lesson is about exploiting the boundary between them when the server trusts the client's messages more than it should.

Broken Access Control | Complete Guide

To build our foundation, let's watch a few segments from Rana Khalil's 'Broken Access Control | Complete Guide'. She provides an excellent conceptual overview of why trusting client-side parameters is so dangerous.

Please watch the following segments: 11:08 - 14:48: Watch the clear explanations of horizontal and vertical privilege escalation. Notice how both are achieved by simply changing a client-controlled parameter in the request (id=123 or admin=false). 18:43 - 20:52: This is a code-level walkthrough of a missing access control check. This shows exactly how such a vulnerability is introduced in code—a simple missing 'if' statement on the server. 38:20 - 39:03: This segment summarizes the key principle for prevention: access control checks must always be performed on the server side. Focus on how, in each case, the application is making a critical security decision based on untrusted input from the client.

The key takeaway is that any piece of information coming from the client—whether it's a URL parameter, a hidden form field, a cookie, or an HTTP header—can be manipulated. If the server uses that information to decide "Is this user an admin?" or "What price should this customer pay?", it's likely vulnerable.

2. Practical Exploitation: From Price Tampering to Privilege Escalation

Now, let's move from theory to practice. The following video demonstrates several real-world examples of bypassing client-side controls. These are exactly the kinds of bugs that have high impact and earn significant bounties.

We'll focus on two primary attack patterns:

Bypassing Business Logic: Manipulating application logic, like payments, for financial gain.
Vertical Privilege Escalation: Granting your low-privilege user account administrative or premium capabilities.

Payment Bypass Vulnerability | Step-by-Step Bug Bounty Tutorial

The video 'Payment Bypass Vulnerability' by ZACK0X01 is a masterclass in exploiting misplaced client-side trust. We'll see how to get paid content for free by simply telling the application it's free.

Watch these two key demonstrations: 02:26 - 04:48 (Price Tampering): The attacker intercepts a server response that contains the price of a course ("price": "$99"). They modify this to "$0" and forward it to the browser. The client-side code, trusting this response, then renders the course as free and allows the purchase. 13:12 - 17:06 (Privilege Escalation): Here, the application fetches the user's account status ("user_type": "free"). The attacker intercepts this response and changes the value to "paid" or "premium". The client-side UI then unlocks all paid features, because it was told the user is a premium member.

These examples beautifully illustrate the core issue. The server-side logic was flawed:

In the payment example, the server should have re-validated the price during the final checkout step, not trusted the price the client submitted back to it.
In the privilege escalation example, the server should re-validate the user's subscription status from its own database before serving any premium content, not just trust a flag set in the client's session.

Test your understanding!

You are testing a web application where users can have roles like "viewer", "editor", and "admin". When you log in as a "viewer", you notice in your browser's localStorage a key-value pair: userInfo: {"role": "viewer"}. The application UI correctly shows you only viewer-level options.

How would you test for a client-side authorization vulnerability?

Show answer

You would use the browser's developer tools (F12) to modify the localStorage object. You would change the value of the role from "viewer" to "admin". After modifying it, you would refresh the page. If the application now renders the administrative UI and, more importantly, the server allows you to successfully perform administrative actions, you have found a critical vertical privilege escalation vulnerability. The application was trusting the role value stored on the client instead of enforcing it based on a server-side session.

3. Expanding the Attack Surface

The vulnerabilities we've seen are just a few examples of a broader class of bugs. Client-side controls can be implemented in many ways, and thus can be bypassed in many ways.

The following reading from PortSwigger provides a more systematic overview of different vectors for this kind of attack.

Access control vulnerabilities and privilege escalation

Let's expand our toolkit. PortSwigger's 'Access control vulnerabilities and privilege escalation' article details several other ways attackers can bypass controls that rely on client-side information.

Please read the following sections: 'Unprotected functionality': This covers how attackers can access functionality (like an admin panel) that is simply hidden from the UI. Even if there's no link, the endpoint might still be accessible if you can guess its URL (e.g., /admin). 'Parameter-based access control methods': This is what we saw in the Rana Khalil video. It covers modifying parameters in hidden fields, cookies, or the URL (e.g., ?admin=true) to escalate privileges. 'Access control vulnerabilities in multi-step processes': Sometimes, only the first step of a process is protected. An attacker might be able to skip directly to step 2 or 3, bypassing the initial check. 'Referer-based access control': A classic flaw where the server checks the Referer header to see if you came from an authorized page. Since you control all headers, you can forge this and gain access.

This reading adds several attack vectors to your mental checklist:

Forced Browsing: Don't just rely on the UI. Always try to guess or discover URLs for privileged areas (/admin, /config, /dashboard).
Parameter Tampering: Look for any parameter in the URL, request body, or cookies that looks like it might control access (isAdmin, role, user_level). Change it and see what happens.
Workflow Bypass: If an action takes multiple steps, try to perform the last step first.
Header Forging: Check if the application uses headers like Referer or X-Forwarded-For for security, and then forge them.

4. Case Study: A Modern, Real-World Framework Bypass

These vulnerabilities aren't limited to simple or old applications. They can exist in complex, modern frameworks used by major companies. Analyzing a real CVE (Common Vulnerabilities and Exposures) is excellent practice.

Let's look at a recent vulnerability in Next.js, a very popular React framework.

CVE-2025-29927: Next.js Middleware Authorization Bypass

To see how these principles apply at an expert level, let's analyze a real-world critical vulnerability: the Next.js Middleware Authorization Bypass (CVE-2025-29927). This write-up from ProjectDiscovery is a perfect example of a high-impact bug you might find.

Please read the following sections of the blog post: 'The Next.js Middleware': Understand that middleware is code that runs before the main request is handled, often used for authentication. 'The vulnerability mechanism': This is the core of the issue. A special HTTP header, x-middleware-subrequest, was intended for internal use but could be sent by an attacker. When the server saw this header, it would skip the authorization middleware entirely. 'Exploitation Across Different Next.js Versions': Look at the practical payloads. This is exactly what a tester would use in Burp Suite. (The GET request example): This shows a simple, complete exploit request. This is a sophisticated but clear example of our lesson's theme: the server trusted a client-controlled header to make a security-critical decision.

This CVE is a powerful lesson. A feature designed for the framework's internal workings was unintentionally exposed to client control. An attacker who discovered this could add a single header to their request and bypass the application's primary authentication and authorization mechanism.

Conclusion

The boundary between the client and the server is a fertile ground for vulnerabilities. As a penetration tester or bug bounty hunter, you must cultivate a deep-seated distrust of anything the client can control. Client-side controls are for user experience and aesthetics; they are not, and never should be, a security mechanism.

Key Takeaways:

The Golden Rule: All authentication and authorization checks must be enforced on the server, using data the server owns and trusts (like a server-side session object), not data provided by the client.
Your Toolkit: An interception proxy like Burp Suite is your best friend. Use it to inspect and tamper with every part of an HTTP request and response: URLs, headers, cookies, and the request/response body. Browser developer tools are also essential for manipulating client-side scripts and storage.
Common Targets for Manipulation:
- Prices, quantities, or product IDs in e-commerce apps.
- User roles, permissions, or status flags (isAdmin, isPremium).
- Hidden form fields that might control application logic.
- Headers like Referer or even non-standard ones like X-Original-URL.
- Any data stored in cookies or localStorage that seems security-related.

Next Lesson Preview:
In this lesson, we explored a broad category of flaws based on trusting the client. In our next lesson, we will kick off a new module, "Authorization Bypass & Logic Flaws," by focusing on one of the most common and impactful vulnerabilities in this category: Insecure Direct Object References (IDOR). IDOR is a specific type of authorization flaw where you can access other users' data (e.g., profiles, messages, orders) by simply changing an ID in the URL, like .../viewOrder?id=123 to .../viewOrder?id=124.