Secret management best practices: Secure your Node.js and PHP apps

Last month, I spent an entire Saturday rotating API keys because a junior developer accidentally pushed a .env file to a public repository. We’d all been there before, but the cleanup—revoking tokens, updating CI/CD pipelines, and auditing logs—took about six hours of manual work I didn't want to repeat. If you're building production apps, your credentials don't belong in Git, period.

Effective secret management isn't just about hiding passwords; it's about building a workflow that makes it impossible to commit them in the first place.

The Foundation: Decoupling with Environmental Variables

The first rule of secure configuration is that your code should never know your secrets. Instead, it should know how to ask for them. Whether you're working in Node.js or PHP, the pattern remains identical: read values from the system environment.

In Node.js, we typically use dotenv to load a local file during development. However, never rely on this in production. For Laravel developers, understanding the .env file and configuration in Laravel is essential, but remember that the .env file itself is a local convenience, not a deployment strategy.

When your app boots, it should look like this:

JAVASCRIPT
// Node.js example
const dbPassword = process.env.DB_PASSWORD;
if (!dbPassword) {
  throw new Error("Missing mandatory environment variable: DB_PASSWORD");
}

By explicitly checking for the existence of these variables at startup, you crash fast if the configuration is missing, rather than running in an undefined state.

Hardening the Workflow with Git-Secrets Scanning

Even with the best intentions, humans make mistakes. We might commit a test file or a debug script that contains a hardcoded credential. This is where git-secrets scanning comes in. You need a safety net that runs locally and in your CI pipeline.

I've experimented with several tools, but gitleaks is my current go-to. It’s fast, supports regex-based patterns, and integrates cleanly into pre-commit hooks.

Implementing the Safety Net

1. Install the tool: brew install gitleaks (or use their Docker image).
2. Define your rules: Create a gitleaks.toml file in your repo root.
3. Run the scan: Execute gitleaks detect --source . -v before every push.

If you want to automate this for your team, add a pre-commit hook. Create a file at .git/hooks/pre-commit:

Bash
#!/bin/sh
gitleaks detect --staged --redact

This prevents a commit from finishing if it detects high-entropy strings that look like API keys. It’s saved me from "oops" moments more times than I can count.

Moving Beyond Local Files

Early in my career, I thought storing encrypted JSON files in the repo was clever. It was a disaster. The key to decrypt the file was eventually committed, or the file size grew too large to manage.

Instead, focus on platform-native solutions. If you're on AWS, use Parameter Store or Secrets Manager. If you're using Heroku or Render, their dashboard-based environment variables are the standard. The goal is to move the secret from your local disk into the infrastructure's memory at runtime.

Common Pitfalls and Lessons Learned

I once tried using a custom shell script to inject secrets into a PHP app during the build phase. It worked, but it left the secrets exposed in the process environment list, which was visible to other users on the shared server. I learned the hard way that preventing improper CORS policy configuration is only half the battle; if your environment variables are readable by other processes, your secrets aren't actually secret.

Another mistake is failing to rotate secrets after a leak. If a credential hits a public repo, assume it’s compromised. Don't try to "clean" the history; just rotate the key.

Frequently Asked Questions

Q: Should I commit an .env.example file? A: Yes, absolutely. It acts as a template for other developers without exposing real values. Just ensure it contains dummy data.

Q: Does git-secrets scanning slow down my workflow? A: If you scan the entire history, yes. If you scan only staged changes, it usually adds less than 200ms to your commit time. It's a negligible price for peace of mind.

Q: What if I have to use a legacy system that requires a config file? A: Use a template engine to generate the config file at runtime using environment variables as the source of truth. Never store the actual config file in version control.

Final Thoughts

Security is a process, not a destination. While tools like gitleaks provide a solid layer of defense for git-secrets management, they aren't a replacement for team culture. Make it clear to your team why hardcoding secrets is a non-starter.

I still worry about "shadow" configurations—those hidden variables that get added to a server and forgotten. Next time, I’m planning to implement a centralized secret injection service that logs access, so we can see exactly which services are touching which keys. For now, keeping the environment clean and the git history sanitized is the best defense we’ve got.