TeaOnHer Exposed Thousands of IDs After API and S3 Misconfigurations

What happened

TeaOnHer, a new app for sharing dating gossip, accidentally exposed thousands of users’ personal data to the open web. TechCrunch discovered exposed admin credentials, public API documentation that allowed unauthenticated queries, and links to ID photos and driver’s licenses stored in an Amazon S3 bucket set to public access.

The chain was simple and fast: an API landing page revealed developer credentials, the /docs endpoint listed usable commands, and several API calls returned user records with direct URLs to identity documents. TechCrunch reached the developer but received limited follow-up; the issues were patched only after disclosure.

How the exposure unfolded

Investigators started at the app store listing and the privacy policy link, found a domain and a single subdomain, and opened the API landing page. That page contained an exposed email and plaintext password for an admin account and linked to Swagger-style documentation that could execute queries directly from a browser.

Because some endpoints required no authentication, it was possible to list users in the identity verification queue and fetch individual records — including web addresses for uploaded IDs. The files lived on an S3 bucket with public read permissions, meaning anyone with a link could open them.

Why this matters

This incident illustrates a broader risk: apps that collect identity documents create high-value targets. Regulatory pressure for age verification and identity checks will push more services to collect PII, increasing the number of databases that, if misconfigured, leak sensitive data. The result: greater privacy harm and legal exposure for operators.

Think of it like leaving the keys under the welcome mat and publicly posting the house layout. An open API documentation page plus public cloud storage is exactly that — an invitation to scrape and harvest personal data at scale.

Immediate remediation checklist

• Remove public read access from cloud buckets and rotate any exposed credentials.
• Require authentication for all API endpoints and audit access logs for suspicious activity.
• Minimize PII collection: only store what’s legally required and for the shortest time needed.
• Run targeted API security tests and automated scans before launch, and maintain a disclosure channel for researchers.

What organizations should take away

Whether you’re a solo developer shipping an idea or a larger team building verification systems, responsibility for user data doesn’t scale away. Invest in simple guardrails: sane access controls on cloud storage, authentication on APIs, and honest privacy notices. If you require IDs for compliance, assume attackers will target that data and design accordingly.

QuarkyByte’s approach is to rapidly map exposures, prioritize fixes by risk and impact, and help teams translate technical findings into operational and regulatory actions. That means quickly locking public buckets, enforcing API auth, and producing a remediation roadmap that reduces user harm and legal exposure — not just a pile of technical tickets.

If you suspect an app is leaking sensitive information, document what you find, use secure channels to disclose it, and urge operators to act. And if you run services that collect identity documents, ask: do we really need to store these files, and are we prepared to protect them?