An API key appeared in your website: is deleting it enough?

A variable name does not tell you its permissions

Suppose an AI-built landing page calls an email service from the browser. Its JavaScript contains a value named API_KEY. That name alone does not establish a vulnerability. Check the provider’s documentation: is this a public identifier, a restricted client key or a secret that can authorize actions? Do not try a credential from a site you do not own. This is an illustrative scenario, not a reported incident.

For your own service, ask the account owner to check the key type and permissions in the provider console. Record the affected bundle URL and discovery time without copying the full value into email, tickets or an AI chat. Screenshots used for discussion should hide the secret.

Remove access before cleaning every copy

For a confirmed exposed secret, arrange revocation or rotation with the owner promptly. GitHub’s guidance also puts this before repository-history cleanup. Rebuilding the page removes one delivery path; it does not stop someone using a copy downloaded earlier.

The replacement needs a safe home. Put secret-backed operations behind the server and store the replacement in an appropriate server-side secret store. Check that the build will not insert it into browser assets again. A value placed in an environment variable can still be bundled into public code. If the feature cannot operate safely during the change, agree on temporarily disabling it rather than issuing another exposed key.

No billing spike does not close the investigation

Examine available provider usage and audit records for the possible exposure period. Record what the key could do and what the logs actually show. A quiet bill is not evidence that no data was accessed, and missing logs are a limitation, not a clean result. Escalate to the service owner’s incident process if the evidence suggests unauthorized use.

Inventory copies your team controls: deployed bundles, CDN caches, repositories, build outputs and shared troubleshooting material. Coordinate any repository-history cleanup; a rewritten history can affect colleagues and does not erase someone else’s clone. Keep the incident record restricted and redacted.

What to verify after the change

Using your own authorized account, confirm that the old credential is revoked and the replacement has only the permissions needed. Check that the deployed browser assets no longer expose the secret, then verify the legitimate feature still works. Record the deployment identifier and the verification time. Do not run up third-party charges to demonstrate impact.

An external website check may identify a visible credential, but provider-log review, rotation, source review and incident response are separate work. Mingxi’s standard public check does not include those activities or certify that an exposed key was never used. Keep any unverified part visible in the handover.

Practical checklist

• Confirm the key type with its provider and owner.
• Revoke or rotate a confirmed exposed secret promptly.
• Review available logs and redact evidence.
• Check the new deployment and legitimate feature.

A common question

Must every key visible in JavaScript be removed?

No. Some services use public client keys by design. Follow that provider’s requirements for permissions and restrictions. A publishable identifier and a server secret must not be treated as interchangeable.