AI iOS Apps Found Leaking LLM API Credentials Through Network Traffic

Hundreds of AI-powered iOS apps are exposing large language model API credentials through network traffic, putting developers at risk of account abuse, unexpected cloud bills, and unauthorized use of paid AI services.

A new academic study analyzed 444 free iOS apps with working LLM features and found that 282 of them exposed exploitable credentials or backend access paths during normal app use. That means 64% of the tested apps had a credential leakage problem.

The research, titled Mind your key: An Empirical Study of LLM API Credential Leakage in iOS Apps, was conducted by researchers from Wake Forest University and collaborators. The findings show that the problem affects both small apps and popular apps, including one vulnerable app with more than 2.3 million user ratings.

Researchers Built LLMKeyLens to Test Real App Traffic

The researchers created a dynamic testing framework called LLMKeyLens to inspect app behavior at runtime. Instead of relying on static code analysis or app binary decryption, the tool observed network traffic while each app’s AI features were used.

The study started with 5,619 LLM-related iOS apps from the US App Store. Researchers narrowed that pool to 1,092 candidates and then manually tested 444 free apps that had accessible, working LLM features.

The method matters because iOS apps distributed through the App Store are harder to inspect through traditional static scanning. Runtime analysis let the researchers capture what the app actually sent to LLM providers or backend proxies during use.

Finding	Number	Why it matters
Apps tested	444	Free iOS apps with working LLM features
Apps with exposed credentials	282	64% of the tested apps leaked exploitable credentials or access paths
Fully exploitable cases	146	Attackers could abuse access with few or no practical limits
Remediated after 90 days	28%	Most affected apps still had exploitable issues after disclosure

Three Main Leakage Patterns Were Found

The most common problem was JWT-based token leakage. According to the research paper, this pattern accounted for 48% of the affected apps. These apps did not always expose the raw LLM API key, but they leaked bearer tokens that could still be replayed against backend services.

The second pattern involved unauthenticated backend proxies. In 33% of affected apps, developers moved the LLM API key to a server but failed to require proper authentication on the proxy endpoint. Once an attacker understood the request format, the backend could be abused as an open relay for LLM inference.

The third pattern involved plaintext API keys. In 19% of affected apps, the app sent provider credentials directly in requests to LLM services. OpenAI’s API key guidance warns developers not to deploy API keys in mobile apps or other client-side environments because exposed keys can be used to make requests on the account owner’s behalf.

Why This Creates a Cost and Security Risk

Leaked LLM credentials can create immediate financial damage because API calls are often billed to the developer account. Attackers can use exposed keys or weak proxy endpoints to generate text, process prompts, drain credits, or trigger large usage spikes.

Google also tells developers to secure and restrict API keys. Its Gemini API key documentation explains that key restrictions can limit how a key gets used, which reduces the damage if a credential is exposed.

The risk is not limited to raw API keys. Broken backend authentication can be just as dangerous. OWASP’s API security guidance warns that broken authentication can let attackers abuse APIs when tokens, identity checks, or access controls are missing or incorrectly enforced.

Many Defensive Measures Were Weak or Missing

The study found that only 143 of the 444 apps used any form of interception resistance. The most common defense simply bypassed the system HTTP proxy, but researchers said that approach failed in 81% of cases when they switched to VPN-based traffic capture.

Apple’s App Transport Security helps improve network privacy and integrity by encouraging secure connections, but encrypted transport alone does not solve leaked credential design. If an app sends a reusable secret from the client, that secret can still become exposed in controlled or compromised environments.

The stronger defenses were rare. Apps that combined multiple protections, such as payload encryption, anti-debugging checks, and better backend enforcement, were harder to analyze and less likely to expose reusable credentials.

• Do not embed LLM provider API keys in iOS apps.
• Use a backend service to handle provider credentials.
• Require authentication and authorization on all LLM proxy endpoints.
• Use short-lived tokens and enforce expiration on the server.
• Apply provider-side restrictions where available.
• Rotate exposed keys and monitor unusual LLM usage spikes.

Remediation Remains Slow

The researchers rechecked the 282 vulnerable apps 90 days after responsible disclosure. Only 28% showed clear evidence of remediation, while 72% remained exploitable.

Some developers revoked exposed keys, added backend authentication, or changed their architecture. Others removed features, abandoned services, or left the issue unresolved. The study also found JWT problems such as missing expiration claims, extremely long token lifetimes, and servers accepting expired tokens.

This shows that secure LLM integration still lags behind the fast adoption of AI features in mobile apps. Developers need to treat LLM credentials like production secrets, not app configuration values. Provider documentation, platform review processes, and automated testing also need to catch AI-related credential leaks earlier.

What Developers Should Do Now

Developers who ship AI features in iOS apps should review their LLM integration immediately. Any key sent directly from the app to a provider endpoint should be treated as exposed and rotated.

Teams using OpenAI should follow the API key safety recommendations and route requests through a backend that keeps secrets server-side. Teams using Gemini should review Google’s key management guidance and apply restrictions where supported.

Backend proxies also need the same security attention as any public API. Developers should validate tokens, reject expired credentials, apply rate limits, log abuse patterns, and test endpoints against broken authentication risks. iOS teams should also review Apple’s network security guidance as part of a broader secure development process.

FAQ