Use the issuer’s documented credential type and effective privileges to classify exposure, then revoke any privileged secret and repair its server-side boundary.
A value called an API key is not automatically a secret, and a value deliberately visible in a browser is not automatically safe. Classify it using the issuing service’s current documentation and its actual authority. Some identifiers are designed for public clients; privileged credentials that authorize server actions must not be shipped in public website code.
Do not paste the value into chat, a public issue, a scanner website or a screenshot to ask which type it is. Record the service, non-secret credential type, environment and relevant permissions through an authorized private process. If classification is uncertain and exposure could grant privileged access, contain it through the issuer’s incident procedure.
Identify the issuer and credential type
Start with the code’s maintained integration and the account that issued the value. Find the official documentation for that exact credential class. A familiar prefix can help locate the type, but it should not be the sole basis of a security decision, especially if a provider has changed its formats.
Ask what possession enables: identifying an application, requesting a public resource, consuming billable quota, reading private records, changing data or administering an account. Note additional controls such as user authentication, per-object authorization and provider-supported usage restrictions.
OAuth’s framework explicitly says a client identifier is not a secret and must not be used alone for client authentication. That is a specific protocol fact. It does not classify arbitrary API keys, and it does not make every value described as a client key harmless.
| Documented role | Browser placement question | Required companion control |
|---|---|---|
| Public application identifier | Is exposure intended by the issuer? | Do not treat identification as authorization |
| Restricted public client key | What usage and billing exposure remains? | Supported restrictions, quotas and monitoring |
| User access token | Which client/session design is supported? | Proper scope, lifetime and secure handling |
| Privileged server credential | Why was it delivered to a browser? | Revocation and a reviewed server boundary |
| Unknown value | Who can confirm its type privately? | Contain possible privileged exposure while investigating |
A fictional map identifier and publishing secret
A fictional publisher finds two values in a frontend bundle. The map provider documents the first as a browser key with permitted usage restrictions. The publishing service documents the second as a credential able to create and publish private-account content.
The map value is reviewed against its provider’s required restrictions and quota model. Its visibility alone is not reported as a privileged-secret leak. The publishing credential is treated as exposed: the authorized owner revokes it, investigates its possible use and moves the integration to a properly authenticated server-side operation.
Deleting the bundle reference is only one part of that repair. Old deployments, caches and downloaded copies may still contain the value. A replacement secret inserted into the same public bundle would repeat the flaw. This example is fictional and does not identify any real leaked credential.
Follow the value to what the browser receives
Inspect the actual built asset, rendered configuration and relevant browser requests in an authorized environment. A variable stored in an environment file can still be embedded into frontend output by a build tool. The label environment variable does not establish a server-only boundary.
Check source maps, inline scripts, public JSON, static exports and error messages. The public source-map guide covers one disclosure route. Removing source maps cannot protect a secret that remains in executable JavaScript, a request URL or another publicly delivered asset.
Do not copy every value into a report. Identify the file or response location and the credential class, with appropriate redaction. Keep evidence of exposure privately under the organization’s retention and incident rules.
Contain a privileged exposure at the issuer
OWASP’s secrets guidance distinguishes revocation from application restart. An exposed credential remains usable until the backing service expires or revokes it. Removing a source file, rebuilding or restarting an application does not independently invalidate the credential.
Use the service’s supported revocation and replacement process under the authorized account owner. Determine which other integrations use that credential and coordinate legitimate continuity, while prioritizing containment for active compromise. A routine overlap strategy may be inappropriate for a key already known to be exposed.
Review activity through the issuer’s available audit evidence and the credential’s effective permissions. Do not claim no misuse occurred simply because a dashboard looks quiet. Record the time range and logging limitations, then inspect changes the credential could authorize.
For an affected WordPress integration, the application-password guide explains the separate credential and user-capability boundary. Revoke the specific credential through supported controls; do not publish its authorization header as proof.
A server endpoint must enforce its own authority
Moving a secret to a server is necessary for many integrations, but not sufficient. A public endpoint that accepts arbitrary actions and forwards them with a privileged credential can expose equivalent authority indirectly. Define the permitted caller, action, target resource and rate limits.
OWASP cautions against relying exclusively on API keys for sensitive resources. Authenticate users where required and authorize each operation. Validate inputs and keep the privileged provider destination controlled by the application.
Return only the data the caller may receive. Do not forward private upstream errors or secret-bearing headers into the browser. If a task needs a limited temporary credential, use the issuer’s supported scope and lifetime rather than inventing a browser copy of the server secret.
Public keys still need an abuse model
A documented public client key can identify your application for quotas or billing. Read the provider’s supported restrictions and residual risks. Domain/referrer restrictions, when offered, are not a replacement for protecting private data at the server. Do not assume a familiar website origin proves a specific user’s entitlement.
Review third-party code that receives the key or can call your endpoint. The third-party script audit helps map that dependency. A public identifier may be intentionally visible while the surrounding integration still sends unnecessary private data.
Verify the repaired boundary
- Confirm the exact credential class and documented exposure model.
- Revoke privileged exposed credentials through the issuer and record safe metadata.
- Verify frontend assets and error paths contain no replacement secrets.
- Check the server operation permits authorized tasks and refuses unauthorized ones in staging.
- Review quotas, restrictions and relevant activity evidence with the owner.
- Record any unexamined old deployment or cache route.
Your next step is a credential inventory organized by authority, issuer, environment and owner. Keep values outside that inventory. The useful outcome is a documented public/client boundary and a revocable server-secret lifecycle, not a promise that hiding a string makes an API secure.
Sources and verification
Editorial review 2026-10-17. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- RFC6749: OAuth2 authorization frameworkChecked A client identifier is not a secret and is insufficient for client authentication.
Limits: This does not classify arbitrary provider API keys; current OAuth security guidance also applies. - OWASP: Secrets ManagementChecked Secret lifecycle, rotation and revocation.
Limits: A restart or removing a file does not revoke an exposed credential. - OWASP: REST SecurityChecked Access checks, API-key limitations and server-enforced workflow transitions.
Limits: No assertion that a live API implements these recommendations.