We Checked 286 Indian Companies. 4 in 5 Are One Bug Away From a Breach

For the past two weeks, we ran an unauthenticated sweep of the public-facing web estate of 286 Indian organizations, meaning every website, app and API they expose to the internet. They included fintechs and lenders, e-commerce and quick-commerce players, edtechs, health platforms, logistics firms, telcos, media houses and SaaS companies.

We were looking for exposed API keys, open endpoints and anything else an attacker could find without logging in. Across 1,368 internet-facing assets, we confirmed 1,819 security findings.

231 of the 286 organizations (81%) had at least one Critical or High severity issue that anyone on the internet could reach without credentials. 92 of them (32%) had a Critical one. More than 85 million records were readable without a login, and at least 7 million of them belong to identifiable people.

We didn't chain findings into attacks, and we didn't keep any customer data. We found everything in this report from the same place an attacker starts: outside, with no account.

How We Ran the Research

We only looked at two things: what any visitor's browser already downloads, and what a server sends back when someone asks without logging in. That meant JavaScript bundles and their source maps, the API endpoints those bundles call, DNS records, storage URLs referenced in the frontend, and the responses those endpoints give to an anonymous caller.

We ran all the analysis on AI models we host ourselves, so no outside AI service ever saw any company's data.

An agentic harness (a setup where AI agents run the repetitive steps) did the heavy lifting: subdomain and asset discovery, pulling and de-minifying JavaScript, extracting keys and endpoints, mapping which endpoints answered without authentication, and first-pass triage. That's work a human team would need months to do across 286 companies.

Then our analysts checked every finding before counting it. If it came from our own lab targets or we couldn't tie it to a real company, we threw it out.

None of this needed special access, so an attacker running the same kind of tooling sees exactly what we saw. In at least one case, someone already had: an open search cluster we found already held indexes named pwned_test and all_exfil, created by earlier visitors over the past several months.

The Numbers

Metric	Value
Organizations with findings	286
Internet-facing assets with findings	1,368
Distinct affected endpoints / URLs	~1,500
Confirmed findings	1,819
Average findings per organization	6.4

By severity

By organization

• 97% had at least one Medium-or-worse issue.
• 81% had at least one Critical or High issue.
• 32% had at least one Critical issue.

Critical and High findings make up 30% of the total, and they're spread out, not piled up in a few weak companies. Most organizations had one or two serious problems sitting next to a longer tail of hygiene issues.

What We Found

No company names, URLs or reproducible detail follow. Affected organizations are being notified privately (see Responsible Disclosure below).

Secrets in JavaScript: Exposed API Keys and Tokens

Exposed API keys and other secrets were the most common serious problem. 192 organizations (67%) shipped at least one secret, key or credential to the browser, and 119 (42%) had one rated Critical or High.

What we found in production bundles:

• Internal API keys and static service tokens. The largest group by far: 121 findings across 94 organizations. In many cases the key was the only thing protecting a backend API, so anyone who opened the bundle had access. One long-lived service token, valid until 2053, opened a production user directory with customer names, emails and phone numbers.
• Encryption and signing keys. 52 findings across 44 organizations, nearly half of them Critical. AES keys used to "encrypt" Aadhaar numbers, MPINs or KYC payloads in the browser before sending them; HMAC keys guarding OTP requests; RSA and JWT signing keys that could forge login tokens accepted by production APIs. Encrypting something in the browser with a key you also send to the browser protects nothing.
• Payment gateway and UPI credentials at 14 organizations.
• SMS, email and messaging provider tokens at 10 organizations, including real-time pub/sub keys with publish rights.
• CRM and helpdesk keys at 10 organizations. One of them exposed a support desk holding patient contact details.

Six organizations leaked keys that gave direct cloud access: an AWS IAM key pair, a Cognito identity pool that hands out AWS credentials to anyone, 261 hard-coded storage access tokens, a cloud identity client secret, and two Google Cloud service-account private keys. Far more common were application keys that open the company's own APIs.

Unauthenticated API endpoints

60 organizations (21%) had at least one endpoint that returned personal or business data to a caller with no session at all, and 33 of those were Critical or High.

The worst of them:

• An internal analytics console that ran any SQL query sent to it, against a customer-data warehouse of 4.16 million users and 8.4 billion behavioral events.
• A call-analytics dashboard exposing 563,000 loan-recovery call records, covering about 159,000 borrower phone numbers, with recordings and AI-generated transcripts.
• Learner profiles keyed to more than two million account IDs, and a separate learner table whose schema included Aadhaar number, date of birth and address fields.
• A patient appointment API that returned anyone's booking history from a mobile number alone, and let an anonymous caller cancel those appointments.
• Staff directories with corporate emails and roles (one with about 900 accounts and their bcrypt password hashes), exam candidates' details keyed only by hall-ticket number, and vendor bank account and PAN data.

A handful went further and accepted writes: creating records, deleting tokens, minting upload URLs into production storage, or uploading files straight into public buckets.

Most of these endpoints were built for an internal admin tool or a mobile app, and someone assumed nobody outside would ever find the route. But the JavaScript bundle listed it for anyone to read.

Broken access control (IDOR)

IDOR (insecure direct object reference) means changing an ID in a request, say user 1001 to 1002, and getting someone else's data. We found the fewest of these, mostly because IDOR testing usually needs a logged-in account, and we never logged in.

Even so, several organizations had object-level access control failures visible to an anonymous caller: device push tokens returned by walking a sequential user ID, a KYC document endpoint that accepted any reference number and returned PAN/Aadhaar-linked records, a patient lookup keyed on a phone number, a database whose row-level security could be bypassed anonymously, a merchant API that served any store's catalog, and a cache that would hand one user's private profile page to another. Three more admin consoles fell to a known framework flaw that skips the login check entirely.

If these show up without a login, the authenticated surface almost certainly has more.

Cloud and storage misconfigurations

112 organizations (39%) had a storage, cloud or configuration issue.

• Open databases and search clusters at 24 organizations. One unauthenticated cluster held 63.5 million documents from a financial-services company's internal platform, including more than 142,000 employee records. Another held 15.8 million documents, accepted writes, and already carried indexes left by previous intruders. An open Redis instance held live real-money payment configuration with full write access.
• Publicly listable storage buckets at 37 organizations (26 rated Critical/High). Most held static assets, but not all: patient prescriptions and consultation recordings, PAN card scans, customer tax invoices, seller KYC documents and databases, résumés with dates of birth, customers' personal photographs, and roughly 20,000 webcam and screen captures from online exam proctoring. Across the buckets we could size, about 750,000 objects were enumerable by anyone.
• Source code repositories left on web servers. Exposed .git and .svn directories, plus .env and config files, at 21 organizations. These leaked full source trees, root database credentials, live GitHub tokens with write access to private repositories, and production payment-gateway secret keys.
• Open Firebase / Firestore / Realtime Database at 19 organizations, including databases that allowed anonymous read and write.
• Debug surfaces left on in production at 33 organizations: Spring Boot Actuator endpoints (one offering a full JVM heap dump), framework debug pages printing settings and internal IPs, and phpinfo pages.

Exposed internal and admin surfaces

This is the widest category. Almost every organization leaked something about its internals, and most of it is low severity on its own. The serious part is what sits underneath:

• Staging, UAT and dev environments reachable from the internet at 133 organizations (47%), often without the WAF that protects production, and in some cases running a full replica of the payments stack.
• Admin panels and back-office consoles served to anonymous users at 133 organizations (47%), 59 of them rated Critical/High. Several relied entirely on the frontend to decide who was an admin.
• Production source maps at 125 organizations (44%). These turn a minified bundle back into the original source tree, in some cases thousands of files, including internal admin apps, KYC flows and payment consoles. 89 organizations had this at Critical/High because the recovered source contained credentials or the full API contract of a privileged system.
• API documentation (Swagger/OpenAPI, Postman collections) at 31 organizations, and GraphQL introspection at 13.
• CI/CD, identity and infrastructure tools (build servers, identity-provider admin consoles, deployment controllers, VPN and firewall management interfaces, secrets managers) reachable at 55 organizations.
• Server-side request forgery on a few hosts, letting an anonymous caller make the server fetch internal addresses, in one case including the cloud metadata service.
• Dangling DNS records at 76 organizations (27%): subdomains still pointing at deleted cloud resources. Anyone can claim that resource and serve their own content on the company's domain. This is called subdomain takeover. Several sat on login, KYC or payment-adjacent subdomains.

Industries Affected

Small samples (fewer than 20 organizations) should be read as directional. Government-adjacent services appeared in our set but in too few numbers to report a rate.

The sectors with the highest exposure rate and the sectors with the most damaging findings aren't the same.

• Edtech, healthcare and telecom had the highest exposure rates. Every organization we looked at in those sectors had at least one Critical or High issue. Edtech carried the heaviest load of any sector, at 3.4 serious findings per company, much of it unauthenticated endpoints returning learner and student records.
• Media and entertainment had the most Criticals per company (level with telecom), driven by open search clusters, a customer-data warehouse that accepted raw SQL, and source repositories left on web servers with production credentials inside.
• Fintech and BFSI had the lowest exposure rate of the large sectors (69%), which reflects real investment in security. But the fintech findings we did see hit the most sensitive data in the study: Aadhaar and PAN handling, video-KYC flows, DigiLocker integrations, MPIN encryption keys and KYC backends. And two of the biggest exposures of financial customer and employee data sat outside the core banking estate, on an internal platform and on a vendor's dashboard. Fewer hits on far more dangerous data is still a bad place to be.
• Logistics and mobility had a middling exposure rate but the joint-highest share of organizations with a Critical (62%, level with edtech), driven by hardcoded keys that opened internal operations APIs and staff data.

What Kind of User Data Is Exposed

We report categories, not records. Across the findings that touched personal data, these are the types we saw reachable without authentication:

• Names, phone numbers and email addresses, including customer contact lists and full staff directories
• Physical and delivery addresses, and dates of birth
• Aadhaar and PAN references, PAN card scans, and the keys used to "protect" them in transit
• KYC documents, video-KYC application source and identity-document upload flows
• Health data: patient appointment histories, prescriptions, consultation recordings and patient contact details
• Financial data: loan-recovery call recordings and transcripts, borrower phone numbers, invoices, payouts, vendor bank accounts and GST identifiers
• Student and candidate records: profiles, leads, exam marks, résumés and proctoring images
• Employee records, including password hashes for an entire staff base
• Personal photographs uploaded by customers
• Device identifiers and push tokens that allow targeted messaging to individual users

Scale. More than 85 million records were readable without a login. The biggest single exposure was 63.5 million documents in one open search cluster at a financial-services company, including more than 142,000 employee records. Behind it come a 4.16-million-user customer-data warehouse, more than two million learner accounts, 15.8 million documents in an open media search cluster, and 563,000 loan-recovery call records. At least 7 million of the exposed records belong directly to identifiable customers, borrowers, learners, patients and employees, and about 750,000 more files sat in publicly listable storage.

These counts come from what the systems reported about themselves (index sizes, row counts, result totals), not from downloading the data. They are a floor. Several exposures, such as the patient lookup by phone number, have no fixed size: anyone with a list of mobile numbers can keep querying.

Why This Keeps Happening

Keys ship to the frontend because it's the fastest way to make a feature work. A developer needs the web app to call an internal API, puts the key in an environment variable, and the build tool inlines it into the public bundle. Nobody notices because it works.

APIs trust the frontend to enforce access. The admin UI hides a button from non-admins, so the API behind it never checks. Anyone who reads the bundle can call the API directly.

Internal tools get deployed like they're on an intranet. Search clusters, analytics consoles, Kibana dashboards and metrics endpoints are built for teams inside the network, then end up on a public IP with no login.

Staging and test environments never die. They get spun up for a launch, keep production-like data, sit outside the WAF, and are forgotten. Nearly half the organizations had one reachable.

Point-in-time pentests miss what shipped next week. Most of these issues live in code that changes on every deploy: a new bundle, a new subdomain, a new bucket. An annual test only sees one snapshot, while attackers get to look at every release.

What This Means Under DPDP

From May 2027, the Digital Personal Data Protection (DPDP) Act, 2023 will require companies to put reasonable security safeguards in place to prevent personal data breaches. An endpoint returning customer records to anyone who asks is a compliance exposure as well as a security one, and "nobody knew the URL" won't count as a safeguard.

What to Check This Week

You don't need a new tool for any of this.

1. Grep your production JavaScript for secrets. Pull the bundles your site actually serves (not the repo) and search for keys, tokens, secret, password, AKIA, private-key headers and gateway credentials. Check whether you're serving .map files while you're there.
2. Call your own APIs without a session. Take the endpoint list from your bundles, strip the auth header, and see what comes back. Anything that returns data or accepts a write is a finding.
3. Check for repositories and env files on your web servers. Request /.git/config, /.svn/entries and /.env on every host you own. If any of them return content, assume every credential inside has been taken.
4. Find your internal data stores on the internet. Scan your own IP ranges for Elasticsearch, Kibana, Redis, Metabase and Prometheus ports. None of them should answer an anonymous request.
5. Inventory and kill unused staging hosts. List every subdomain in your DNS, mark what's non-production, and either put it behind SSO/VPN or delete it. Remove DNS records that point at cloud resources you no longer own.
6. Rotate every credential that has ever shipped to a browser. Just removing the key from your next build won't fix it. The old bundle is already sitting in caches and web archives. Rotate it, then move the call server-side.
7. Audit public cloud storage permissions. Check every bucket and Firebase/Firestore rule set for anonymous list, read or write. Make "private by default" the rule and treat public buckets as exceptions you can justify.

Responsible Disclosure

We're reporting every Critical and High finding privately to the affected organization, with evidence and fix guidance. That work is still going on, and it's been the hardest part of the project.

Some organizations got back to us quickly, took the report seriously and patched within days. For many others, the problem has been finding someone to tell:

• No published security contact. Most of the organizations we looked at have no security.txt, no vulnerability disclosure policy and no bug bounty. The only way in is a generic support inbox or a social media handle.
• Reports go nowhere. Messages sent to support, grievance or privacy addresses get a ticket number and silence, or a reply asking us to log in and raise a customer complaint.
• No clear owner. Even when we reach a person, it's often unclear who owns the asset, especially for staging hosts, acquired brands and agency-built microsites.

We're continuing to reach out through every channel we can find, including direct introductions to security leaders. Until an organization confirms a fix, we treat its findings as live. That's why this post names no one and includes nothing that could be used to reproduce an issue. The figures here are aggregates.

We kept only what we needed to report each finding. Personal data seen during validation wasn't stored beyond that, and individual findings won't be published.

If you run security at an Indian company: publish a security.txt and a disclosure email that a human actually reads. Researchers are finding these issues either way, and that address decides whether you hear about a problem from them or from an attacker.

If you think your organization was in scope and you haven't heard from us, contact security@strobes.co. We'll verify ownership and share what we found.

Find Out What Attackers See About You

Attacker's First Look runs this same research for your company only, with your permission, and keeps running it as you ship.

• Verify ownership. Confirm your domain with a work email address.
• Agree scope. An analyst works with you to set what's in and out.
• We research your external surface. AI agents and analysts look at your domains, frontends and APIs the way an outside attacker would, and keep watching every new release.
• Findings go only to you. The verified contact gets each finding privately, with evidence and fix guidance.

It doesn't commit you to buying anything. If you want to know what someone with no credentials can already see about your company, sign up for Attacker's First Look.

Related Reading

• How to Pentest Single-Page Applications (React, Angular, Vue)
• How to Check for Subdomain Takeover: A Step-by-Step Guide
• Understanding External Attack Surface Management
• Strobes Attack Surface Management