What to know
- Record owners and consumers without copying secret values.
- Keep private credentials server-side and restrict permissions.
- Revoke or rotate exposed keys before repository cleanup.
Give every credential a clear purpose
An API key should have an owner, a service, an environment and a reason to exist. Our suggested inventory records those facts without storing the secret itself in the worksheet. Separate development from production and identify which application consumes each credential. That makes a later replacement much easier than searching through servers during an incident.
Limit access and lifetime
The OWASP secrets-management guidance recommends least privilege, revocation, rotation and protection from plaintext logging. Grant only the operations an integration needs. Store private credentials in a protected server-side configuration or appropriate secrets manager, and restrict who can retrieve them. A secret in browser-delivered JavaScript is available to the browser user regardless of how confusing its variable name looks.
Review deployment and diagnostics
Laravel’s deployment guide warns that production debug mode can expose sensitive configuration. Serve the application from its intended public directory and keep private configuration outside the web root. Our release checklist also reviews error pages, support exports and log samples for accidental disclosure. Use harmless placeholders in documentation and screenshots.
Respond to exposure with replacement
GitHub’s sensitive-data guidance puts revoking or rotating an exposed credential before repository-history cleanup. Deleting a line from the latest commit cannot make an already copied key private again. Replace the affected key, update its consumers, check access records and coordinate any repository cleanup with collaborators. Avoid spreading the old value through incident tickets.
Practice a normal rotation before an emergency
Our recommended exercise is to replace one low-risk test credential, confirm the integration still works and document the sequence. For production, agree on supported overlap, revocation timing and a recovery contact with the provider. Verify scheduled jobs as well as web requests before closing the change. Keep only the evidence needed to prove completion, with secret values redacted. For an integration review, describe the services through Kiava web development. The VPS security checklist covers the surrounding server access controls.
Sources & further reading
Primary sources supporting this article. The practical recommendations are Kiava’s general guidance and should be adapted to your project.