India Startup Data Breaches: Why DIY Auth Keeps Failing

Almost every Indian startup breach of the last decade reads the same way: no exotic zero-day, no nation-state actor — just an open storage bucket, a leaked cloud key, or an API that never checked who was calling. The average data breach in India now costs ₹22 crore, an all-time high, up 13% year over year (IBM, Aug 2025). And with the DPDP Rules 2025 now notified, the same mistakes carry a penalty of up to ₹250 crore per instance. This post walks the actual incidents, the handful of auth bugs behind them, and what changes when you stop rebuilding those bugs yourself.

NamoID is an India-first OAuth 2.1 / OIDC identity provider, so we read these post-mortems closely — the failure modes below are the exact ones an identity layer exists to prevent. We'll teach the pattern first; the product shows up at the end, where it belongs.

The pattern: config and auth failures, not zero-days

Line up the verified Indian breaches and the root causes rhyme. These are not sophisticated attacks — they are missing access control on data and secrets.

Company	Year	What leaked	Root cause
Justdial	2019	~100M users' PII	Unauthenticated public API, open since ~2015
CSC / BHIM (cscbhim.in)	2020	7M+ records incl. KYC	Misconfigured public AWS S3 bucket
Dr Lal PathLabs	2020	Millions of lab records	Public S3 bucket, no password
RailYatri	2020	~700K users' PII + UPI IDs	Misconfigured Elasticsearch, no auth
Juspay	2020–21	35M records, masked cards	Leaked, unrotated AWS access key
Upstox	2021	~2.5M KYC (Aadhaar, PAN, bank)	Compromised AWS key
BigBasket	2020–21	~20M records, hashed passwords	Database stolen and leaked

Two clusters dominate. Open datastores — S3 buckets and Elasticsearch indexes reachable with no credential at all (CSC-BHIM, Dr Lal PathLabs, RailYatri). And leaked long-lived cloud keys — a single AWS access key was the direct ingress for both Juspay and Upstox. Justdial's was arguably worse: a public API that returned user data to anyone, unchecked, for roughly four years. Note the careful scale framing matters here — Domino's India's 2021 incident, often cited as "180M users," was ~180M orders, not unique accounts. Precision is part of credibility.

Not every big number is real, either. Skip the ones that don't survive scrutiny: the "1 billion Aadhaar biometrics" line traces to a claim Gemalto publicly retracted; the 2021 MobiKwik figures were company-denied and are still best described as alleged and RBI-audited, not confirmed. A trustworthy security post cites what's verifiable and flags what isn't.

Why "we'll just build auth" is where it goes wrong

Here's the catch: the breaches above aren't storage bugs so much as authorization bugs — data and secrets that should have required a credential and didn't. Auth is where this class of mistake concentrates, and auth is exactly what teams underestimate. When someone says "we'll just add a login," the real surface area is much wider — standards-correct OAuth/OIDC, PKCE, token rotation, session revocation, MFA, rate limiting, audit. We broke that lifetime cost down in Build vs Buy Auth in India; the short version is that the login form is 5% of the work.

The other 95% is where the recurring bugs live. OWASP still ranks Authentication Failures at #7 in its 2025 Top 10, with recorded CVEs nearly doubling since the 2021 edition. The failure classes read like a checklist the breaches above failed:

• No rate limiting — credential stuffing and brute force walk in. (Fixes in Rate-Limiting Auth Endpoints.)
• User enumeration — differential errors or timing confirm which accounts exist, seeding the next attack.
• Weak session and token handling — session IDs not rotated after login, tokens not invalidated on logout, refresh tokens with no replay detection.
• Plaintext or weakly hashed passwords, and missing MFA.
• Long-lived secrets — the unrotated AWS keys behind Juspay and Upstox.

None of these are hard to name. All of them are easy to get subtly wrong, and the penalty for wrong is a headline. Stolen or compromised credentials were the joint-most-common initial attack vector in India in 2024 — 18%, tied with phishing — and the single most common globally at 16% (IBM, 2024). Credentials are the front door, and hand-rolled auth is where the lock gets installed wrong.

What DPDP changes in 2027 — and why the clock is already running

For years "we'll harden it later" was a survivable bet in India. That window is closing. The Digital Personal Data Protection Rules 2025 were notified on 13 November 2025 (PIB), with the substantive security obligations phasing in around May 2027. The compliance clock is no longer theoretical.

What bites, specifically:

• Up to ₹250 crore per instance for failing to take reasonable security safeguards to prevent a breach (Section 8(5)), a penalty the Board may enhance up to twice the amount under Section 33(3). Negligence is enough — an open bucket needs no attacker to attract the penalty.
• Rule 6 now specifies the floor for "reasonable security safeguards": encryption or masking, access controls, logging and monitoring, backups, and one-year retention of logs. Encryption at rest, access control, and audit-log retention are now legally named, not optional hygiene.
• Two-stage breach reporting — affected users "without delay," and a detailed report to the Data Protection Board within 72 hours — layered on top of CERT-In's existing six-hour rule.

One honest clarification, because overstating the law helps no one: "all Indian user data must stay in India" is not the current mandate. What is mandated in-country today is payment data (RBI) and 180 days of security logs (CERT-In); general personal data transfer is permissive under DPDP Section 16, since no country has been restricted. In-region residency is a prudent default — it simplifies CERT-In log compliance and future risk — but present it as sound posture, not a blanket legal requirement. We cover the specifics in Data Localization in India: DPDP Rule 15 and the DPDP Audit Trail Requirements.

The uncomfortable part for founders: you are the Data Fiduciary. If your auth layer — or a vendor's — leaks user data, the liability is yours. Which makes how you build or buy auth a board-level risk decision, not a sprint ticket.

The bugs that keep leaking data, mapped to the control that stops each

Every root cause above has a well-understood fix. This is the checklist to hold any auth implementation — yours or a vendor's — against:

Breach root cause	The control that prevents it
Unauthenticated API / open datastore	Authorization enforced on every endpoint; deny by default
Leaked long-lived cloud key	Short-lived credentials, secret rotation, no keys in code
Credential stuffing / brute force	Per-IP and per-identifier rate limiting on auth and OTP
Account enumeration	Uniform responses and timing; never reveal if an account exists
Plaintext / weak password storage	Modern hashing (bcrypt/argon2); prefer passwordless and passkeys
Stolen session or refresh token	Rotate sessions after login; refresh-token rotation with replay detection
No breach forensics	Append-only, tamper-evident audit log with retention

If you build, all of this is yours to implement correctly and keep correct as browsers, platforms, and the law evolve. Refresh-token rotation, for instance, is not just "issue a new token" — when an already-used refresh token reappears, that's a theft signal, and the correct response is to revoke the whole token chain, not reject one request. We walk through that in Refresh Token Rotation and Replay Detection. Multiply that subtlety across the table above, forever.

How NamoID approaches this

We built NamoID so this checklist is the default, not a backlog. Concretely, the controls above ship as invariants:

• PKCE required on every flow, including first-party clients; no implicit grant.
• Refresh-token rotation with replay detection — a reused token revokes the chain and emits a security event.
• Provider tokens encrypted at rest (AES-256-GCM); the private signing key never leaves the service.
• Aadhaar masked to the last four digits — the full number is processed in memory and never persisted.
• Rate limits on /auth and OTP endpoints, backed by Redis.
• An append-only audit trail — every state change is an event, which is also what makes DPDP-grade forensics and Rule 6 log retention straightforward.
• India-first data residency as the default posture.

On compliance, here's exactly where we stand — no more, no less. NamoID is built DPDP-ready: the architecture assumes India's DPDP Act from day one. We've published a CSA STAR Level 1 self-assessment (CAIQ v4.1.0) to the Cloud Security Alliance registry — a public, standards-based account of our controls, and we're clear that Level 1 is a self-assessment, not a third-party audit. Our security assessments are run by the in-house PolyMindsLabs team against an OAuth/OIDC-specific test plan; we label those honestly as first-party. We have not completed a SOC 2 or ISO 27001 certification — we pursue independent certification when a partner requires it, and we'll prove it under that engagement, with the threat model and full assessment results available under NDA. If a security page claims more certainty than that, be skeptical; on an identity product, precise honesty is the point.

Buying DPDP-first auth doesn't erase your liability as the Data Fiduciary. What it does is hand you day-one residency, encryption, masking, rate limiting, and an audit trail — instead of you reimplementing the exact bugs that filled the last decade of breach headlines, and hoping you got every subtle one right.

FAQ

Is my startup liable under DPDP if a vendor causes the breach? Yes. You are the Data Fiduciary for your users' data. A processor's failure doesn't transfer your obligation to take reasonable security safeguards — so choosing vendors that shrink your attack surface is itself a compliance control.

Does all Indian user data legally have to stay in India? No, not as a blanket rule today. Payment data (RBI) and 180 days of security logs (CERT-In) must stay in-country; general personal data is permissive under DPDP Section 16 because no country has been restricted. In-region residency remains a sound default, but it's prudent posture, not universal law.

What's the DPDP penalty for a data breach? Up to ₹250 crore per instance for failing to take reasonable security safeguards (Section 8(5)), which the Board may enhance up to twice under Section 33(3). Penalties follow a Board inquiry, not automatically — but negligence, like an exposed bucket, is enough to qualify.

Which auth mistakes cause most breaches? In the Indian incidents above: unauthenticated APIs and datastores, leaked long-lived cloud keys, and the classic auth failures OWASP tracks — missing rate limits, enumeration, weak session and token handling, and no MFA.

If you're weighing building this yourself, start with the honest cost breakdown in Build vs Buy Auth in India — then decide with your eyes open.