DEV Community: Abhinav Singwal

How to Find People on the Internet

Abhinav Singwal — Sat, 25 Jul 2026 18:09:36 +0000

You may know a person's name, but searching it on Google often returns hundreds of unrelated results. Sometimes you know a little more about them—their profession, company, city, or another detail—but combining that information into an effective search can still be time-consuming.

That's why I built the People Search Tool.

It helps you create targeted Google searches using just two pieces of information, making it easier to find publicly available information about a person.

What Is the People Search Tool?

The People Search Tool is a free web application that helps you search for people online more efficiently.

All you need to enter is:

Person's Name
A Clue or Additional Information

The clue can be anything you already know, such as:

Job title
Company name
City or country
College or university
Username
Industry
Hobby
Any other identifying detail

The tool then generates multiple search queries that you can open in Google with a single click.

Example

Suppose you're looking for someone named:

Name

Abhinav Singwal

Clue

Penetration Tester

Use People Search: https://yogsec.github.io/People-Search/

The tool creates multiple search queries that help you locate publicly available profiles, articles, websites, and other online information related to that person.

Instead of manually trying different combinations, the tool does the work for you.

Why I Built This Tool

Many people spend several minutes changing search terms, adding new keywords, and trying different websites before finding the right person.

I wanted to simplify that process.

With just two input fields, the People Search Tool generates multiple search queries in seconds, helping you reach relevant results faster.

Who Can Use It?

The People Search Tool is useful for anyone who needs to find publicly available information online, including:

Recruiters searching for candidates
Journalists verifying public information
Students researching authors or speakers
Security researchers performing OSINT
Bug bounty hunters
Event organizers looking for speaker profiles
Anyone trying to locate a person's public online presence

LinkedIn - https://www.linkedin.com/in/abhinavsingwal/

Vulnerable Login: Learn 12 Common Authentication Vulnerabilities

Abhinav Singwal — Sat, 25 Jul 2026 03:12:13 +0000

Authentication is one of the most important parts of any web application. A single mistake in a login system can expose user accounts, leak sensitive information, or even allow attackers to gain complete access to an application.

Unfortunately, many developers learn secure authentication only after discovering security issues in production.

To help developers and security students understand these risks, I created Vulnerable Login, a deliberately insecure login application that contains 12 common authentication vulnerabilities found in real-world web applications.

This project is built for education only. It allows developers and penetration testers to safely explore insecure authentication mechanisms and understand how to fix them.

Why I Built Vulnerable Login

Many tutorials explain authentication using only secure examples. While that is important, it doesn't show developers what insecure authentication actually looks like.

Understanding vulnerable code helps developers:

Identify authentication weaknesses before attackers do
Learn common security mistakes
Practice web application penetration testing
Improve secure coding skills
Understand how authentication attacks work

The goal of this project is to make learning authentication security practical instead of theoretical.

Live Demo

You can test the vulnerable application here:

Live Demo: https://yogsec.github.io/Vulnerable-Login

GitHub Repository:

https://github.com/yogsec/Vulnerable-Login

Important: Never use this code in production. Every vulnerability is intentionally included for educational purposes.

Authentication Vulnerabilities Included

The project contains twelve intentionally vulnerable authentication mechanisms.

1. SQL Injection Authentication Bypass

User input is directly inserted into SQL queries.

Developers will learn:

Why parameterized queries are important
How SQL Injection bypasses authentication
How prepared statements prevent attacks

2. Plaintext Password Storage

Passwords are stored in plain text instead of being securely hashed.

This demonstrates why passwords should never be stored without strong hashing algorithms such as bcrypt or Argon2.

3. No Rate Limiting

The login page allows unlimited login attempts.

Students can understand how brute-force attacks become possible when no request limits exist.

4. No Account Lockout

Even after repeated failed login attempts, accounts remain accessible.

This demonstrates why account lockout policies are an important security control.

5. Weak Passwords

The application contains users with predictable passwords.

Examples include passwords that attackers commonly try first during password guessing attacks.

6. Weak MD5 Password Hashing

Passwords are hashed using MD5 without salt.

Developers can understand why MD5 is no longer considered secure for password storage.

7. Verbose Error Messages

Different error messages reveal whether a username exists.

This small mistake provides valuable information to attackers.

8. User Enumeration

The application allows attackers to determine valid usernames.

Developers can learn how consistent responses reduce information disclosure.

9. Session Fixation

The session identifier is not regenerated after successful login.

Students can observe how attackers may hijack authenticated sessions.

10. Hardcoded Credentials

Administrative credentials are embedded directly inside the source code.

This demonstrates why secrets should never be committed into repositories.

11. No HTTPS Protection

Credentials are transmitted over HTTP instead of HTTPS.

Developers can understand why encrypted communication is essential for protecting usernames and passwords.

12. CSRF Protection That Doesn't Work

The application includes an anti-CSRF token but never validates it.

This demonstrates how incomplete security implementations create a false sense of protection.

Who Should Use This Project?

This repository is useful for:

Frontend Developers
Backend Developers
Full Stack Developers
Security Researchers
Bug Bounty Hunters
Penetration Testers
Students Learning Cybersecurity
Web Security Trainers
University Instructors

What Developers Will Learn

After exploring this project, you'll better understand:

Authentication security
Login security best practices
Password storage
Session management
Secure authentication design
Brute-force protection
SQL Injection prevention
CSRF mitigation
User enumeration prevention
Secure coding practices

These concepts are directly applicable when building secure web applications.

API Pentesting Tools: A Complete Open-Source Collection for Learning and Bug Hunting

Abhinav Singwal — Fri, 24 Jul 2026 17:38:02 +0000

If you're learning API security or participating in bug bounty programs, you've probably faced this problem:

"Which tool should I use for API reconnaissance? What about authorization testing? Is there a good tool for GraphQL? Which fuzzing tool is best?"

Instead of searching through dozens of blog posts and GitHub repositories, I decided to create one place where everything is organized.

That's why I built API Pentesting Tools, an open-source repository that collects useful tools for every stage of API security testing.

GitHub:
https://github.com/yogsec/API-Pentesting-Tools

Why I Created This Repository

When I started learning API penetration testing, I spent more time searching for tools than actually testing APIs.

Every article listed different tools. Some were outdated, while others only covered one part of API testing.

I wanted a repository where students, beginners, and bug bounty hunters could quickly find the right tool without wasting time.

Today, this repository is helping people discover API security tools from one central place and is ranking #2 on Google for the search term "API Pentesting Tools."

What You'll Find

The repository is divided into different API testing categories.

API Reconnaissance

Before testing an API, you need to understand its attack surface.

This section includes tools for:

API endpoint discovery
Subdomain enumeration
Swagger analysis
GraphQL schema discovery
Hidden endpoint discovery ...

Who Should Use This Repository?

This project is useful for:

Students learning API Security
Bug Bounty Hunters
Penetration Testers
Security Researchers
API Developers
Anyone interested in Application Security

Whether you're preparing for interviews, solving API labs, or hunting vulnerabilities on bug bounty platforms, this repository can save you time.

Why Bookmark This Repository?

Instead of remembering hundreds of tool names, you can use this repository as a quick reference.

It is regularly updated with useful tools so you can easily discover new resources for API penetration testing.

Repository:
https://github.com/yogsec/API-Pentesting-Tools

LinkTree: https://linktr.ee/abhinavsingwal

CVE-2026-56844: Veeam Security Update You Should Know About

Abhinav Singwal — Thu, 23 Jul 2026 03:19:01 +0000

CVE-2026-56844 is a privilege escalation vulnerability found in the Veeam Updater component of the Veeam Software Appliance. The flaw enables a local user with existing high privileges to elevate further and gain root-level access to the underlying operating system.

Root Cause

The vulnerability is classified as CWE-22: Path Traversal. This indicates that the root cause lies in insufficient input validation when processing pathnames. The updater component fails to properly restrict directory traversal sequences, allowing an attacker to manipulate file paths and access restricted locations on the filesystem.

The technical implementation of this flaw involves improper privilege management within the updater service, where insufficient validation occurs during the update process. This represents a classic case of privilege escalation through insecure component design—legitimate functionality becomes a vector for unauthorized privilege elevation.

CVSS

The key nuance is the PR:H (Privileges Required: High) metric—an attacker already needs elevated access. This vulnerability enables further escalation from high privileges to full root control.

Affected Products and Versions

The vulnerability affects:

Veeam Software Appliance (Linux-based Veeam Backup & Replication server)
Veeam Infrastructure Appliance Not affected:
Windows-based Veeam Backup & Replication servers (though remote Linux components they manage may still be vulnerable)
Veeam Backup & Replication version 13.0.2 is listed as unaffected

Exploitation

An attacker can exploit this weakness by:

Crafting malicious update packages
Manipulating existing update mechanisms
Leveraging the updater's legitimate administrative capabilities for unauthorized system access Once root access is obtained, an attacker can:
Modify system files
Install persistent backdoors
Access sensitive backup data
Manipulate backup operations
Potentially compromise the entire backup infrastructure ### Mitigation

The patch is included in Veeam Updater version 12.3.0.65. For systems that cannot reach Veeam's update repository, manual installation is required.

LinkTree: https://linktr.ee/abhinavsingwal

This guide explains why shopping website security matters, how these vulnerabilities affect online stores, and how website owners can identify and fix them before attackers do. Ideal for e-commerce businesses, developers, and security professionals.

Abhinav Singwal — Thu, 23 Jul 2026 03:08:36 +0000

Abhinav Singwal

Jul 23

Is Your Shopping Website Secure? Common Security Issues Every E-commerce Business Should Check

#webdev #cybersecurity #business #ecommerce

3 min read

Is Your Shopping Website Secure? Common Security Issues Every E-commerce Business Should Check

Abhinav Singwal — Thu, 23 Jul 2026 03:07:38 +0000

Running an online store is about more than selling products. Customers trust your website with their personal information, addresses, payment details, and orders. Even a small security issue can lead to data leaks, financial loss, or damage to your business reputation.

Many website owners believe their online store is secure because it works correctly. However, a website can look perfect while still containing hidden security problems that attackers can abuse.

To help people understand these risks, I created Vulnerable Shopping Cart, a deliberately insecure e-commerce application built for cybersecurity learning and security testing.

GitHub Repository: https://github.com/yogsec/Vulnerable-shopping-Cart

Vulnerable Cart Demo: https://yogsec.github.io/Vulnerable-shopping-Cart/

This project demonstrates common vulnerabilities that are often found in shopping websites. It is designed for educational purposes so developers, students, and business owners can understand what these issues look like and why they should be fixed.

Common Security Issues in Shopping Websites

Cross-Site Scripting (XSS)

An attacker may inject malicious code into your website. This can allow them to steal user sessions, display fake content, or perform actions on behalf of customers.

Insecure Direct Object Reference (IDOR)

If access control is not properly implemented, one customer may be able to access another customer's shopping cart, profile, or order information.

Price Manipulation

Some websites rely on values stored in the browser. An attacker may change the product quantity or price before completing a purchase.

Gift Card and Coupon Abuse

If gift cards or coupons are validated only on the client side, users may reuse discounts or increase gift card balances without authorization.

Session Fixation

If session identifiers are predictable or accepted from URLs, attackers may hijack customer accounts.

Open Redirect

Improper redirect validation can send users to malicious websites that imitate your business.

Missing CSRF Protection

Without proper request validation, attackers may force logged-in users to perform actions without their knowledge.

Missing Security Headers

Headers such as Content Security Policy (CSP) and X-Frame-Options help protect websites from several browser-based attacks. Missing them increases risk.

Sensitive Data Exposure

Customer information, payment details, or internal application data should never be exposed to users or stored insecurely.

Business Logic Flaws

Not every vulnerability is technical. Sometimes attackers abuse the normal workflow of a website, such as applying discounts multiple times, bypassing shipping rules, or earning unlimited loyalty points.

Why This Matters

A successful attack can result in:

Customer data leaks
Financial losses
Fraudulent orders
Account takeover
Loss of customer trust
Damage to your brand
Legal and compliance issues

Finding these issues early is much cheaper than dealing with the consequences of a security breach.

Learn in a Safe Environment

The Vulnerable Shopping Cart includes intentionally vulnerable examples so security professionals and developers can safely learn how these problems occur and how they should be fixed. It is meant for education only and should never be deployed in a production environment.

Explore the project:

GitHub: https://github.com/yogsec/Vulnerable-shopping-Cart

Live Demo: https://yogsec.github.io/Vulnerable-shopping-Cart/

Need Your Website Tested?

I help businesses identify security vulnerabilities in their websites and provide a clear report with findings and recommendations. My website security assessment starts at $20, making it affordable for startups, small businesses, and e-commerce website owners who want to improve their security before attackers find the issues.

If you would like your website tested, feel free to contact me.

Email: abhinavsingwal@gmail.com

Linktree: https://linktr.ee/abhinavsingwal

When a Phone Number Field Accepts Negative Numbers: A Look at Input Validation Failures

Abhinav Singwal — Sat, 13 Jun 2026 10:03:33 +0000

During a recent web application assessment, I came across an interesting issue that demonstrates why input validation remains one of the most important aspects of application security.

The Observation

A phone number field was expected to accept valid telephone numbers. However, while testing the application, I discovered that the field accepted negative numeric values such as:

-27
-90
-137

These values were processed and accepted by the application without any apparent restrictions.

At first glance, this may appear to be a minor issue. After all, accepting an invalid phone number does not immediately result in account takeover or remote code execution. However, findings like this often reveal deeper problems in the application's validation logic.

Why Does This Matter?

Applications rely on user-supplied data for business operations, reporting, notifications, integrations, and analytics. When invalid data is allowed into a system, it can create unexpected behavior throughout the application.

Some potential impacts include:

1. Data Integrity Issues

Phone number fields are designed to store contact information. Allowing invalid values can pollute databases and reduce the reliability of stored data.

2. Business Logic Problems

Many workflows depend on valid phone numbers, including:

SMS verification
Customer communication
OTP delivery
Account recovery processes

Improper validation can interfere with these workflows and lead to unexpected application behavior.

3. Input Validation Gaps

When one field lacks proper validation, it often indicates that similar weaknesses may exist elsewhere in the application.

Security testers frequently use small validation failures as indicators that broader validation issues may be present.

4. Downstream Processing Risks

Applications often share data with external systems such as:

CRM platforms
Marketing tools
Reporting systems
Third-party APIs

Unexpected values can cause failures, exceptions, or inaccurate reporting within these connected systems.

Client-Side Validation Is Not Enough

Many applications rely heavily on frontend validation using JavaScript. While this improves user experience, it should never be considered a security control.

Attackers can easily bypass client-side restrictions using:

Browser developer tools
Proxy tools
Modified requests
Automated scripts

All validation rules must be enforced on the server side before data is accepted and stored.

Recommended Mitigations

To prevent issues like this:

Validate all inputs on the server side.
Enforce strict phone number formats.
Reject unexpected characters and negative values.
Implement length restrictions.
Use allowlists instead of blocklists whenever possible.
Perform consistent validation across all application interfaces and APIs.

Business Logic Vulnerability: When Multiple Accounts Can Share the Same Payout Details

Abhinav Singwal — Mon, 08 Jun 2026 07:02:38 +0000

Business logic vulnerabilities are often overlooked because they do not always involve classic security issues such as SQL Injection, Cross-Site Scripting, or Remote Code Execution. Instead, they arise when an application's workflow allows actions that conflict with the intended business rules.

One interesting scenario involves payout settings.

The Scenario

Imagine a platform that allows users to receive payments through bank accounts, gift cards, cryptocurrency wallets, or other payout methods.

A user can navigate to their profile and configure payout information that will be used to receive future rewards or payments.

Now consider the following workflow:

User A registers an account.
User A adds a bank account and payout email.
The platform saves the information successfully.
User B registers a completely different account.
User B enters the exact same payout information.
The platform accepts the details without any validation or review.

As a result, multiple accounts become associated with the same payout destination.

Why Is This Interesting?

At first glance, this may appear harmless. However, from a business logic perspective, payout information is often treated as an identifier that links financial transactions to a specific user.

Allowing the same payout destination to be associated with multiple accounts can create challenges for fraud detection, abuse prevention, and account attribution.

The issue is not necessarily the duplicate data itself. The real concern is how that data may be used by other business processes within the application.

Potential Risks

Multi-Account Abuse

Many platforms attempt to limit abuse by restricting rewards, promotions, referrals, or bonuses to one user.

If the same payout destination can be reused indefinitely, a single individual may create multiple accounts while still directing all payments to a single destination.

Referral Program Abuse

Referral systems frequently assume that each participant represents a unique individual.

When payout destinations are not validated, an attacker may create multiple accounts and funnel rewards to the same financial endpoint.

Fraud Investigation Challenges

Security and fraud teams often rely on payout information to identify relationships between accounts.

If duplicate payout information is allowed without monitoring or review, suspicious activity may become harder to investigate.

Ban Evasion

Platforms sometimes ban accounts involved in abuse or policy violations.

If payout information is not used as part of anti-abuse controls, a banned user may create additional accounts while continuing to use the same payout destination.

How Security Researchers Can Test This

When assessing payout systems, researchers can examine the following:

Can multiple accounts register the same bank account?
Can multiple accounts use the same payout email address?
Are duplicate cryptocurrency wallet addresses accepted?
Is there any verification process for payout ownership?
Does the application generate warnings when duplicates are detected?
Are duplicate payout destinations reviewed by fraud systems?

The objective is not merely to identify duplicate data acceptance but to understand how the platform's business processes interact with that data.

Example Test Flow

Create Account A.
Add a payout destination.
Create Account B.
Add the same payout destination.
Observe whether the platform:

Rejects the entry.
Generates a warning.
Requires additional verification.
Accepts the data silently.

Documenting these behaviors can help identify weaknesses in fraud prevention and account attribution mechanisms.

Security Recommendations

Organizations can reduce risk by implementing several controls:

Server-Side Uniqueness Checks

Validate whether a payout destination already exists before saving it to another account.

How I Find Excessive Data Exposure in APIs

Abhinav Singwal — Sat, 06 Jun 2026 09:22:57 +0000

I was testing a fintech app's "View Profile" feature. The mobile app showed my name and avatar. Burp Suite showed something else entirely:

{
  "name": "John Doe",
  "avatar": "/images/avatar.jpg",
  "email": "john@example.com",
  "phone": "+1234567890",
  "password_hash": "5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8",
  "reset_token": "a7b3f9e2c4d1g6h8j9k0l",
  "internal_risk_score": 42,
  "admin_notes": "Flagged for unusual activity",
  "last_login_ip": "192.168.1.100"
}

The app only showed name and avatar. The API returned everything about me - including my password hash and an active reset token.

That was my first Excessive Data Exposure bounty. $1,500 for reading my own data.

Let me show you how to find these everywhere.

What Even Is Excessive Data Exposure?

Simple definition: The API gives you more data than you need to see.

Technical definition: The backend queries SELECT * FROM users and sends the entire database row to the frontend, even though the UI only displays 2 of the 15 columns.

The scary part? You don't need broken authentication. You don't need SQL injection. You just need to look at the raw API response.

The 9 Endpoints Where I Always Find This

1. User Profile Endpoints

GET /api/users/{id} or GET /api/users/me

What to look for:

email, phone, address
password_hash, salt
reset_token, verify_token
two_fa_secret, backup_codes
api_keys, session_tokens

Bug bounty example: I once found stripe_customer_id and subscription_billing_cycle on a /me endpoint. The company paid $500 because they considered it internal architecture exposure.

2. Search Endpoints

GET /api/search?q=john

What to look for:

Full emails instead of truncated j***@example.com
Exact timestamps of last login
Internal user IDs used for other API calls

Pro tip: Even if you can't IDOR to other users, search your own email. The API might return extra fields on your own result that shouldn't be visible to you.

3. Registration / Signup Responses

POST /api/register

What to look for:

Your password echoed back in plaintext (yes, this happens)
Your session token in the response body
Internal account flags like "is_verified": false, "requires_review": true

4. Order History

GET /api/orders/12345

What to look for:

Credit card last4, expiry, billing zip
Full shipping address
Internal cost vs retail price (business logic exposure)
refund_eligibility flags

5. File Upload Metadata

POST /api/upload → returns file_id → GET /api/files/{file_id}

What to look for:

Internal S3 bucket paths (exposes infrastructure)
Original filenames (could contain PII like resume_ssn_123.pdf)
Uploader's IP address and user agent
file_permissions array showing who can access

6. GraphQL Endpoints (The Jackpot)

POST /graphql

What to do: Request fields you shouldn't see even on your own account:

query {
  me {
    name
    email
    password_hash   # ← try it
    reset_token     # ← try it
    internal_notes  # ← try it
    admin_flags     # ← try it
  }
}

Real bounty: A bug hunter found credit_card and ssn fields exposed on the /me query of a major credit bureau. $7,500 bounty.

7. Analytics & Dashboard Endpoints

GET /api/dashboard/stats

What to look for:

Other users' emails or IPs in event logs
Database connection strings
Debug arrays containing full request/response objects

8. Export / Download Endpoints

GET /api/export/users.csv

What to look for: If you can access this endpoint at all (auth bypass or misconfigured role), the CSV often contains:

Full database columns including sensitive ones
Password reset hashes
2FA secrets (mangled or plain)

9. PATCH / PUT Responses

PATCH /api/users/me (with empty body {})

Why this works: When you send an update with no changes, some APIs still return the full updated object - which might contain fields you never had permission to read.

My 4-Step Testing Methodology

Step 1: Intercept Everything

Stop trusting what you see in the browser/mobile app. Forward every request through Burp Suite, Caido, or ZAP.

The raw response always tells the truth.

Step 2: Build Your Keyword Radar

I search responses for these strings (I keep this as a grep pattern):

email|e-?mail|phone|mobile|telephone|address|location|
ssn|tax|tin|passport|license|driver|
birthday|dob|age|
password|pass|pwd|secret|token|jwt|api[_-]?key|apikey|
hash|salt|reset[_-]?token|verify[_-]?token|
credit[_-]?card|cc|cvv|expiry|stripe|paypal|
ip[_-]?address|user[_-]?agent|device[_-]?id|
internal[_-]?note|admin[_-]?note|flag|reason[_-]?code|
otp|mfa|two[_-]?fa|backup[_-]?code

Step 3: Compare Responses Across IDs

If you can change ?user_id=1 to ?user_id=2, do it. But even without IDOR, compare:

Authenticated vs unauthenticated
Your low-privilege account vs a different low-privilege account
Verbose param (?verbose=true) vs normal

Tool tip: Use Burp's Comparer or the Diffy extension to spot extra JSON keys.

Step 4: Trigger Verbose Modes

Add these parameters to every request:

?verbose=true
?debug=1
?include_fields=all
?format=full
?fields=*
?pretty=true
?show_internal=true

Broken User Authentication in APIs

Abhinav Singwal — Sat, 06 Jun 2026 06:58:36 +0000

Broken User Authentication ranks as the second most critical vulnerability in the OWASP API Security Top 10 for 2023. In bug bounty programs, authentication flaws often lead to account takeover, data breaches, and high-severity payouts.

Unlike traditional web applications, APIs use stateless tokens, OAuth flows, and machine-to-machine communication patterns. This creates unique attack surfaces that many testers overlook. This guide covers the ten most critical API authentication vulnerabilities with practical testing techniques.

What Makes API Authentication Different

Standard web apps rely on session cookies and server-side state. APIs use tokens that carry all authentication information within the request itself. Every request must prove its identity independently.

This stateless design introduces specific vulnerabilities. JWT tokens can be manipulated. Refresh tokens can be replayed. OAuth flows have multiple redirects where things go wrong. Understanding these differences is the first step to finding bugs.

The Ten Critical Vulnerabilities

1. JWT Algorithm Confusion

JSON Web Tokens include an alg header that tells the server which signing algorithm was used. When servers trust this header without strict validation, attackers can bypass signature verification.

The none algorithm attack works because some libraries accept unsigned tokens. Setting alg: "none" removes the signature requirement entirely. The server processes the token as valid.

The RS256 to HS256 confusion attack is more subtle. RS256 uses RSA private keys for signing and public keys for verification. HS256 uses a shared secret. If a server expects RS256 but receives HS256, it may verify the signature using the public key as an HMAC secret. Attackers who know the public key can forge valid tokens.

Testing requires intercepting a valid JWT, modifying the alg header, and sending the modified token to protected endpoints.

2. JWT Key ID Injection

The kid header specifies which key should verify the token. Servers often fetch this key from files, databases, or external URLs. When kid is not sanitized, injection attacks become possible.

Path traversal via kid: "../../../dev/null" can read local files. If the server uses file contents as verification keys, attackers control the key.

SQL injection in kid works when servers query a database for the key. A payload like ' UNION SELECT 'public_key can return attacker-controlled values.

SSRF attacks use kid: "http://internal-service/secret" to force the server into fetching from attacker-specified locations.

Testing requires modifying the kid value to various injection payloads and observing server behavior.

3. Weak JWT Secrets

Many developers generate JWT secrets manually. Common choices include "secret", "changeme", "password", or simple strings. These are vulnerable to brute-force attacks.

Hashcat with mode 16500 cracks JWT secrets. RockYou wordlist contains thousands of common secrets. Tools like jwt_tool and crackjwt automate this process.

A secret with low entropy can be cracked in minutes on modern hardware. Even longer secrets that follow dictionary patterns are vulnerable.

Testing involves capturing a valid JWT and attempting to crack its secret offline. No rate limits apply because the attack happens on your own machine.

4. Missing Token Expiration

JWTs can include an exp claim that defines expiration time. Without this claim, tokens remain valid forever. Some implementations set expiration to years in the future or never check it at all.

An attacker who captures a token once can reuse it indefinitely. This is especially dangerous for tokens leaked in logs, browser history, or network traffic.

Testing requires capturing a token, waiting for its supposed expiration, and attempting to reuse it. Also check if the exp claim exists and whether the server rejects expired tokens.

5. Refresh Token Reuse Without Rotation

Refresh tokens allow clients to obtain new access tokens without re-authenticating. The secure pattern is one-time use with rotation. Each refresh request returns a new refresh token and invalidates the old one.

Without rotation, stolen refresh tokens remain valid forever. An attacker can generate unlimited access tokens from a single stolen refresh token.

Testing involves using a refresh token to obtain new tokens, then using the same refresh token again. If the second request succeeds, rotation is missing.

6. Predictable Password Reset Tokens

Password reset flows generate tokens sent via email or SMS. When these tokens follow predictable patterns, attackers can brute-force them.

Common flaws include 4-digit or 6-digit numeric codes with no rate limiting. An attacker can try all 10,000 combinations in minutes.

Time-based tokens using milliseconds or seconds since epoch are also predictable. If an attacker can guess the approximate reset request time, they can narrow the search space.

Tokens returned in API responses during the reset request represent the most critical flaw. The attacker can simply read the token from the response body.

Testing requires requesting multiple resets and analyzing token patterns. Check for sequential increases, timestamp encoding, or short numeric values.

7. No Rate Limiting on Authentication Endpoints

Login, OTP verification, password reset, and token issuance endpoints require rate limiting. Without it, brute-force attacks become feasible.

Four-digit OTP codes need only 10,000 attempts. With no rate limits, this takes minutes. Credential stuffing using breached password lists becomes trivial.

Rate limiting should apply per user, per IP address, and globally. It should also increase delays after repeated failures.

Testing involves sending 100 or more rapid requests to authentication endpoints. Use Burp Intruder or a simple Python script. If all requests succeed, rate limiting is missing.

8. Verbose Error Messages Enabling Account Enumeration

Authentication endpoints should return identical responses for all failure cases. When they differentiate, attackers can enumerate valid users.

Different messages like "Password incorrect" versus "User not found" reveal whether an account exists. Registration endpoints that say "Email already registered" provide the same information.

Response timing differences can also leak information. Checking an existing user might take longer because the server fetches the user record first.

Testing requires comparing responses for known valid and known invalid inputs. Look for differences in status codes, response bodies, or response times.

9. OAuth 2.0 Misconfiguration

OAuth flows involve multiple redirects where tokens pass through the browser. Each redirect is an attack opportunity.

The redirect_uri parameter tells the OAuth provider where to send the authorization code. When validation is missing, attackers can set their own domain and steal codes.

Open redirects in redirect_uri allow attackers to leak codes via the Referer header. The code travels from the legitimate site to the attacker's site automatically.

Missing CSRF protection on the state parameter enables attackers to initiate flows and intercept responses. The state parameter should be unpredictable and tied to the user session.

Testing requires attempting to change redirect_uri to external domains, open redirect endpoints, or localhost addresses.

10. Exposed API Keys in URLs and Client Code

API keys in URLs appear in browser history, server logs, and Referer headers. Anyone with access to these logs can steal the key.

Mobile applications and single-page apps often hardcode API keys in JavaScript or configuration files. These are trivially extractable.

Debug endpoints, source maps, and public repositories are common leakage sources. Developers sometimes commit keys to GitHub despite best efforts.

Testing involves checking network traffic, browser developer tools, JavaScript files, and public code repositories for exposed keys.

#XSS #CrossSiteScripting #XSSLABS #PortSwiggerLabsXSS

Abhinav Singwal — Sat, 06 Jun 2026 05:35:41 +0000

Abhinav Singwal

May 26

Master XSS the Practical Way: Introducing xss-labs

#tryhackme #xss #xssrat #hackthebox

3 min read

API Hacking: What is BOLA/IDOR?

Abhinav Singwal — Sat, 06 Jun 2026 05:34:25 +0000

Today I want to talk about one of the most common API vulnerabilities.

It's called BOLA (Broken Object Level Authorization).

You might also know it as IDOR (Insecure Direct Object Reference).

Don't let the fancy names scare you. It's actually very simple.

Let me explain.

The Problem

Imagine you live in an apartment building.

Each apartment has a number: 101, 102, 103...

Now imagine the building has no locks. Anyone can walk into any apartment.

That's BOLA.

The API says "here is apartment number 103" but never checks if you live there.

A Real API Example

Let's say you log into a shopping website.

You want to see your order number 1001.

The app sends this request:

GET /api/orders/1001

And you see your order. Great.

Now what happens if you change the number?

GET /api/orders/1002

If you see someone else's order, that is BOLA.

The API trusted you just because you asked. It never checked if the order belongs to you.

Why Does This Happen?

Developers forget to add a simple check.

They should ask: "Does user 123 own order 1002?"

But sometimes they only ask: "Is user 123 logged in?"

Being logged in is not enough. You also need permission to see that specific thing.

How Hackers Find BOLA

It is very simple. You just change numbers or IDs in the request.

Look for these places:

GET /api/user/123 -> try 124, 125, 126
POST /api/invoice with {"invoice_id": 456} in body -> try 457
DELETE /api/post/789 -> try 788, 787
/api/download?file=report_1.pdf -> try report_2.pdf

Also try UUIDs like this:

/api/user/550e8400-e29b-41d4-a716-446655440000

Change one letter or number. Sometimes it still works.

Quick Test Method (2 Accounts)

This is how I test for BOLA:

Step 1: Create two accounts (Account A and Account B)
Step 2: Login as Account A, find an order ID or user ID
Step 3: Copy the request
Step 4: Login as Account B
Step 5: Paste the request and change the ID to Account A's ID

If you see Account A's data while logged in as Account B, you found BOLA.

How to Protect Your API (For Developers)

If you build APIs, remember this rule:

Never trust the user. Always check permission.

Every time someone asks for an object, ask two questions:

Is the user logged in?
Does this user own the object?

For extra safety, don't use simple numbers like 123. Use random UUIDs. But even then, still check permissions.

Found this helpful? Leave a like and follow for more API hacking posts.

Questions? Drop a comment below.