Secrets and API Key Management in Business Applications: Storing, Rotating, and Detecting Credential Leaks

An API key for a payment service is stored in a configuration file, that file gets copied into the code repository, and one day the repository is shared with a new contractor or, worse, accidentally made public. Within hours, someone scanning the internet finds the key and uses it. A scenario like this is not a rare story. Leaked application secrets, such as database passwords, API keys, access tokens, and certificates, are among the most frequent and most preventable causes of security incidents.

The term secret in software development refers to any value that grants access to a system and must not be known to the public. A modern business application uses dozens of secrets: database connections, payment services, email and messaging, file storage, AI services, integrations with ERP and marketplaces, and the keys that sign login sessions. The more integrations, the more keys to protect.

This article explains how to manage secrets with a discipline that is realistic for small and medium businesses: where to store them, how to separate environments, how to rotate, how to detect leaks, and what to do when an incident happens. You do not need expensive tools to start. What you need are consistent habits and rules.

Summary

• Never store secrets in source code, Git history, screenshots, or chat groups
• Separate secrets per environment (development, test, production) and per service, with the least possible access
• Store them in a place designed for it, namely a secrets manager or encrypted environment variables on the hosting platform, not in ordinary files
• Rotate secrets periodically and immediately after someone leaves the team or a leak is suspected
• Install automated scanning to detect secrets accidentally committed, and prepare a written procedure for when one leaks

What counts as a secret

Many teams consider only passwords to be secrets. The list is actually longer. Here is what is commonly found in business applications:

• Database passwords and connection strings
• API keys for payment, shipping, maps, email, messaging, and AI services
• Access tokens and refresh tokens for third-party integrations, including ERP, marketplaces, and accounting
• Webhook signing secrets and session token signing keys
• Certificates and private keys, including SSH keys for server access
• Cloud account and service account credentials
• Shared account passwords such as the hosting panel, domain registrar, and company social media accounts

Note that client-side values, such as public keys for maps or analytics, are designed to be visible in the browser and are not secrets. However, a key that looks like that often has a secret counterpart. Check each service's documentation to tell them apart, and restrict public keys to specific domains where the service supports it.

The mistakes that most often cause leaks

Most leaks are not the result of sophisticated hacking but of loose everyday habits.

Secrets in code or Git history

Writing a key directly in code for speed is the number one source of leaks. Even if the key is later removed from the code, it remains in the Git history, so anyone who can access the repository can find it. Deleting the file is therefore not enough; a key that was ever committed must be treated as leaked and rotated.

Configuration files that get uploaded

Files such as .env or production configuration files are often accidentally committed or included in archives sent to a vendor. Make sure such files are on the ignore list from day one, and provide an example file without real values for documentation.

Shared through chat and email

Sending passwords through chat groups or email is easy, but the message stays for a long time on many devices and backups. Use a team password manager or a one-time secret-sharing tool for unavoidable cases.

Screenshots and logs

Secrets that appear in screenshots of support tickets, screen recordings, or application logs are often forgotten. Make sure logs do not print authorization headers, tokens, or entire request bodies that contain credentials. Safe logging practice is discussed in observability, logs, and error handling in business applications.

One key for everything

Using the same key in development, test, and production, or one administrator account for all services, widens the impact of a leak. One lost developer laptop could mean full access to production data.

The right place to store secrets

The principle is simple: secrets are not stored with the code but injected into the application when it runs.

• Environment variables on the hosting or CI/CD platform: the simplest approach and adequate for many applications. The values are stored encrypted by the platform and do not enter the repository
• Secrets manager: a dedicated service that stores, controls access, records who read, and supports automatic rotation. Suitable when the number of secrets and people grows
• Team password manager: for human credentials such as panel and registrar accounts, with per-folder access rights and audit records
• Hardware security module or cloud key service: for highly sensitive encryption and signing keys

Do not build your own solution such as a spreadsheet of passwords or a shared document titled access. Those tools have no proper access control, do not record who accessed, and are easily copied.

Separating environments and limiting access

Apply three consistent separations. First, environment separation: development, test, and production use different secrets. Non-production environments should use sandbox accounts of third-party services and fictional or anonymized data, in line with personal data protection for websites and applications.

Second, per-service separation: each application or module uses its own credentials, with only the permissions needed. A key that only needs to read data must not be able to write or delete. This least-privilege principle is the same as discussed in designing user access rights, except that the subject is an application, not a person.

Third, separation of people: not every team member needs to see production secrets. Limit them to people who actually operate the system, protect them with multi-factor authentication, and consider passkeys and passwordless login for accounts that hold access. For access across applications, SSO and identity management reduces the number of passwords in circulation.

Rotation: changing keys before and after trouble

A secret that is never changed gives unlimited time to anyone who obtains it. Rotation means changing the secret's value periodically and on certain events.

• Periodically: set a schedule, for example quarterly for important keys, and more often for short-lived tokens
• When people leave: when an employee, contractor, or vendor who had access to secrets stops working, rotate the secrets they knew
• When a leak is suspected: rotate immediately, without waiting for evidence of misuse
• When changing vendors: a project changing hands, as in [rescuing a stalled software project and changing vendors](/blog/menyelamatkan-proyek-software-yang-macet-dan-pindah-vendor), must include a credential handover and a rotation afterward

To keep rotation from causing downtime, design the application to support two active values temporarily (for example the old and new key) during the transition, then revoke the old one. Test the rotation procedure in a test environment before you need it in an emergency. With automated testing and CI/CD, checking that the application keeps running after a key change can be made a routine step.

Detecting leaks early

Prevention is never perfect, so install detection.

• Secret scanners on the repository and on every commit or merge request, rejecting changes that contain known key patterns
• Periodic scans of repository history to find old keys that were once committed
• Alerts from service providers when a key is detected publicly or used from an unusual location
• Usage monitoring: spikes in API calls, unusual bills, or access from foreign regions are often the first sign
• Restricting keys to certain IP addresses, domains, or permission scopes so a leaked key is hard for others to use

Usage monitoring is also tied to cost. A leaked AI or cloud service key can generate a large bill overnight, as discussed in controlling AI costs and controlling cloud costs for business. Set budget limits and alerts on service accounts.

Secrets in integrations, webhooks, and AI agents

Third-party integrations add attack surface. For webhooks, verify the signature of every incoming request with a shared secret so others cannot forge notifications, as discussed in webhooks and real-time integration for business. For APIs you provide yourself, issue keys per client with limited scope that can be revoked one by one, as in API design for business. For payment gateways, follow the provider's security guidance and never put secret keys in client-side code; see payment gateway integration.

AI agents and connectors that call business systems through protocols like those discussed in Model Context Protocol need credentials too. Give agents separate credentials with narrow permissions, do not put secrets into prompts or model context, and watch for data leaks through model output as outlined in AI application security: prompt injection and data leaks.

A plan for when a secret leaks

Prepare a written procedure before an incident occurs, because in a panic people skip steps. The recommended order:

• Revoke or rotate the leaked secret immediately, even before the investigation is finished
• Determine the scope: since when the secret was exposed, who or what could use it, and what it could access
• Check access logs and bills for unauthorized use
• Clean up the source of the leak, for example removing it from the repository, rewriting history if necessary, and fixing the process cause
• Notify affected parties according to legal and contractual obligations, especially when personal data is involved
• Record the lessons and improve the process

This procedure is part of the cybersecurity incident response plan for business, while the ability to restore data lies in business data backup strategy. The broader basics are in basic security for business applications.

When development is done by a vendor or outside team

Outside development adds weak points because many people touch the credentials. Arrange it in the contract and in working habits: production credentials are held by you or managed through a shared secrets manager, the vendor gets temporary and limited access, and all cloud accounts, domains, and repositories are registered in your company's name, not a developer's personal name. When the project ends, revoke access and rotate. These points complement the advice in outsourcing software development to Indonesia and key points of a software development contract.

Steps to start this week

You do not need to wait for a big project. Do the following five things in one week: list all the secrets in use and where they are stored; move everything written in code or ordinary files into environment variables or a secrets manager; install a secret scanner on the repositories; enable multi-factor authentication on all accounts that hold access; and rotate keys that were ever shared through chat or email. These five steps already close most of the most common risks.

Frequently asked questions

Is it safe to store secrets in a .env file on the server?

Better than putting them in code, as long as the file is not in the repository, its file permissions are restricted, and the server is protected. However, a secrets manager or encrypted environment variables on the platform give better access control, auditing, and rotation, especially as the team grows.

An API key was already committed. Is it enough to remove it from the code?

No. The key remains in the history. Treat it as leaked: rotate the key, then clean the code. Rewriting Git history can help reduce exposure but does not replace rotation.

How often should secrets be rotated?

There is no single number. For important keys, quarterly or semiannual is a reasonable starting point, and rotation is mandatory on trigger events such as someone leaving or a suspected leak. The more automated the rotation, the more often you can do it.

Does a small business really need a secrets manager?

Not necessarily at first. Encrypted environment variables on the hosting platform plus a team password manager are often adequate. Consider a dedicated secrets manager when the number of services, environments, and people with access makes manual management hard to audit.

Conclusion

Managing secrets is a habit, not a product. Do not put secrets in code, store them in a place designed for it, separate them per environment and per service, limit who can see them, rotate periodically, and set up detection plus a written emergency procedure. Businesses that apply this discipline close one of the most common incident paths at a far smaller cost than the impact of a single leaked key.