Malinois
Security guides
Malinois Field Guide

Prevent API key leaks in web apps

Anything sent to a browser can be read by the person using it. Environment-variable names such as “public” or build-tool prefixes do not make a credential safe; they usually mean the value will be included in client code.

Classify every credential by where it may run

Public identifiers can be exposed only when the provider designed them for that purpose and enforces restrictions. Secret credentials belong in a trusted server, edge function, or provider-side integration.

The correct question is not whether a key looks obscure. Ask what the key can do, where it is delivered, which resources it can reach, how it is restricted, and how quickly it can be revoked.

Leak-prevention workflow

  1. Inventory credentials

    List API keys, database credentials, signing secrets, webhook secrets, and service tokens. Record owner, purpose, environment, permissions, and rotation path.

  2. Move secret calls server-side

    Have the browser call your controlled endpoint. The server validates the user and input, calls the provider with the secret, and returns only the necessary result.

  3. Constrain public keys

    For keys explicitly designed for browsers, restrict allowed origins, APIs, quotas, and environments in the provider dashboard. Never rely on an origin restriction as authorization for private data.

  4. Keep secrets out of source

    Use secret storage supplied by the hosting platform. Exclude local environment files, review staged changes, and scan repository history as well as the latest commit.

  5. Protect logs and URLs

    Do not place credentials in query strings, analytics events, client errors, screenshots, support messages, or build output. Redact sensitive values before logging.

  6. Rotate suspected exposure

    Revoke or rotate the credential first; deleting it from the current file is not enough. Review provider activity, update dependent services, and verify the old value no longer works.

  7. Inspect the deployed bundle

    Search the final public HTML and JavaScript for provider key patterns and known credential names. Repeat after every build-system or environment change.

Signs that need immediate review

  • A secret appears in browser developer tools, page source, or a downloaded bundle.
  • A client application connects directly with a service-role or admin credential.
  • Repository history contains a value that was later deleted.
  • A key has broad permissions, no usage boundary, or no documented owner.

Treat exposure as a credential event

Do not spend time proving that nobody copied an exposed secret before rotating it. Contain access, review activity, correct the architecture, and then verify both the repository and deployed app.

Check the deployed app, not just the checklist

With the owner’s authorization, Malinois reviews public responses for exposed files, secrets, database access signals, and missing security headers.

Run a free passive scan

Passive external review only. No exploitation or penetration testing.

Continue the review

AI app security checklist

A launch-to-maintenance workflow covering access, data, dependencies, recovery, and verification.

Read guide →

Security headers checklist

Understand the browser protections each response header adds and verify them without guesswork.

Read guide →