DEV Community: Abhinav Singwal

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.

Cross Site Scripting Labs #XSS

Abhinav Singwal — Fri, 05 Jun 2026 06:51:04 +0000

Abhinav Singwal

May 26

Master XSS the Practical Way: Introducing xss-labs

#tryhackme #xss #xssrat #hackthebox

3 min read

CVE-2021-3163: Stored XSS Concerns in Quill Rich Text Editor

Abhinav Singwal — Fri, 05 Jun 2026 06:47:54 +0000

Text editors are commonly used in web applications for comments, blog posts, support tickets, documentation systems, and messaging platforms. Because they process user-controlled content, security issues affecting these editors can have significant consequences.

One publicly discussed issue involving Quill is CVE-2021-3163, which was assigned to a potential Stored Cross-Site Scripting (XSS) vulnerability in Quill versions prior to 1.3.7.

What Is the Issue?

The vulnerability report describes a situation where specially crafted HTML content could result in JavaScript execution when rendered by applications using Quill.

The issue specifically involved handling of user-supplied HTML content within the editor. Since the content is stored and later viewed by other users, the impact falls into the category of Stored XSS.

It is worth noting that the vulnerability has been publicly disputed, with discussions around whether the behavior originates from browser parsing behavior or from Quill itself. Regardless of the debate, applications processing untrusted HTML should treat such reports seriously.

Why Stored XSS Is Dangerous

Stored XSS is generally considered more severe than reflected XSS because the malicious content is saved by the application and automatically delivered to future visitors.

Potential impacts include:

Session hijacking
Account takeover
Unauthorized actions on behalf of users
Phishing attacks
Defacement of application content
Theft of sensitive information accessible through the browser

Typical Vulnerable Pattern

Applications often take editor output and directly insert it into the DOM:

const content = databaseContent;

document.getElementById("article").innerHTML = content;

If the content contains unsafe HTML, the browser may interpret and execute it.

Secure Approach

Before rendering user-generated HTML, sanitize it.

Example using DOMPurify:

<script src="dompurify.min.js"></script>

<script>
const cleanHTML = DOMPurify.sanitize(databaseContent);

document.getElementById("article").innerHTML = cleanHTML;
</script>

This removes dangerous elements and attributes before the content reaches the browser.

Example Quill Integration

const quill = new Quill('#editor', {
    theme: 'snow'
});

const html = quill.root.innerHTML;

If this HTML is later displayed elsewhere in the application, it should be sanitized before rendering.

Affected Versions

Reportedly affected:

Quill < 1.3.7

Mitigation

Upgrade to the latest supported version of Quill.
Sanitize all user-generated HTML.
Apply Content Security Policy (CSP).
Validate content on both client and server sides.
Regularly review third-party dependencies.
Avoid trusting rich-text editor output by default.

Security Takeaway

Rich text editors provide convenience, but they also introduce risk because they handle complex HTML content generated by users. CVE-2021-3163 serves as a reminder that any feature allowing HTML input should be carefully reviewed, sanitized, and monitored.

Even when a vulnerability is disputed, security teams should evaluate the behavior, understand the potential impact on their environment, and implement appropriate defensive controls.

Author: Abhinav Singwal

https://linktr.ee/abhinavsingwal

Missing rate limiting on login pages is a critical vulnerability I find constantly during shopping site audits. This post explains how attackers exploit it, how to test for it, and exactly how to fix it. A must-read for any e-commerce developer or security.

Abhinav Singwal — Thu, 04 Jun 2026 00:57:51 +0000

Abhinav Singwal

Jun 4

Why Your Shopping Site's Missing Rate Limit Is a Disaster Waiting to Happen

#webdev #security #ecommerce #business

5 min read

Why Your Shopping Site's Missing Rate Limit Is a Disaster Waiting to Happen

Abhinav Singwal — Thu, 04 Jun 2026 00:56:56 +0000

You have built a beautiful e-commerce platform. Customers love the smooth checkout. Your product images load instantly. But there is a silent killer hiding in your login form.

The lack of rate limiting on authentication attempts.

I run a security audit business focused on shopping websites. The number one vulnerability I find is not SQL injection or cross-site scripting. It is the ability to try passwords unlimited times. No blocks. No delays. No CAPTCHA.

This article explains why this matters, how attackers exploit it, and what you need to fix today.

The Problem in Plain English

Rate limiting means restricting how many requests a user or IP address can make in a specific time window.

Without rate limiting on your login endpoint, an attacker can send one thousand password guesses per second. Your server will happily process each one. After a few minutes, the attacker has tried one hundred thousand passwords. After an hour, millions.

Your customer`s account falls to a dictionary attack. Their stored credit card gets drained. Their saved addresses get changed to a drop location. And you get the chargeback nightmare.

How Attackers Exploit This

There are three common attack patterns against shopping sites with no login rate limiting.

Credential stuffing is the most dangerous. Attackers take username and password pairs leaked from other data breaches. They feed these into your login endpoint automatically. Many people reuse passwords across sites. The attacker now owns those accounts on your platform.

Brute force attacks are simpler but still effective. Attackers try common passwords like password123 or winter2024 against many usernames. Without rate limiting, they will eventually succeed on accounts with weak credentials.

Username enumeration is a privacy leak. When the login response differs slightly for valid versus invalid usernames, attackers can discover which email addresses have accounts on your site. This information sells to spammers and phishers.

Real Example From a Recent Audit

I tested a mid-sized fashion retailer last month. Their API login endpoint had zero restrictions. I wrote a simple twenty-line Python script. It tried one thousand passwords per minute from a single IP address.

Within eight minutes, I cracked three customer accounts. Two used their first name as the password. One used welcome123. All three had saved payment methods.

I reported this as critical severity. The fix was trivial to implement. But the client had been vulnerable for over two years.

Why Shopping Sites Are Prime Targets

Shopping sites hold three things attackers want.

Payment card data. Even tokenized cards can be used for fraudulent purchases if the account is compromised.

Shipping addresses. Attackers use these to build identity profiles or send unsolicited packages.

Order history. This reveals spending habits, income indicators, and product preferences used for targeted scams.

A compromised shopping account is a complete identity and payment package. No wonder attackers target these sites relentlessly.

How to Test Your Own Site

Run this simple manual test right now.

Open an incognito window and go to your login page. Enter a valid customer email address. Type a wrong password. Submit the form. Repeat this twenty times as fast as you can click.

Does your site ever stop you? Do you see a CAPTCHA? Does the login button become disabled temporarily? Does the page tell you to wait?

If nothing changes after twenty failed attempts, you are vulnerable.

For a more thorough test, use Burp Suite Intruder or write a short curl loop.

curl -X POST https://yoursite.com/login \
-d "email=customer@example.com&password=wrongguess"

Run that one hundred times. If you still get the same invalid credentials response without any lockout, you have confirmed the vulnerability.

The Technical Fixes That Work

Implementing rate limiting is not difficult. Here are the specific controls that protect your customers.

Per-IP rate limiting blocks an IP address after a certain number of failed attempts. Start with ten attempts per minute. After that, return HTTP 429 Too Many Requests. Do not even process the authentication attempt.

Per-account rate limiting protects a specific customer account from being targeted by many different IP addresses. Allow five failed attempts per hour on a single account. After the fifth failure, lock the account for fifteen minutes or require email verification to unlock.

Progressive delays increase the response time after each failure. After three failures, add a one-second delay. After five failures, add a five-second delay. This does not block the user but makes automated guessing impossibly slow.

CAPTCHA after N failures stops bots while letting legitimate users through. Use reCAPTCHA v3 which runs invisibly in the background. Most real users never see it, but automated scripts get blocked.

Web Application Firewall rules can provide a stopgap if you cannot modify application code. Configure your WAF to block IPs that exceed a threshold of login requests per minute.

Common Bypasses and How to Prevent Them

Attackers will try to circumvent your rate limiting. You must protect against these bypass methods as well.

IP rotation uses a botnet of thousands of residential proxies. Each IP makes only a few attempts. Per-IP limits alone fail against this. You need per-account rate limiting to stop distributed attacks.

Parameter pollution appends debug=true or similar parameters to the request. Some applications apply rate limits only to the clean URL but not the parameterized version. Normalize all request parameters before applying rate limits.

Different endpoints sometimes have separate rate limits. Attackers may target the API login endpoint while you protected only the web login. Apply consistent rate limiting across all authentication endpoints including login, password reset, and API authentication.

Header spoofing sends X-Forwarded-For headers to fake IP addresses. If your rate limiting trusts this header without validation, attackers can bypass it. Extract the real client IP from the lowest trusted layer, typically the connection source address.

Writing This Up in Your Security Report

When you find missing rate limiting on a client site, here is how to document it professionally.

Title: Missing Rate Limiting on Login Endpoint

Severity: High

Endpoint: POST /api/v1/login

Description: The application accepts an unlimited number of failed authentication attempts to the same user account from the same IP address. No CAPTCHA, delay, or account lockout mechanism is present.

Proof of Concept: One hundred consecutive login requests with incorrect passwords were sent over thirty seconds. Each request returned HTTP 200 with a generic Invalid credentials message. The account remained accessible for correct password entry throughout the test.

Impact: An attacker can perform automated brute force or credential stuffing attacks leading to account takeover. Compromised accounts can be used for fraudulent purchases, gift card draining, and personal data theft.

Remediation: Implement per-IP rate limiting of ten attempts per minute returning HTTP 429 after the limit. Implement per-account rate limiting of five failed attempts per hour with a fifteen minute temporary lockout. Add CAPTCHA after three consecutive failures.

References: OWASP ASVS V2.1.2, CWE-307

The Business Case for Fixing This

Your development team might say this is low priority. Here is what to tell them.

One account takeover leads to an average loss of two hundred fifty dollars in fraudulent transactions plus fifty dollars in chargeback fees. If you have one hundred thousand customer accounts and a one percent annual takeover rate, that is two hundred fifty thousand dollars in direct losses.

Payment card networks increase fees for merchants with high fraud rates. Your compliance auditor will flag missing rate limiting during PCI DSS assessment. Insurance providers may deny breach claims if basic controls like rate limiting were missing.

The fix takes a competent developer four hours to implement and test. The cost of not fixing it is orders of magnitude higher.

Weak password policies allowing brute force attacks. #E-Commerce #WebDevelopment #CyberSecurity

Abhinav Singwal — Wed, 03 Jun 2026 11:34:57 +0000

Abhinav Singwal

Jun 3

Weak Password Policies + No Rate Limiting: The Account Takeover Crisis in E-Commerce

#ecommerce #business #webdev #cybersecurity

5 min read

Weak Password Policies + No Rate Limiting: The Account Takeover Crisis in E-Commerce

Abhinav Singwal — Wed, 03 Jun 2026 11:31:47 +0000

The Problem

Most shopping websites allow users to set passwords like password123 or admin. At the same time, they do not limit how many login attempts can be made per minute. This combination creates a critical vulnerability: attackers can try thousands of password guesses per hour until they find the correct one.

Account takeover via brute force is not theoretical. It happens daily across small and medium e-commerce stores. The result is stolen payment information, fraudulent orders, and angry customers who blame the merchant.

If your shopping website allows unlimited login attempts and accepts weak passwords, your customer accounts are essentially unprotected.

How Attackers Exploit This Combination

The exploitation process follows a simple, automated workflow:

The attacker obtains a list of email addresses. These may come from previous data breaches, OSINT, or simple guessing.
The attacker uses a tool like Hydra, Burp Suite Intruder, or a custom Python script to send login requests.
The tool cycles through the top 1000 most common passwords against each email address.
Because there is no rate limiting, all 1000 attempts complete in minutes.
Because the password policy is weak, common passwords like qwerty123 or welcome are actually valid.

Within hours, the attacker compromises dozens or hundreds of accounts.

Real-World Attack Scenarios on Shopping Sites

The following attack vectors are common in e-commerce environments:

Customer Account Brute Force

An attacker targets a list of customer email addresses. Upon successful login, the attacker gains access to saved credit cards, shipping addresses, order history, and stored gift cards. This data can be used for identity theft or direct financial fraud.

Admin Account Brute Force

Many shopping platforms use predictable admin panel URLs like /admin or /administrator. Attackers attempt common credentials such as admin:password, admin:admin, or storename:storename. A compromised admin account allows the attacker to issue mass refunds, download the entire customer database, or deface the website.

Gift Card and Loyalty Point Brute Force

If a shopping website allows unlimited balance checks on gift card numbers or loyalty accounts, attackers can brute force valid numbers. Predictable gift card code patterns worsen this risk.

Coupon Code Brute Force

Attackers can discover active discount codes by brute forcing common patterns such as SAVE10, SAVE20, WELCOME15, or SUMMER2024. This leads to revenue loss and promotion abuse.

Why E-Commerce Platforms Are Particularly Vulnerable

Shopping websites have unique characteristics that make them more susceptible to this vulnerability than banks or social media platforms.

Frictionless Checkout Priority

E-commerce businesses prioritize speed. Adding CAPTCHA or login delays is seen as hurting conversion rates. Security is often deprioritized until a breach occurs.

Reliance on Payment Processors

Many merchants assume the payment gateway handles all fraud prevention. Payment processors monitor transaction fraud, not login attempts. The login system is entirely the merchant's responsibility.

Use of Insecure Templates

Small to medium stores frequently use unmodified open-source platforms or cheap templates. These often ship with default password policies and no rate limiting configured.

Third-Party Account Integration

Shopping websites that allow social login still maintain traditional login endpoints. Attackers target the weaker traditional endpoint.

Step-by-Step Testing Methodology

You should test your own website responsibly. The following methodology assumes you have permission to test.

Step 1: Assess Password Policy

Attempt to register or change a password using these values:

password
123456
qwerty
a
aaaaaaaa
password123
No numbers or symbols only

If any of these are accepted, your policy is weak.

Step 2: Test for Rate Limiting

Send 100 consecutive login requests with incorrect credentials to the same account. Use a simple bash loop or a tool like Burp Suite Intruder.

for i in {1..100}; do
  curl -X POST https://yourstore.com/login \
    -H "Content-Type: application/json" \
    -d '{"email":"victim@example.com","password":"wrongpassword"}'
  sleep 0.1
done

If all 100 requests return the same response (e.g., invalid credentials), there is no rate limiting.

Step 3: Check for Account Lockout

After 10 to 20 failed attempts, the account should lock temporarily. If you can still attempt logins after 50 attempts without any lockout message, lockout is absent.

Step 4: Test IP-Based vs User-Based Rate Limiting

Repeat the 100 attempts from a different IP address. If the second IP can also attempt 100 times without delay, rate limiting is missing entirely.

Sample Proof of Concept

The following Python script demonstrates a minimal brute force test. This is for authorized security testing only.

import requests
import time

target_email = "customer@example.com"
password_list = ["password", "123456", "qwerty", "admin", "welcome", "password123"]

url = "https://target-shop.com/api/login"

for password in password_list:
    response = requests.post(url, json={"email": target_email, "password": password})
    print(f"Trying {password}: {response.status_code}")
    if response.status_code == 200:
        print(f"Success! Password is {password}")
        break
    time.sleep(0.1)  # Minimal delay, often ineffective

On a vulnerable site, this script finds a valid password within seconds.

Business Impact: Beyond the Hype

The impact of brute force account takeover on a shopping website includes the following business consequences.

Financial Loss from Fraudulent Orders

Compromised accounts are used to place orders using saved payment methods. The original customer disputes the charge. The merchant absorbs chargeback fees, product loss, and payment processor penalties.

Customer Churn and Reputation Damage

News of a breach spreads quickly on social media and review platforms. Customers lose trust and move to competitors. Small merchants rarely recover their reputation after a publicized account takeover incident.

Support Overload

After a breach, customer support teams receive hundreds of password reset requests and fraud reports. This strains limited support resources.

Legal and Compliance Exposure

Data breach notification laws may require the merchant to disclose the incident to affected customers and regulators. Failure to disclose leads to fines.

Gift Card and Loyalty Point Theft

If gift card balances are accessible via login, attackers drain stored value. The merchant must reissue funds or face customer lawsuits.

How to Fix It: Actionable Recommendations

Implement the following controls in order of priority.

Priority 1: Enforce a Strong Password Policy

Require a minimum of 8 characters. Require at least three of the four following character types: uppercase letters, lowercase letters, numbers, and symbols. Maintain a blocklist of the top 1000 most common passwords from breaches. Reject passwords that include the user's email prefix or common patterns.

Priority 2: Implement Rate Limiting

Allow a maximum of 5 login attempts per 15 minutes per user account. Allow a maximum of 10 login attempts per 15 minutes per IP address across all accounts. Return a standard HTTP 429 Too Many Requests response when limits are exceeded.

Priority 3: Add Progressive Delays

After 3 failed attempts, introduce a 2-second delay before allowing another attempt. After 7 failed attempts, increase the delay to 10 seconds. Delays make brute force economically unviable.

Priority 4: Implement Account Lockout

Temporarily lock the account for 15 minutes after 10 consecutive failed login attempts. Send an email alert to the account owner when lockout occurs. Require password reset after 20 cumulative failed attempts over 24 hours.

Priority 5: Add CAPTCHA

Present a CAPTCHA after 3 failed login attempts from the same IP or account. Use reCAPTCHA v3 or hCaptcha to minimize friction while blocking automation.

Priority 6: Monitor and Alert

Log all failed login attempts including timestamp, IP address, and user agent. Configure alerts for more than 10 failed attempts on a single account in 5 minutes. Review logs weekly for brute force patterns.