API Keys and Secrets: The Mistakes That Expose a Small Business Site Without Anyone Noticing

A site that uses a CRM, a payment service, a mapping API, or an email sending tool almost always handles access keys, also called secrets, which let these external services identify and authorize requests sent from the site. These keys work like passwords, with one important difference: they are often copied, shared, and embedded in code without anyone questioning their actual level of protection.

The most common mistake: the key hardcoded in the code

On a custom PHP build, it remains common to find an API key written directly into a configuration file versioned along with the rest of the source code. The problem arises as soon as that code is shared, whether through a private Git repository accessible to an external provider, an export to a new developer, or worse, a repository that accidentally becomes public. Once a key has circulated through a version history, removing it from the current code is not enough: it remains readable in previous versions until it has been revoked and replaced with a new one.

The basic good practice: environment variables

The standard solution is to take keys out of the source code and store them in environment variables, usually through a file named .env, which is never included in the code repository thanks to a .gitignore file that explicitly excludes it. The application code then reads the key from this variable at runtime, never writing it in plain text into a file tracked by version control. This approach remains appropriate for local development or a modestly sized site, provided this file is never sent by email or instant messaging, channels that leave traces difficult to fully erase.

What this file does not protect against

A .env file correctly excluded from the code repository still remains present in plain text on the production server, which means unauthorized access to the server, for instance through a flaw in a WordPress plugin or a compromised FTP password, directly exposes every key it contains. For a site with higher security requirements, particularly when several people or providers work on the infrastructure, a dedicated secrets manager, such as those offered by major cloud providers, allows encrypted storage with fine grained control over who can view which key, going beyond what a simple local file can offer.

The frontend trap and browser visible code

A key embedded in JavaScript code running in the browser, even in a compiled or minified file, remains technically accessible to anyone inspecting the page's source code. This is a common mistake when a third party integration is added quickly without routing the request through the site's own server. The solution is to route these calls through a server side entry point, which keeps the key secret and only sends the browser the necessary result, never the key itself.

Restricting each key to its strict use

Most services let you limit an API key to a specific domain, a range of IP addresses, or a set of authorized actions, a feature often ignored for simplicity when the key is created. This restriction costs nothing to set up and greatly reduces the impact of a potential leak, since a key limited to nikaia.net cannot be reused from another domain even if it is discovered.

Rotating keys, not just protecting them

A key created at a project's launch and never renewed since remains a risk that accumulates over time, particularly when several providers or employees have had access to it over the years without the list of relevant people being kept up to date. Periodic rotation, even a simple one, limits the exploitation window of a key that might have leaked without anyone noticing.

Points to verify before publishing: confirm that the description of how .env files work and their exclusion via .gitignore remains consistent with standard PHP development practices at the time of publication, and check that the secrets manager examples mentioned remain commonly used solutions on the market.