API keys: storage, access and a response to exposure

A website needs a key for payments, maps or email. Someone places it temporarily in a test file, which later reaches a public repository. Removing the visible line cannot revoke an already copied value or erase saved history.

Not every identifier is secret. Some providers offer restricted keys intended for public use. Verify that distinction in the provider’s documentation rather than inferring it from the word “key”.

Limit access to the intended task

The OWASP secrets-management guide treats storage, permissions and lifecycle together. Give a project only the capabilities and environments it needs. Separate testing from production access where supported.

Inventory the purpose, owner and replacement procedure without recording the secret value itself. Associate access with responsibilities. Reusing one unrestricted key across projects increases the potential impact of a single exposure.

Browser-delivered secrets cannot be hidden

People can inspect code and requests delivered to their browser. Renaming a file or minifying code does not protect a secret. Keep private credentials on the server and expose only the required, authorised operation.

Protect environment configuration too. Accidentally serving it publicly or logging complete values creates another exposure route. Review screenshots sent for support: repositories are not the only place a credential can leak.

Revoke the exposed credential

Identify the provider’s supported revocation and replacement process. Verify the required function using the new key, then independently confirm that the old credential no longer works. Deleting a file is not a complete response.

• Assess where and how long the key was accessible.
• Replace access through the provider’s procedure.
• Confirm the old credential is invalid.
• Test dependent website functions.
• Investigate possible use and the cause of exposure.

A named owner and documented recovery route make incident decisions easier. Include them in website maintenance. Protection depends on controlled access and the ability to change it, rather than one supposedly hidden file.