Yes. Any API key sent to, stored by, or bundled into client-side JavaScript is visible through Chrome, Edge, or Firefox DevTools. OWASP and CWE-321 classify exposed client-side credentials as a top security risk, and once a key reaches the browser, it must be treated as public regardless of minification or obfuscation. This guide covers where…
Kewyn Appadoo is a software engineer, digital growth strategist, and award-winning marketing expert with over 15 years of experience at the intersection of tech, AI, and performance marketing.
A two-time ClickFunnels award winner — including the prestigious Two Comma Club X for generating over $10 million in revenue. He brings a rare blend of software engineering, AI automation, and conversion-focused strategy.
At Digital Marketing Toolkit, Kewyn shares practical insights on how marketers can leverage AI tools to scale smarter, build faster, and convert better.
Table of content
Yes. Any API key sent to, stored by, or bundled into client-side JavaScript is visible through Chrome, Edge, or Firefox DevTools. OWASP and CWE-321 classify exposed client-side credentials as a top security risk, and once a key reaches the browser, it must be treated as public regardless of minification or obfuscation. This guide covers where keys appear in DevTools, public versus secret keys, why exposure is risky, and how to keep credentials off the client.
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
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.
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.
