Anything you send to the browser is public. Yet API keys, cloud tokens and private credentials regularly end up in JavaScript bundles, HTML comments and configuration endpoints.

How it happens

A developer adds a key to get a feature working, or a build tool bundles an environment file into the front end. Attackers download your JavaScript and search it for key patterns, which takes seconds.

Why it matters

• Abuse of paid third-party services billed to you.
• Access to cloud storage, email or payment APIs.
• Data exposure through keys with too many permissions.

How to prevent it

• Keep secrets on the server; have the front end call your own back end instead.
• Use keys that are restricted by domain and permission when a public key is unavoidable.
• Scan builds for secrets before deployment.
• Rotate any key that has been exposed.

How Vooki Pro helps

• Detects API keys and hard-coded credentials in responses and JavaScript.
• Flags personal data (PII) in responses.
• ThreatLens, running on your own machine, adds AI-assisted detection of exposed secrets. Your scan data is never sent to a third party.
• Every finding includes the exact location of the exposed value.

Frequently asked questions

Is it safe to put an API key in JavaScript?

Only if the key is designed to be public and restricted by domain and permissions. Anything sent to the browser can be read by anyone.

What should I do if a key was exposed?

Revoke and rotate it immediately, then move the call behind your own server.

Related: Preventing information disclosure: .git, .env, backups and source maps · Protecting against clickjacking