Key Takeaways
- Any API key sent to the browser or stored client-side is visible in DevTools; this is inherent to how client-side code works, not a browser flaw.
- The three DevTools locations to check are Network (headers, parameters, bodies), Sources (JavaScript bundles), and Application (storage).
- OWASP and CWE-321 classify exposed client-side credentials as a top security risk.
- Public keys like Stripe’s publishable key are safe for browser use when scoped and restricted; secret keys never belong in the browser.
- Minification and referrer restrictions reduce risk but do not make a key secret.
- If a key is exposed, rotate it immediately, review logs, audit its spread, and redesign the architecture.
What Does “Seeing an API Key in DevTools” Mean?
It means locating the key value, typically an authentication string, in one of several browser-accessible locations. A key may appear as a value in an HTTP request header (Authorization: Bearer), a URL query parameter (?api_key=), part of a JSON request body, a string in a JavaScript bundle, or a value stored in localStorage, sessionStorage, or a cookie.
None of these locations require special access. DevTools opens in any browser via F12 or right-click and Inspect.
Where Do API Keys Appear in DevTools?
API keys surface in three DevTools panels:
| DevTools Panel | What to Look For | Common Key Locations |
| Network | All HTTP requests and responses | Authorization or X-API-Key headers, query parameters, JSON bodies |
| Sources | All JavaScript files and source maps | Hardcoded strings, compiled environment variables, SDK init calls |
| Application | All browser storage | localStorage, sessionStorage, cookies, IndexedDB, cached responses |
The Network tab is the most direct route to an exposed key. Opening DevTools, reloading the page, and filtering by XHR/Fetch reveals every API call, with authentication values often visible in request headers.
The Sources tab shows all JavaScript loaded by the page, including minified bundles. A global search (Ctrl+Shift+F or Cmd+Option+F) for terms like apiKey, token, or Bearer finds hardcoded keys even in minified code, since minification is not encryption.
The Application tab exposes all browser storage. localStorage and sessionStorage values display as readable key-value pairs, and cookies list their attributes, including whether HttpOnly is set. HttpOnly blocks JavaScript access but not server-side inspection. Long-lived tokens stored here are especially risky since they persist beyond the page session.
Public Keys vs Secret Keys: What’s the Difference?
Public keys are designed for browser exposure; secret keys are not, and exposing one is critical.
| Key Type | Designed for Browser? | Risk If Exposed | Examples |
| Publishable Key | Yes | Low to Medium | Stripe publishable key, reCAPTCHA site key |
| Analytics ID | Yes | Low | Google Analytics ID, Segment write key |
| Read-Only API Key | Depends on scope | Medium | Weather API key |
| Full-Access API Key | No | High | Most general-purpose keys |
| Secret/Private Key | No | Critical | Stripe secret key, OpenAI API key |
| Admin Token | No | Critical | Cloud provider service keys |
Providers that explicitly designate a key as publishable, such as Stripe’s publishable key, scope it to safe operations like tokenising card data; it cannot charge cards or access account data.
Even public keys need restrictions: domain allowlisting, scope limits, usage quotas, and monitoring. Any credential capable of write operations, data deletion, or account administration belongs only on the server, in environment variables never compiled into client bundles.
Why Is an Exposed API Key a Security Risk?
OWASP’s API Security Top 10 identifies Broken Authentication and Unrestricted Resource Consumption as critical risks, both directly enabled by exposed credentials. A copied key can be reused by anyone who finds it, exhausting rate limits or generating significant unexpected charges; Google Cloud and AWS have documented cases of exposed keys producing thousands of dollars in charges within hours. Depending on permissions, an exposed key may also allow unauthorised reading of private data or unauthorised actions like sending communications or modifying records.
Restrictions such as referrer rules, IP allowlists, and rate limits reduce the blast radius of an exposed key, but they do not make it secret. The key remains visible to any user inspecting the page from an authorised domain. OWASP notes that transport-layer controls do not compensate for credential exposure at the application layer.
How Do You Find an Exposed API Key in DevTools?
Follow this five-step process in Chrome DevTools:
- Open DevTools with F12 or Cmd+Option+I, or right-click and select Inspect.
- Check the Network tab: reload the page, filter by XHR/Fetch, and inspect request headers and payloads for credentials.
- Search the Sources tab using Ctrl+Shift+F or Cmd+Option+F for terms like apiKey, Bearer, token, and secret.
- Inspect the Application tab: expand Local Storage, Session Storage, and Cookies, and check Cache Storage for cached credentials.
- Evaluate each key found by checking provider documentation to confirm whether it is publishable or secret, and remediate any secret key immediately.
How Do You Keep API Keys Out of DevTools?
The backend proxy pattern is OWASP’s recommended solution: the frontend calls your own server, your server authenticates with the third-party API using server-side environment variables, and the third-party key never reaches the browser. When a provider offers a publishable key for client-side use, use that key, not the secret key, and apply domain allowlisting and scope restrictions.
Never compile secrets into frontend bundles. Variables prefixed for client exposure, such as NEXT_PUBLIC_ in Next.js or VITE_ in Vite, are compiled into the JavaScript bundle and readable in DevTools. Secrets belong only in server-side environment variables excluded from the client build. Apply least privilege to every credential, public or private, restricting permissions to the minimum required, a principle drawn from the NIST Cybersecurity Framework.
What Should You Do If You Find an Exposed API Key?
Rotate the key immediately from the provider’s dashboard before making any other change; treat the exposed value as permanently compromised, since scanners like GitHub Secret Scanning or truffleHog may have already copied it. Review provider usage logs for the exposure period, checking for unexpected IP addresses, unusual volumes, or abnormal endpoint calls.
Audit every location the key may have spread to, including repository commit history, deployed JavaScript bundles, mobile builds, CI/CD logs, and internal documentation or screenshots. Finally, redesign the architecture rather than simply swapping in a new key: implement the backend proxy pattern, move the call server-side, restrict permissions, and add usage monitoring. OWASP’s API Security Best Practices documentation offers a reference checklist for this process.
What’s the Bottom Line on API Keys in DevTools?
Any API key that reaches the browser is visible and must be treated as public, since DevTools exposes the Network, Sources, and Application panels to anyone using that session. Public keys like Stripe’s publishable key are safe when properly scoped, but secret keys belong only on the server, protected through the backend proxy pattern. If a key is ever exposed, rotate it immediately, audit where it spread, and redesign the architecture so it cannot happen again.
Where Can You Find More Security Resources?
Digital Marketing Toolkit offers in-depth guides, tool comparisons, and best practices to help teams secure their APIs, manage credentials properly, and build reliable systems behind every marketing and product workflow. From authentication and key management to integration security, every resource is built for teams that treat security as a foundation, not an afterthought.
Frequently Asked Questions
1. Is an API a Tool?
Yes. An API allows software systems to communicate and share data, enabling developers to connect applications, access third-party services, and automate workflows without building functionality from scratch.
2. What are API testing tools?
API testing tools allow developers to send requests to an API endpoint and verify the response behaves as expected. Common options include Postman, Insomnia, SoapUI, Swagger UI, and cURL, each supporting different use cases from manual testing to automation.
3. What Is the Best Tool for API Testing?
There is no single best tool. Postman leads for manual and automated testing, REST Assured and Supertest suit code-first teams in Java and Node.js, k6 is the top choice for load testing, and Pact is the standard for microservices contract testing. Most teams use more than one tool across testing stages.
4. Can a crawler or automated tool find an exposed API key?
Yes. Tools like GitHub Secret Scanning and truffleHog actively scan repositories and deployed code for credential patterns, and a key briefly exposed publicly may already be indexed or copied.
5. Does minification or obfuscation protect an API key?
No. Minification reduces code size but does not encrypt values, and DevTools search can find a key string in a minified bundle in seconds.