Treat client-side credentials as exposed

Browser code is delivered to the user. Lovable's current security documentation explicitly states that API keys and other secrets cannot be stored safely in generated frontend code and directs sensitive calls through server-side functions and secret storage.

Apply the same boundary to any web application. A value is not protected by an obscure variable name, minification, a hidden UI control, or a request made immediately after page load.

Check these locations without copying the value:

  • source files and repository history;
  • generated browser bundles and source maps;
  • local environment files and shared configuration;
  • CI/CD variables, workflow definitions, and build output;
  • provider secret stores and runtime configuration;
  • screenshots, tickets, prompts, logs, and exported diagnostics; and
  • developer machines or scripts that may retain an old copy.

Record a neutral label, such as billing-api-test, plus each authorized reference and owner.

Contain first, then choose the replacement path

Reduce access or disable the affected function when it can be done safely. Notify the accountable owner and use the provider's current incident and revocation procedure. A known exposed production credential is an incident, not a documentation exercise.

OWASP describes creation, rotation, revocation, and expiration as parts of a secret lifecycle and recommends minimum privileges. For the selected credential, record:

  • owning provider and accountable human;
  • intended service, environment, and action;
  • effective scope and expiration;
  • every consumer that must receive the replacement;
  • provider-side replace or revoke order; and
  • recovery plan if a consumer cannot switch safely.

Use a deliberately fake or approved test credential for rehearsal.

Replace both sides of the trust relationship

A client or server configuration change does not rotate a provider credential by itself. A safe sequence usually needs an overlap or outage decision:

  1. create or designate the replacement at the owning provider;
  2. apply the smallest required scope;
  3. deliver it through the approved runtime secret mechanism;
  4. verify one bounded action with the replacement;
  5. revoke or disable the old test value; and
  6. verify that the old value is rejected.

The exact order depends on whether the provider supports overlapping values, versioned secrets, immediate revocation, or only one active credential. Follow that provider's current procedure rather than copying a generic command.

Keep secret delivery out of source and browser output

Move privileged API calls to a trusted server boundary. Give the runtime identity or secret only the permissions required by that action and environment. Separate development, preview, and production values.

Review build arguments, static configuration, error pages, and diagnostic endpoints. A server-side secret can still leak if it is serialized into an HTML response, returned in an API error, or embedded during a frontend build.

If GitHub Actions is in scope, GitHub's current secure-use guidance warns that automatic redaction is not guaranteed. Register sensitive derived values where supported, avoid structured blobs as one secret, and treat an unredacted log as exposure requiring log deletion and rotation.

Verify without revealing the value

Use outcomes and identifiers, not the credential itself:

Check Safe evidence Expected result
Authorized references inventoried Paths or secret names Complete
Client bundle and source checked Scan result and revision Value absent
Logging checked Redacted event or test assertion No value present
Replacement configured Provider event ID or timestamp New active
Bounded function tested Status and correlation ID Success
Old test value retried Status only Rejected

Also test a client-only replacement before provider rotation in the synthetic fixture. It should fail; otherwise the exercise may not model the actual trust boundary.

Decide the recovery boundary

Record what happens if replacement breaks a dependent service. The response may be to restore a prior configuration temporarily, issue another credential, disable the function, or contact the provider. Never reactivate a credential known to be compromised merely to recover availability.

Check scheduled jobs, webhook consumers, CI workflows, and rarely used administrative paths. A successful primary request does not prove every consumer moved.

Evidence boundary for this draft

The accompanying local model ran six tests on August 4, 2026 using deliberately fake values. It showed a bounded action, absence from public configuration, a value-free audit record, coordinated replacement, old-value rejection, and failure when only the client side changed.

No provider account, browser bundle, repository history, CI workflow, log system, or real credential was exercised. This review version reports only the fake local results; a security-conscious owner must complete the provider worksheet before claiming a real credential was contained or replaced.

Verification checklist

  • Credential label, provider, owner, purpose, environment, and scope exist.
  • Every authorized reference is listed without the value.
  • Source, history, client output, build output, and logs were reviewed.
  • Provider-side replacement or revocation followed current documentation.
  • The replacement works only at the intended scope.
  • The old test value is rejected.
  • Dependent consumers and recovery were checked.
  • A production exposure was handled as an incident.

Frequently asked questions

Is moving an API key to an environment variable enough?

Only if the variable is delivered to a trusted runtime, omitted from browser output and build artifacts, scoped appropriately, auditable, and replaceable. Frontend build variables are often public after compilation.

Should I rotate a key before finding every consumer?

Contain urgent risk first. Then use the provider's incident procedure and an accountable owner to balance revocation speed against known dependencies. Do not delay a necessary production revocation for a documentation exercise.

Can log redaction prove a secret never leaked?

No. Redaction can fail and may cover only registered values. Test safe logging, limit collected data, inspect relevant history, and rotate when exposure is known or credible.