Forem: Srichinmai Sripathi

How We Bypassed OTP Rate Limits via IP Rotation on a Major Streaming Platform

Srichinmai Sripathi — Fri, 22 May 2026 19:59:07 +0000

At our engineering team, we have been building an autonomous browser agent that navigates the web to test checkout and subscription flows. Recently, we pointed our test runner at a major subscription video streaming platform to analyze how it handled user authentication.

What started as a routine crawler testing run ended in the discovery of two significant API vulnerabilities: a High-severity Account Takeover (ATO) via OTP brute forcing and a Medium-severity SMS Flooding/DoS vulnerability.

Here is the step-by-step breakdown of how we intercepted the auth flow, reverse-engineered the rate-limiting rules, and proved that a simple IP rotation completely bypasses the platform's defenses.

1. Intercepting the Auth Flow

Because the service is a subscription streaming platform, user registration is required before arriving at any checkout screen. To understand how they authorize users, we used a Playwright network interception script to capture traffic during a standard login attempt.

We uncovered a 4-step API chain pointing to their authentication service:

Guest Registration: POST /api/v1/user/guest/register returns an anonymous session ID.
OTP Generation: POST /api/v1/user/auth/generateOTP triggers a 4-digit OTP code sent to the mobile number.
OTP Validation: POST /api/v1/user/auth/validateOTP validates the code.
Subscription Status: POST /api/v1/subscription/current pulls the active subscription details.

2. Reverse-Engineering the Rate Limiter

Once we mapped the API, we wrote a script to stress-test the rate limits on both the OTP generation and validation endpoints. We ran three scenarios:

Scenario A: Brute-force wrong OTP codes to measure the validation lockout threshold.
Scenario B: Spam the resend OTP endpoint to measure the generation lockout threshold.
Scenario C (Identity Bypass): Rotate the session identifiers (deviceId and session tokens) while keeping the same source IP to see if the counter resets.

The Results:

Validation Limit: The API allowed 5 incorrect attempts before returning an HTTP 429 API rate limit exceeded message with a variable retry-after cooldown (between 10s to 20s).
Generation Limit: The API allowed 5 SMS requests before lockout, but with a tiny 3-second cooldown.
Identity Bypass: Rotating session-specific device IDs did not bypass the limit. The API gateway successfully tracked requests by the client's source IP.

But this IP-only protection introduced a massive vulnerability.

3. The Vulnerability: Account Takeover (ATO)

Because the rate limit is tied solely to the client IP address and not to the target phone number, the system is highly vulnerable to distributed brute-forcing.

The platform uses a 4-digit OTP (only 10,000 possible combinations, from 0000 to 9999). If a malicious actor wants to compromise a specific phone number, they don't need to bypass the IP rate limit—they just need to rotate their IP.

The Math:

Lockout rate: 5 attempts per IP before a temporary block.
Evasion: By rotating requests through a residential proxy pool of 100 IPs, an attacker can execute 500 attempts every 20 seconds.
Time to Compromise: $$\frac{10,000 \text{ combinations}}{1,500 \text{ attempts/minute}} \approx 6.6 \text{ minutes}$$
Cost: Extremely low cost for residential proxy bandwidth.

Within 7 minutes, an attacker can exhaust the entire keyspace, validate the correct OTP, and gain a valid authentication token for any registered phone number.

4. SMS Flooding & Denial of Service

Similarly, the 3-second cooldown on the /generateOTP endpoint is trivial to exploit. By routing requests through a rotating proxy pool, an attacker can bypass the 3-second cooldown and flood a victim's phone with thousands of SMS messages per minute.

$$\text{5 SMS} \times \frac{60\text{s}}{3\text{s}} = 100\text{SMS/min per IP}$$ With 10 proxy IPs, that is 1,000 SMS messages sent to a single victim every minute, resulting in severe harassment, carrier costs, and temporary denial of mobile service.

5. Responsible Disclosure & Recommendations

_All testing was strictly restricted to developer-owned SIM cards/phone numbers, and no live user accounts were targeted. We have responsibly disclosed these findings to the platform vendor.

To fix these vulnerabilities, we recommend implementing the following architectural remediations:_

Implement Account Lockout: Tie the rate limiter to the phone number (identity) instead of just the IP address. Lock the phone number out of the authentication flow after 5 failed validation attempts.
Increase Entropy: Shift from a 4-digit OTP (10,000 combinations) to a 6-digit OTP (1,000,000 combinations). This increases the search space by a factor of 100, rendering brute-forcing through proxy pools completely impractical.
Strict Token TTLs: Shorten the OTP validity window to 2 minutes.
CAPTCHA Gateways: Introduce a reCAPTCHA or Turnstile verification challenge after the first OTP resend attempt on the registration screen.

hi

Srichinmai Sripathi — Thu, 14 May 2026 05:02:33 +0000

Srichinmai Sripathi

May 13

I Built an AI That Has to Lie to the Internet to Do Its Job

#ai #devops #security #architecture

Comments

4 min read

[Boost]

Srichinmai Sripathi — Thu, 14 May 2026 05:02:24 +0000

Srichinmai Sripathi

May 13

I Built an AI That Has to Lie to the Internet to Do Its Job

#ai #devops #security #architecture

Comments

4 min read

I Built an AI That Has to Lie to the Internet to Do Its Job

Srichinmai Sripathi — Wed, 13 May 2026 19:51:26 +0000

At PCI Oasis Inc , I was handed a task that sounded simple on paper:

"Help build a crawler that navigates e-commerce websites from the homepage to the checkout page."

Easy enough, right? Open a browser, click some buttons, reach checkout. Done.

Except the internet doesn't want you to do that.

The Problem Nobody Talks About

Every major e-commerce platform, your favourite fashion brands, electronics stores, and sneaker sites run some form of bot detection. Cloudflare. DataDome. PerimeterX. Akamai. Kasada.

These systems are sophisticated. They don't just check if you're sending the right HTTP headers. They watch how you behave in the browser.

They measure things like:

Does your mouse move in a straight line?
Do you type at a perfectly constant speed?
Does your browser have a Canvas fingerprint they've seen a thousand times before?
Is your WebGL renderer showing signs of a headless cloud VM?
If anything looks off and I mean anything you get a CAPTCHA, a silent redirect, or just an empty page.

Our crawler had to get through all of that. Autonomously. On any site. Without a human in the loop.

Fingerprint, Meet Counterfeit

Here's what I didn't expect: your browser has a fingerprint, and headless browsers have a very obvious one.

When Chrome runs in headless mode on a cloud server, several things give it away.
The fix? Patch every one of these before the page even loads.

But that's just the beginning. The really interesting stuff is the Canvas fingerprint.

Why Your Browser's Art Class Betrays You

Here's something wild: websites can tell a lot about your browser by asking it to draw something.

The HTML5 Canvas API lets JavaScript render graphics. But the exact pixel output of that rendering varies slightly between real hardware, operating systems, and GPU drivers. Headless Chrome on a cloud VM produces a consistent, identifiable hash — because it always runs on the same virtual GPU.

Bot detection systems have a database of these hashes. If yours matches a known headless browser fingerprint blocked.

The solution? Add noise to the Canvas output. Tiny, imperceptible random variations that make each session produce a unique hash.

Same goes for WebGL — the GPU fingerprint. Headless Chrome on GCP returns "Google SwiftShader" as the renderer. That's a dead giveaway.

The Mouse Problem

This one is my favourite.

Humans don't move their mouse in straight lines. Watch yourself right now your cursor curves, accelerates, decelerates, overshoots slightly and corrects. It's a beautiful, messy, organic path.

Bots move in straight lines. Or they teleport. Both are instant flags.

The solution: Bézier curve mouse simulation.

A Bézier curve is a mathematical curve defined by control points. By generating random control points between the current cursor position and the target, you get a realistic, curved path with natural acceleration and deceleration.

Typing works the same way. Real people don't type at exactly 120ms per keystroke. They have rhythm, occasional hesitation, and natural variance. Gaussian-distributed delays simulate that.

But Wait!! What About the AI Part?

Here's the thing I learned that I didn't expect going in:

The hardest part of building an AI-powered crawler isn't the AI.

It's getting the browser to a state where the AI's decisions can actually execute.

Once you've dealt with fingerprinting, WAFs, and cookie consent banners the AI's job of "figure out how to navigate this checkout" is almost the easy part. The browser is finally in a clean, unblocked state where clicks actually work.

I can't share everything about how the AI navigation works that's the core product. But I'll say this: the most interesting design decision was figuring out when NOT to use AI.

Calling an LLM for every single navigation step is slow and expensive. The real insight was building a system that handles ~60% of decisions with zero AI at all, pure pattern matching and saves the AI for the genuinely hard cases.

That's the architectural principle I'm taking with me: AI is most powerful when it's used precisely, not constantly.

What I Took Away

The impressive part isn't the model. It's everything around the model the infrastructure that gets it into a position where it can actually do something useful.

The browser stealth work, the WAF bypass strategies, the Bézier mouse simulation none of that involves a single API call to an LLM. But without it, the AI is completely useless.

That gap between "AI that works in demos" and "AI that works in production on the real internet" is enormous. And crossing it is mostly an engineering problem, not an AI problem.

If this was interesting to you, the company I worked with PCI Oasis builds security tools for e-commerce payment protection. Their e-skimming labs (the other project I worked on) are open to the public at labs.pcioasis.com if you want to explore real attack simulations in a safe environment.

pcioasis.com

And if you have questions about any of the techniques above, drop them in the comments. Happy to dig in.

Thanks for reading my article :)