Secrets management for web applications

What it means

A secret is a value whose disclosure can grant someone authority, such as access to an application service. Its protection depends on where the value becomes available and who can use it—not on whether its variable name sounds private. Browser-delivered code is an output boundary: a value embedded there is available to recipients of that code. Keeping a value on the server avoids that particular route, but does not settle access, logging or lifecycle questions.

Try it

Simulation: use only the supplied synthetic selections—no real credentials are needed or accepted. Start with Secret location = public client bundle and Leaked key has been revoked? = no. Then change only Secret location to server env and inspect the changed result and explanation. Select Compare with baseline to display both outcome labels. This changes only a local example; it does not move, revoke or inspect a credential.

The baseline result is “STOP: likely secret exposure.” Its explanation is “Client or repository exposure requires authorized containment, investigation and credential revocation.” The public client placement supplies an exposure path, while the no selection supplies no revocation assumption. This is a synthetic warning, not an observed incident. For a real suspected exposure, keep secrets out of shared evidence and involve the authorized incident owner before making changes.

Keep Leaked key has been revoked? = no while changing Secret location from public client bundle to server env. The comparison isolates placement; it does not model incident history or a completed migration.

Reset restores Secret location = public client bundle and Leaked key has been revoked? = no, clears input errors, and removes the comparison. It preserves your independent choices to open or close FAQ answers and About this model.

How it works

A credential can grant authority because a service accepts it, not because of the file or variable that contains it. If a build embeds a valid secret in a public client bundle, recipients can obtain that value. The intermediate condition is therefore not merely “the application uses a secret”; it is “the secret has crossed into output available to recipients.” Server-only placement can avoid that route, provided the value actually stays on the server. Runtime access and logging remain separate concerns.

Placement and containment answer different questions. Correcting a build can prevent the same value from appearing in future output, but it does not withdraw copies already obtained. Revocation changes whether the issuing service accepts the old credential. Rotation also requires a verified transition for legitimate consumers; merely replacing text in one configuration is not proof that the exposed credential has lost its authority.

For a second synthetic case, select Secret location = source control and Leaked key has been revoked? = yes. The result is “Exposure may be contained, verification needed,” with the explanation “Revocation must be confirmed across all consumers; removing one copy is insufficient.” The yes selection changes the model's containment assumption; it does not perform revocation or verify it. In practice, you need evidence that the issuer no longer accepts the old credential and that affected legitimate consumers use the intended replacement.

Worked example

This is a synthetic baseline, not a captured production observation.

The result is “STOP: likely secret exposure.” The explanation is “Client or repository exposure requires authorized containment, investigation and credential revocation.”

The location makes the credential available through client output in this example. With revocation set to no, the model has no basis for treating its continuing authority as contained. The relevant next task in a real incident would be authorized containment—not merely hiding the variable name or deleting the visible string.

What changes when the condition changes

Change only Secret location to server env. Keep Leaked key has been revoked? = no.

The result becomes “No immediate client exposure indicated.” The explanation is: “Server-only environment variables may be appropriate with least privilege, but server logs and access still matter.”

The changed assumption removes the browser-delivered copy from the modeled placement, so the model no longer signals that particular exposure path. This is a different synthetic situation, not a demonstration that moving an already leaked key makes it safe. The server env branch takes precedence regardless of the revocation answer; it does not evaluate earlier public copies or prove that the credential is protected.

In practice

Use this checklist only for applications and credentials you are authorized to administer. Exact revocation and deployment steps depend on the credential issuer and hosting platform; this page supplies no provider-specific commands. Keep real secrets out of this page, screenshots and shared issue reports.

1. Establish the environment and authority. Identify the credential issuer, application, repository, build or deployment, affected environment, and incident owner. Confirm who may inspect evidence, revoke credentials and change deployments. STOP if the target or your authority is uncertain; route the incident to the responsible owner rather than trying credentials or changing access speculatively.
2. Perform a read-only preflight. Within that scope, review approved configuration, output and access evidence without publishing or copying secret values into new locations. Determine whether the value remained server-only, entered a client bundle, or appeared in source control. Identify its granted permissions and legitimate consumers. If the evidence is incomplete, record what is unknown; a server-side setting alone cannot rule out an earlier leak.
3. Define the minimal change and recovery plan. Record the affected configuration and deployment identifiers in the restricted incident record. Identify exactly which credential will be revoked or rotated, which consumers need an update, and how application service can be recovered without restoring the compromised credential. Preserve relevant evidence before speculative cleanup. If you cannot identify the credential or its consumers reliably, STOP the speculative change and escalate for authorized containment.
4. Contain through the approved incident procedure. The authorized owner should revoke or rotate the exposed credential and update legitimate consumers as required by the issuer's procedure. Do not delay authorized containment to finish repository cleanup. Separately correct the placement or build configuration that exposed the value; deleting one copy does not invalidate other copies.
5. Verify both security and application behavior. Use approved issuer evidence or authorized verification tooling to confirm that the old credential no longer grants access. Verify that legitimate consumers work with the intended credential and that the affected build or deployment no longer publishes it. A successful application request alone does not establish revocation, and a clean current file does not establish that historical copies are gone.

If the change disrupts legitimate consumers, follow the approved recovery plan. Roll back application or configuration changes only to a state that uses a noncompromised credential, then verify application behavior and containment again. Do not reactivate the exposed credential as a convenience rollback. If safe recovery is uncertain, stop speculative changes and escalate.

Limits and unknowns

No real secrets, credentials or deployment environment are accessed. The simulation does not inspect a client bundle, repository, log, credential issuer or running application. Its messages apply only to the selected synthetic conditions.

The model treats source control as an exposure path without examining repository visibility, access history or surviving copies. For public client bundle and source control, the revocation selection changes the containment branch. For server env, the placement branch takes precedence and the revocation selection does not affect the result. Neither branch establishes whether a real credential was previously disclosed or whether containment succeeded.

If placement, access history or revocation cannot be established from authorized evidence, the real-world conclusion remains unknown. Collect that missing evidence rather than choosing a reassuring answer. The model has no “containment verified” result.

If input is invalid, the previous calculated outcome is removed; correct the selection or use Reset before interpreting a result. Without JavaScript, the initial example and explanation remain readable, but the controls do not operate.

What to carry forward

Make two separate decisions: where future builds and deployments may obtain a secret, and whether an already exposed credential still grants authority. A server-only placement can address the first question without resolving the second. Close an exposure incident only on authorized evidence of containment and working legitimate consumers—not on a cleaner repository or a favorable simulation result.