Skip to content

Web security

Exposed secrets: validate, contain, and remediate

Handle suspected keys and credentials in public files without leaking them further, distinguish public identifiers, and plan safe rotation and verification.

By BugSnaps · Updated

Direct answer

An exposed secret is sensitive credential material available outside its intended trust boundary. Assess where it was disclosed, what access it could authorize, and whether it remains active. Minimize handling, notify the owner, and rotate or revoke through the proper provider controls.

Classify the value before escalating

A public client identifier, a sample placeholder, and a private API credential require different treatment. Record the file, deployment, and surrounding configuration that suggest the value's purpose. Do not assume a string is a working secret because it resembles a key format.

  • Save a redacted fingerprint rather than the full credential.
  • Identify whether the file is public, private, or intentionally distributed.
  • Ask the owner to map the value to its provider and permissions.

Validate with the smallest approved check

Prefer owner-assisted provider inspection to using the credential against production data. If active verification is approved, limit it to a read-only capability check designed for that provider. Never place a found secret in a public issue, browser URL, or analytics event.

  • Keep the credential out of report screenshots and request logs.
  • Record the approved verification method and its result.
  • Stop if validation could access another party's data.

Rotate the credential and remove disclosure

Deleting a visible file does not revoke a credential already copied. Coordinate replacement and revocation, update dependent services, and remove the exposed material from the current distribution. Rotation needs verification because an incomplete change can interrupt legitimate integrations.

Reference: OWASP Secrets Management Cheat Sheet.

Check the full distribution path

Recheck public assets, build artifacts, source maps, downloaded reports, and caches involved in the original exposure. Use the redacted fingerprint to track locations. Confirm the application works with the replacement and that the old secret's permissions are no longer usable.

Assessment limits

A format match is a candidate, not proof of active credentials. Provider-specific permission and revocation behavior varies. Removing source text cannot erase copies already downloaded, so the response must include the credential's lifecycle.

Frequently asked questions

Is a public API key always a secret?

No. Some identifiers are designed for browser distribution. Evaluate the provider's model, restrictions, permissions, and other controls before labeling the exposure.

Does deleting the file solve a credential leak?

It removes one disclosure path but does not invalidate previously copied credentials. Review revocation or rotation and verify dependent services afterward.

Should a report include the full secret as proof?

Use redacted evidence and a fingerprint sufficient for the owner to identify it. Share sensitive material only through the agreed protected process when necessary.

Primary sources and further reading

These guides combine published security guidance with practical assessment planning. Adapt checks to the owner's policy, environment, and authorized scope.

Apply the guide to your own application.

Start with an authorized target, known test data, and a clear scope. Use the report's evidence and coverage limits to decide which checks need further review.

Open MyPentest