Infrastructure Security

The Risk

API keys in committed files are permanently in git history - even if you delete the file later. Bots scan GitHub continuously (including private repos via leaked PATs) and can find your keys within minutes. A single committed Brevo API key lets attackers send email as your domain.

The Solution

Store all secrets (API keys, database passwords, tokens) as environment variables on your hosting platform - never in code files. If a secret is accidentally committed to git, rotate it immediately (generate a new one and revoke the old one). Simply deleting the file doesn't help because git keeps the full history. Scan your repo periodically for accidental exposures.

The Fix

# Use environment variables only
API_KEY = os.getenv("API_KEY")
if not API_KEY:
    raise RuntimeError("API_KEY not configured")

# Scan for accidentally committed secrets
git ls-files | grep -i "env|secret|key|token"

# If found, rotate immediately - don't just delete the file

The Risk

Missing .gitignore entries cause secrets and large files to be committed accidentally. A .env file with database URLs, an SSL private key (.pem), or a node_modules folder can all end up in your repo. Once committed, removing them from the working tree doesn't remove them from git history.

The Solution

Add a .gitignore file at the root of every repository that lists all files and folders that should never be committed: .env files (secrets), private keys (.pem, .key), dependency folders (node_modules, .venv), and build outputs (dist, build). This is a one-time setup that prevents accidental exposure of sensitive files.

The Fix

# Minimum .gitignore for every repo
.env
.env.local
.env.*.local
.env.vercel.check
node_modules/
__pycache__/
.venv/
dist/
build/
*.pem
*.key

The Risk

When one backend serves multiple apps (e.g., a shared API behind App A, App B, and a dashboard), changing CORS origins, auth behavior, or rate limits for one app can break the others. You push a CORS fix for App A and App B's fetch calls start failing with opaque CORS errors. This is especially dangerous because the broken app shows no error in server logs - only the browser console reveals the CORS failure.

The Solution

Before changing any shared backend configuration: list all apps that depend on it (check CORS origins list, API monitor logs, cron jobs, MCP endpoints). Test the change against each app's endpoints. If possible, use environment variables so CORS origins and rate limits are configurable per deployment. When in doubt, add the new origin to the allow list rather than replacing the existing ones.

The Fix

# Before changing a shared backend:
# 1. List all consumers
grep -r "BACKEND_URL" ../*/  # find all apps calling this backend
# Check API monitor: which apps hit which endpoints?

# 2. Check CORS origin list covers all consumers
origins = os.getenv("CORS_ORIGINS", "").split(",")
# Verify: every frontend that calls this backend is in the list

# 3. Test each app after deploying changes
# CORS failures show in browser console, NOT server logs

# 4. Use env vars for flexibility (per-deployment config)
RATE_LIMIT = os.getenv("RATE_LIMIT", "30/minute")
# Different deployments can have different limits

The Risk

Unlike Vercel (auto-deploys on git push), self-hosted platforms like Coolify often require manual deployment triggers. After pushing a security fix, the old vulnerable code keeps running until you explicitly deploy. This gap can be minutes or hours - during which your fix exists in git but not in production.

The Solution

For security-critical changes: verify whether auto-deploy is enabled BEFORE pushing. If not, immediately trigger deployment after push (via Coolify API, dashboard, or webhook). After deployment, verify the new version is running - hit the /health endpoint, check container logs, or look for a version indicator. Don't assume pushing means deploying.

The Fix

# After pushing a security fix:

# 1. Check if auto-deploy is enabled
# Coolify: Settings > Auto Deploy toggle
# If OFF, trigger manually:
curl -X POST "https://coolify.example.com/api/v1/deploy" \\
  -H "Authorization: Bearer $COOLIFY_TOKEN" \\
  -d '{"uuid": "app-uuid"}'

# 2. Verify new version is running
curl https://app.example.com/health
# Check: response should reflect the fix

# 3. Check container logs for successful startup
docker logs <container> --tail 20

The Risk

After major refactors - consolidating endpoints, migrating auth systems, switching from direct API calls to a proxy - code paths that were once reachable may become dead. This seems harmless, but dead code with auth exemptions is a latent vulnerability. If someone later creates a route or endpoint that accidentally hits that old code path, the auth bypass activates silently. Real-world example: after consolidating 11 API endpoints into a single RPC endpoint with JWT auth, a Calendly webhook handler inside one of the old handlers still had an auth exemption (it used webhook signature verification instead of JWT). The old endpoint no longer existed, but the code was still there inside the handler function. If someone later re-created that endpoint path for any reason, the auth bypass would have been active.

The Solution

After any major architecture change, audit the codebase for: (1) Auth bypass patterns - search for code that skips JWT/auth verification for specific actions or paths, then verify those paths are still reachable and intentional. (2) Hardcoded URLs referencing old endpoint structure - webhook callback URLs, redirect URLs, API base URLs that point to deleted paths. (3) Conditional auth logic - if/else branches that grant different auth treatment based on action type or path. Remove unreachable branches entirely rather than leaving them as dead code.

The Fix

# After consolidating endpoints or changing auth flow:

# 1. Search for auth bypass patterns
grep -rn "skip.*auth\\|no.*auth\\|bypass\\|exempt\\|without.*verify" api/
grep -rn "action.*===.*webhook\\|action.*===.*public" api/

# 2. Search for hardcoded URLs to old endpoints
grep -rn "/api/old-endpoint\\|api/calendar\\|api/webhook" .

# 3. Search for conditional auth (different paths get different treatment)
grep -rn "if.*action.*===.*\\|switch.*action" api/
# Then verify each branch is still reachable

# 4. After cleanup, verify nothing broke:
npm run build  # frontend compiles
# Hit each endpoint to confirm auth still works