Two-Thirds of iPhone AI Chatbot Apps Are Bleeding API Keys

Key points

• Researchers intercepted network traffic from 444 iOS chatbot apps and found 282, nearly two-thirds, exposing working credentials for paid AI services.
• Exposure methods included plaintext API keys, reusable bearer tokens, and backend proxy servers that accepted model requests with no authentication at all.
• An attacker who grabs a key can send model requests billed to the developer or run abuse traffic through the developer's identity.
• Developers should route all provider keys through an authenticated server-side proxy, never holding them in the mobile client directly.
• Users who've pasted sensitive text into cheap chatbot wrappers should treat that content as potentially logged.

How bad is the exposure?

Researchers tested 444 AI chatbot apps for iPhone and found 282 of them, nearly two-thirds, handing over a working path to paid AI services through their own network traffic. The failure modes weren't subtle: a plaintext API key sitting inside outbound requests, a reusable bearer token that never rotated, or a backend proxy that accepted model requests with no authentication header. Point a script at that last kind of endpoint, send a prompt, and the response is billed to the developer.

What that enables in practice: drain a developer's OpenAI or Anthropic credit, run abuse traffic through the developer's identity, or run a free public mirror of a paid model until the provider revokes the key.

Why is this so common?

None of it is novel. Hardcoded secrets in mobile apps have appeared in OWASP's Mobile Top 10 for years, currently tracked as M1: Improper Credential Usage. Volume is the issue. The AI app boom has produced a long tail of wrapper apps where the entire product is a thin client around someone else's model, and the developer's key is the only thing standing between the user and the bill.

The study didn't name individual apps or break down which upstream providers appeared most often, though apps in this category overwhelmingly route to a small set of commercial LLM APIs. Our June report on a debug flag that turned M365 Android apps into a token buffet caught a structurally similar failure: credentials exposed at the client layer because a server-side control never made it to production.

What should developers do?

Keys belong on a server you control, behind an authenticated proxy that enforces per-user rate limits and request quotas. Mobile clients should never hold a provider key directly. If you must call a third-party API from the device, use short-lived, scoped tokens issued by your own backend after the user authenticates.

Regulatory exposure is thinner than in a typical consumer breach since no personal data is necessarily involved.

Should you worry as a user?

If you've used a free or cheap iOS chatbot wrapper, assume prompts sent through it are being logged somewhere you can't see. Don't paste passwords, medical details, or anything work-confidential into them. Prefer first-party clients from the model vendor itself when the conversation matters. And if a chatbot app abruptly stops working, that's more likely the upstream provider revoking a leaked key than a bug. It tells you something about the developer's habits.