Generating and Storing Secure API Keys During Local Development

An audit of our local development setups, prompted by an unrelated security review, turned up something more concerning than any of us expected: one developer's local .env file used the exact same 12-character password-like string as the API key for nine different local services — the mail testing tool, a local admin panel, a webhook testing proxy, and six others — because it was easy to remember and had been copy-pasted from service to service over roughly a year of onboarding new local tools. None of these were production credentials, which is the only reason this wasn't a serious incident. It was, however, a clear signal that "generate something for local dev, I'll deal with it later" was quietly turning into "never actually deal with it," which is worth taking seriously even when the immediate stakes are low.

Why weak local keys matter more than they seem to

The instinctive reaction to a weak local development key is that it doesn't matter — it's not protecting anything valuable, it's running on a laptop, not the internet. Two things make this reasoning weaker than it feels: first, local development environments increasingly do talk to real external services during testing — a payment provider's sandbox, a real (if free-tier) transactional email service — and a weak or reused key there is a genuine, if smaller-scale, version of the same risk a weak production key carries. Second, and more subtly, habits formed during low-stakes local development have a way of carrying over into higher-stakes situations, specifically because a developer under time pressure reaches for whatever workflow is already automatic, and "reuse the same string everywhere" is a genuinely dangerous habit to have on autopilot the one time it accidentally applies somewhere that matters.

Generating a key properly, instead of typing something memorable

The actual fix is mechanical and takes seconds once it's part of the routine: generate a real random string for every credential, rather than typing something you can remember. From the command line:

# A cryptographically random 32-character string, URL-safe
openssl rand -base64 24 | tr -d '/+=' | head -c 32

# Or, using PHP directly
php -r "echo bin2hex(random_bytes(16));"

Either produces a string with no memorable pattern and no relationship to any other key in use anywhere else, which is the entire point — a key generated this way can't accidentally be the same as a key generated the same way for a different service, the way "a password I like" inevitably ends up being reused. For anyone who'd rather not reach for a terminal every time, this site's own password generator produces the same kind of cryptographically random string through a simple form, which is a reasonable everyday tool for exactly this task without needing to remember the command-line syntax.

Where generated keys actually belong

Generating a strong key solves half the problem; the other half is not writing it down somewhere it'll get reused by habit the next time a new service needs one. A local secrets manager, rather than a personal notes file or — worse — the pattern that caused the original incident, keeps each generated key retrievable without keeping it memorable:

# Using a local secrets tool (1Password CLI shown as an example)
op item create --category=password \
    --title="Local Dev — Webhook Proxy Key" \
    --vault="Local Development" \
    password="$(openssl rand -base64 24 | tr -d '/+=' | head -c 32)"

Piping a freshly generated key directly into a secrets manager, rather than generating it, looking at it, and typing it somewhere, removes the exact step where a human decides "I'll just reuse the one I remember" out of the loop entirely. The friction of retrieving a properly stored key is genuinely lower once the habit is built than the friction of trying to remember which reused string goes with which service anyway — the audit that started this whole review found that reused keys weren't actually saving anyone real time, they were just a habit nobody had questioned.

A practical distinction: which local keys actually need this rigor

• Keys authenticating against a real external service, even a sandbox or free tier — payment provider test keys, transactional email sandbox keys — deserve full rigor: randomly generated, stored in a secrets manager, never reused across services.
• Keys used purely between local services on your own machine, with no external network exposure at all — a local Redis password, for instance, on a service only ever bound to localhost — carry genuinely lower stakes, though generating them properly costs nothing extra and avoids having to make this judgment call individually for every single key.
• When in doubt, treat it as the first category. The cost of over-securing a low-stakes local key is a few extra seconds; the cost of under-securing one that turns out to matter is the kind of incident this post opened with.

The audit that found this, and what it changed going forward

The original security review that surfaced the reused-key pattern wasn't specifically looking for it — it was a routine check of local environment configurations across the team, and the reuse pattern showed up as a side finding once someone noticed the same string appearing in multiple unrelated config files during a search. That's worth noting as its own lesson: this kind of habit rarely gets caught by someone deliberately looking for it, because nobody schedules time to audit their own past shortcuts. It surfaces sideways, during an unrelated review, if it surfaces at all — which is the actual argument for building the better habit up front rather than planning to catch and fix it later during some hypothetical future cleanup that, realistically, competes with everything else on a busy team's list and tends to lose.

The concrete change going forward: generating a new local credential is now a documented step in the same onboarding checklist covered in setting up a productive local dev environment from a blank laptop, with the command-line snippet above included directly rather than left to individual memory or habit. Folding a good default into the onboarding document a new team member actually reads, rather than relying on tribal knowledge, is a small change that's done more to prevent a repeat of the original finding than any individual conversation about the risk ever did.

What rotation actually looks like once keys are properly stored

Generating a strong, unique key once solves the reuse problem at the moment of creation. It doesn't solve a related, quieter problem: local development keys, once generated and stored, tend to sit unrotated indefinitely, because nothing about local development naturally prompts anyone to revisit them the way a production credential rotation policy might. A key generated two years ago for a local testing tool that's still in use is, in practice, no different in risk profile from the reused-key habit this whole review started with — it's just a single string that's been stable for a very long time instead of a string reused across several services.

# A simple script run quarterly, listing local secrets older than 6 months
op item list --vault="Local Development" --format=json \
    | jq '.[] | select(.updated_at < (now - 15552000))'

Running a check like this on a recurring basis — not because any specific incident demands it, but as a routine practice — surfaces local credentials that have quietly aged well past when anyone last thought about them. Rotating a local development key is close to zero-risk compared to rotating a production one: there's no customer-facing downtime to coordinate, no deployment window to plan around, which makes "we should get around to this eventually" a genuinely weaker excuse for local keys than for production ones, where the operational cost of rotation is real and worth weighing carefully.

A checklist for onboarding a new local service or tool

• Generate a fresh, random key using a proper generator rather than typing something memorable — the command-line snippet above or this site's password generator both work.
• Store it in a secrets manager immediately, not in a plain text file, a sticky note, or — as the original incident showed — a mental pattern reused from the last several services set up the same way.
• Add it to .env.example as an empty placeholder, so the next person setting up the same tool knows a value is expected without ever seeing what the actual value is.
• Note the creation date somewhere retrievable, even informally, so a future rotation check like the one above has something to compare against.

None of these individually take more than a few seconds, and the audit that started this whole review exists specifically because skipping all four, repeatedly, over roughly a year, is how one developer ended up with the same weak string protecting nine unrelated local services without ever consciously deciding that was an acceptable outcome.

Why this was easy to let slide for a year

Worth being honest about why the original habit formed at all, since "just be more disciplined" is exactly the kind of advice that doesn't survive contact with a busy sprint. Setting up a new local tool is usually a small, interruptive task wedged between other work — install a package, configure a webhook proxy, get back to the actual feature being built — and reaching for a key you already remember genuinely is faster in the moment than opening a secrets manager, generating something new, and filing it away properly. The fix that actually worked wasn't asking anyone to care more; it was making the secure path just as fast as the shortcut, by scripting key generation and storage into a single command rather than several manual steps, so the properly secure version stopped costing any more time than the shortcut it was replacing.

#!/bin/sh
# scripts/new-local-key.sh — one command, does the whole thing properly
SERVICE_NAME=$1
KEY=$(openssl rand -base64 24 | tr -d '/+=' | head -c 32)

op item create --category=password \
    --title="Local Dev — ${SERVICE_NAME} Key" \
    --vault="Local Development" \
    password="$KEY"

echo "Generated and stored key for ${SERVICE_NAME}. Retrieve with:"
echo "  op item get \"Local Dev — ${SERVICE_NAME} Key\" --fields password"

A single command that generates, stores, and confirms a new key removed the exact friction that made the old habit tempting in the first place — running ./scripts/new-local-key.sh webhook-proxy takes less time than typing out a remembered password would have, which is the actual reason this stuck where a policy document alone wouldn't have.