Secrets are values that must remain confidential because their disclosure could enable access, impersonation, decryption, or another protected action. Passwords, private keys, session tokens, and many API keys belong in this category.
Configuration tells a system how to operate. Some configuration is public or low-sensitivity, such as a website address or display preference. Other configuration contains credentials that allow a script, plugin, or connector to act. Putting both in the same settings file does not make them equally safe to share.
Protecting secrets means more than keeping them out of view. It means controlling where they are stored, which systems receive them, what capabilities they grant, how long they remain valid, and how access can be withdrawn.
Quick navigation
Identifiers, credentials, and secrets are related, but different
An identifier names an account, application, project, or resource. A credential provides evidence used to authenticate a person or system. A secret is information whose confidentiality matters to security.
These categories overlap without being interchangeable. A username identifies an account but usually is not a secret. A password is secret credential material. A public key may be shared, while its corresponding private key must be protected.
- Account or project ID: usually identifies something; it should not, by itself, authorize access. It may still carry privacy or business sensitivity.
- Password: secret material used to authenticate an account.
- API key: depending on the service, may identify a project, authorize requests, associate usage with a billing account, or serve several purposes.
- Access token: commonly grants access to specified resources or actions for a limited period.
- Refresh token: may allow a client to obtain new access tokens, making its protection important even when individual access tokens expire quickly.
- Session token: maintains authenticated continuity between requests. Theft may allow impersonation without revealing the account password.
- Private cryptographic key: may enable signing, authentication, or decryption, depending on its purpose.
Names alone do not establish sensitivity. A value called a “client ID” is often public; a “client secret” is not. Some services deliberately provide publishable keys for browser use. Those keys are not substitutes for server-side authorization and may still require usage restrictions.
Read the provider’s documentation to determine what possession of a particular value enables. The distinction between authentication, authorization, and session continuity helps explain why different credentials require different handling.
When configuration crosses a security boundary
A configuration file can contain harmless preferences alongside a powerful credential. The file must then be handled according to the sensitive material it contains—not according to its filename.
Consider a publishing script with three settings:
- The destination website address
- The default content status, such as draft
- A credential that authenticates requests to the website
The address and draft preference may be suitable for documentation. The credential is not. If the script needs only to create drafts, the credential should not grant broader administrative access merely because that is convenient.
Also distinguish a workflow preference from an enforced restriction. Setting default_status=draft does not prevent publication if the account and API still permit it.
Browser-delivered configuration is visible to the visitor
A secret embedded in HTML, downloadable JavaScript, a mobile application package, or a browser-visible request should not be treated as confidential from the person receiving it. Minification, an obscure variable name, or a hidden interface field does not change that boundary.
Build tools can also copy environment variables into public frontend bundles. A value that began in a private build environment may become public during compilation.
Credentials that must remain secret generally belong on a trusted server or another appropriately controlled execution environment. The browser can request a bounded action from that server, but the server must authenticate and authorize the request. Moving a key behind an unrestricted public endpoint merely changes how its capabilities can be misused.
Store secrets according to what the system needs to do
There is no single storage method suitable for every secret. The first question is whether the system needs to verify a value, retrieve it, or use a cryptographic operation without exposing the underlying key.
Passwords used for sign-in should normally be hashed
A website that verifies users’ passwords generally should not store recoverable copies. Established authentication systems use salted, purpose-built password hashing methods, such as Argon2id, with appropriate parameters.
Hashing allows a system to check a submitted password without retaining the original password in readable form. A fast general-purpose hash alone is not an adequate password-storage design. Website owners should rely on maintained authentication implementations rather than create their own password-handling scheme.
Credentials used to contact another service may need to be retrieved
A script calling an external API may need the actual credential. Hashing it would prevent that use. Suitable storage might include an operating system credential store, a managed secret service, or protected runtime configuration, depending on the environment.
A dedicated secret manager can centralize access policies, auditing, and lifecycle management. It does not remove the need to secure the application that receives the secret or the identity allowed to retrieve it.
Environment variables are a delivery mechanism, not a complete security system
Environment variables can keep credentials out of application source code, but they do not automatically secure those credentials. Values may appear in diagnostic output, crash reports, deployment settings, or process inspection available to sufficiently privileged users.
A local .env file is commonly plaintext. Its protection depends on file permissions, device security, backup behavior, synchronization settings, and whether the file can be served by the web server.
For a small local tool, a restricted configuration file outside the web-accessible directory may be a proportionate choice. For shared or production systems, centrally managed access and short-lived credentials may provide stronger control. The storage decision should match the threats, vulnerabilities, risks, and controls relevant to that system.
What common protections do—and do not—establish
Encoding is not encryption
Base64 and similar encodings change how data is represented. They do not keep it confidential. Anyone who receives an encoded credential can usually decode it without a key.
Encryption protects confidentiality through cryptographic keys. Its effectiveness depends on the method, implementation, and key management. An encrypted credential stored beside an unrestricted decryption key may offer little protection against someone who can read both.
HTTPS protects transport, not every copy of a secret
HTTPS protects data in transit between the endpoints of the encrypted connection. It does not prevent an authorized receiving service from logging a credential, a compromised application from reading it, or a developer from copying it into a support ticket.
Avoid placing secret credentials in URLs unless a protocol specifically requires a carefully controlled mechanism. URLs can be retained in browser history, server logs, analytics, and other records. Use the service’s documented authentication mechanism, commonly an authorization header, and ensure logging does not capture sensitive headers or request bodies.
Repository exclusion is not secret management
A .gitignore rule can help keep an untracked local file out of future commits. It does not remove a file already tracked by Git, erase repository history, revoke a credential, or protect copies elsewhere.
A private repository also is not a substitute for a secret store. Repository access, integrations, forks, build jobs, and downloaded copies can extend the credential’s exposure beyond the application that needs it.
Secret scanning is a useful additional control, but scanners cannot recognize every sensitive value. A clean scan is evidence about that check, not proof that no secrets are present.
Masking a value does not establish secure storage
A settings screen that displays dots instead of a token protects against casual viewing. It does not establish whether the token is encrypted, who can retrieve it, or whether it appears in logs and exports.
Each protection supports a bounded conclusion. That is the purpose of verification scope: stating what was checked without extending the result beyond the evidence.
Limit what a credential can do, where it works, and how long it lasts
Confidentiality is only one part of credential protection. A narrowly scoped credential reduces the consequences of theft or accidental use.
- Separate tasks: use different credentials for unrelated integrations where practical.
- Separate environments: do not give development tools production credentials by default.
- Restrict actions: prefer read-only access when writing is unnecessary, and resource-specific access when broad access is unnecessary.
- Limit duration: use short-lived credentials or temporary grants where supported.
- Use dedicated identities: give automated tools their own service identity rather than a person’s everyday administrator credentials.
- Apply supported restrictions: network, application, or resource restrictions can add protection, although they should not be mistaken for complete authorization.
A credential’s technical capabilities may exceed the task someone has approved. Possession of a key does not independently establish organizational permission to use every capability it exposes. Access, capability, permission, authority, and responsibility remain different things.
This matters when configuring connectors and AI-assisted workflows. Credentials should ordinarily remain in the controlled integration layer, not in prompts, retrieved documents, generated articles, or model-visible tool output. Human approval requirements should be enforced through workflow and application controls, not left solely to an instruction beside an overprivileged credential.
Rotation, expiration, and revocation do different work
Rotation moves a system from an existing credential to a new one through a managed transition. Expiration ends validity at a specified time. Revocation deliberately withdraws validity or access.
Generating a new API key is not a completed rotation if the old key remains active indefinitely.
A routine rotation commonly involves:
- Identifying the applications and jobs using the credential.
- Creating or obtaining its replacement with the necessary scope.
- Updating authorized consumers through the approved storage and deployment path.
- Verifying that the new credential works.
- Revoking the old credential and confirming that it is no longer accepted.
Some providers support a short overlap period to avoid service interruption. Suspected compromise changes that balance: leaving a known exposed credential active for a convenient transition may prolong unauthorized access.
Revocation behavior also varies. Disabling a refresh token may not immediately invalidate every access token previously issued from it. Changing a password may not end existing sessions. Check the service’s documented behavior rather than assuming that one credential change closes every related path.
Rotation policy should reflect credential type and risk. Routine infrastructure credential rotation is not the same as forcing people to change uncompromised account passwords on an arbitrary schedule.
What to do when a secret may have been exposed
If a working credential appears in a public repository, shared conversation, screenshot, log, or unintended recipient’s hands, removing the visible copy is not enough. Other copies may remain.
- Identify the affected access. Determine the service, account, permissions, environment, and credential validity.
- Contain the exposure. Revoke or disable the credential promptly, coordinating essential service continuity where necessary. Do not delay containment solely to prove misuse.
- Replace it through a safer path. Update legitimate consumers without repeating the exposure.
- Review related access. Check whether sessions, issued tokens, connected applications, or other credentials also require action.
- Examine available evidence. Review relevant access, usage, and billing records. Missing or quiet logs do not establish that no misuse occurred.
- Address retained copies and the cause. Clean up repositories, artifacts, logs, and shared materials where appropriate, while preserving necessary incident evidence securely.
An exposed credential does not automatically prove complete system compromise. It does establish a reason to reassess the affected access and investigate within a clear scope. Serious incidents may require the service provider, an incident-response specialist, or the organization’s security and privacy leads.
A practical secret-handling checklist
For each website integration, local script, or publishing adapter, ask:
- Which values are identifiers, and which enable protected actions?
- Where does each secret originate, and where are its copies stored?
- Can it enter browser-delivered code, logs, screenshots, backups, prompts, or generated files?
- Who or what can retrieve it?
- Does its access match the actual task and environment?
- Who is responsible for maintaining and revoking it?
- Can it be replaced without losing track of dependent systems?
- Do we know how to confirm that the old credential has stopped working?
A credential inventory can record purpose, owner, scope, storage location, and lifecycle information without containing the secret values themselves. Documentation and example configuration should use clearly nonfunctional placeholders.
Good secret handling keeps sensitive values within deliberate boundaries, limits the access they provide, and leaves a workable path for withdrawal and recovery. It is one continuing responsibility within building and maintaining secure websites—not a property established once by hiding a password field or excluding a file from Git.