Case study

Exposed API key: 1 day to compromise everything, 0 data lost

Antoine Heriaud · January 2026 · 4 min read

A one-day audit. A few minutes of network traffic analysis. An infrastructure API key visible in the headers, giving full control over all of the platform's content. This case is common among independent developers building fast. It's also one of the easiest to fix.

Context

An independent developer launched an AI-generated video streaming platform. He reached out for a one-day audit, enough to cover the most critical risks before a wider production rollout. The platform hosts videos with an external provider. The interface lets users watch, search and organise them.

The discovery

Opening the browser's developer tools and inspecting network requests, an API key appears in the headers of a request to the hosting provider's API. This key is sent directly from the frontend, meaning any visitor to the site can see it in a matter of seconds.

No complex exploitation was needed, no injection, no fuzzing. Any modern browser's developer tools are enough.

The real impact

With this key, I access the hosting provider's API. The associated permissions allowed:

Listing all hosted videos and their metadata
Deleting any video from the platform
Uploading new content under the account
Potentially modifying permissions and revoking the developer's own legitimate access

No user data was exposed here. But the platform itself (its content, its continuity, its availability) was entirely under the control of anyone who had inspected the network requests.

An infrastructure key exposed client-side is like leaving your server keys in the window display.

The remediation

I documented the vulnerability with a screenshot, proof of exploitation, and impact assessment. The developer understood immediately. The fix is architectural: all interactions with the hosting provider's API must go through his own backend, never exposed directly to the browser.

The right architecture: the frontend calls an endpoint on its own server. That server proxies the request to the hosting provider's API using a key stored as a server-side environment variable. The frontend knows no infrastructure keys.

A short verification after the fix confirmed the key no longer appeared in any client-side network request. Mission completed in one day, problem resolved cleanly.

The takeaway

Infrastructure API keys are never meant for the frontend. Even in a development application. Even if "nobody knows about it yet." Automated scanners and bots constantly index web traffic, and keys exposed in network requests are collected far more often than people realise.

This case also illustrates the value of a short, targeted audit for an independent developer: one well-used day identified and resolved the most critical vulnerability before any incident. The developer left with a clear report, a verified fix, and a more solid architecture.

Methodology How much does a pentest cost? The criteria that drive the price One day or five, black box or white box, web or infrastructure: pentest costs can vary fourfold depending on specific criteria. What you need to understand before requesting a quote. May 2026·6 min read → Case study Incomplete fix: when the server accepted an empty cookie A session cookie on the web side, an unverified API, and a fix that stops halfway. Testing the mobile app reveals a second layer of the same issue. April 2026·5 min read → Vulnerabilities XSS - Cross-Site Scripting: injecting code into a victim's browser XSS lets an attacker inject arbitrary JavaScript into a victim's browser. Session theft, phishing, keylogger, the impact is limited only by the attacker's imagination. May 2026·10 min read →

A question after reading?

If you have doubts about your key exposure or architecture, send a message. No pitch, no automatic quote.

Or book a 30-minute scoping call directly

Book a call →