Credential & Environment Hygiene
13 practices · Internal team guidelines + OWASP Secrets Management & Authentication Cheat Sheets
How we handle passwords, staging access, secrets and who can reach what. Most of these cost minutes, and they are the items that turn a small mistake into an incident when they are missing.
Ticking these off for a specific project? The Project Security Checklist tracks all nine categories in one place. For why these patterns keep recurring, see Security Best Practices.
1. Staging Sits Behind Real Access Control, Not Just Noindex
DescriptionA meta noindex tag or robots.txt disallow keeps staging out of search results, but does nothing to stop a bot or a person with the URL from loading and reading the site. Staging should also require HTTP basic auth, an IP allowlist, or a VPN — and both protections come off together, deliberately, at launch.
Examplenginx: satisfy any;
allow 203.0.113.0/24; deny all;
auth_basic "Staging"; auth_basic_user_file .htpasswd;
+ <meta name="robots" content="noindex, nofollow">2. No Simple or Default Passwords, on Any Account — Staging Included
DescriptionEvery account, on every environment, gets a password meeting a real strength bar — a password manager's generated password, not "Company2024!" — because "it's just staging" is exactly the reasoning that leads to the account that gets found first.
ExamplePassword policy (all environments):
min 14 chars, generated (not chosen), unique per account
enforced via password manager's built-in generator3. No Password Reuse Across Accounts, Staging/Prod Included
Description"Not simple" isn't the same as "not reused." A strong password used on both staging and production — or reused from a personal account — is still a single point of failure: one leak anywhere it's used compromises everywhere it's used.
ExamplePassword manager flags reuse automatically:
1Password Watchtower → "Reused Passwords" report
run and cleared before each client handoff4. Share Credentials Through a Secrets Tool, Never Email or Chat
DescriptionA password typed into an email or Slack message lives forever in that platform's history, forwards, and search index. Share access through 1Password (a shared vault or item-sharing link) or a self-destructing link like One Time Secret instead.
Example1Password: share item → generates a link that
expires after first view / 7 days
// never: "here's the staging login: admin/Summer2024"5. SSO/Google Auth for Admin Panels, Not Email + Password
DescriptionWherever an admin panel supports it, sign in through Google/SSO instead of a standalone email-and-password account — one fewer password to leak, and access is revoked centrally the moment someone leaves Google Workspace. Fall back to email/password only when there's a specific reason the tool doesn't support SSO.
ExampleWordPress: Nextend Social Login restricted to
the company Google Workspace domain,
email/password login disabled for the admin role6. MFA Everywhere It's Supported, Not Just Admin Panels
DescriptionMulti-factor authentication belongs on every service that offers it — hosting provider, domain/DNS registrar, git host, payment processor, and any dashboard with billing or customer-data access — not only the CMS admin login. A registrar account without MFA is one of the highest-value targets there is.
ExampleMFA enabled checklist: GitHub ✓ AWS root ✓
GoDaddy/registrar ✓ Stripe ✓ Google Workspace ✓7. No Real Customer Data on Staging, Ever
DescriptionStaging and QA environments run on synthetic or scrubbed data — names, emails, payment details replaced — never a copy of production. This is the one item on this list that turns a staging leak from an embarrassment into an actual data-breach conversation.
ExampleDB refresh script: pg_dump prod | anonymize.py
(replaces emails, names, payment tokens)
→ restore into staging
// never: direct prod → staging restore8. Sandbox API Keys on Staging, Never Live Keys
DescriptionEvery third-party integration with a "live mode" — Stripe, PayPal, transactional email, analytics — runs on its sandbox/test credentials in staging. A live key on staging means a staging bug can trigger a real charge or a real email to a real customer.
Example.env.staging:
STRIPE_KEY=sk_test_...
.env.production:
STRIPE_KEY=sk_live_... // never swapped or shared9. No Secrets Committed to Git, Anywhere in History
DescriptionAPI keys, database credentials, and .env files never enter the repository — a correct .gitignore from day one, environment variables or a secrets manager for real values, and a pre-commit scanner as the backstop for the day someone forgets.
Example.gitignore: .env, .env.*, *.pem, *.key
+ gitleaks pre-commit hook blocks the push itself
if a key-shaped string is staged10. Revoke or Rotate Access Immediately on Offboarding
DescriptionWhen a contractor, freelancer, or team member's involvement ends, their access is removed the same day — every account they touched, staging included, not just the ones that come to mind first. A shared checklist prevents the ones that get forgotten.
ExampleOffboarding checklist: GitHub org ✗ remove
AWS IAM user ✗ deactivate Staging admin ✗ revoke
1Password vault ✗ remove Rotate any shared secret they held11. Least-Privilege Access for Every Collaborator
DescriptionGive each person the minimum role the work requires — viewer or editor, not admin by default — on every tool from the CMS to the cloud console to the shared drive. Reviewing and tightening this periodically catches access nobody remembers granting.
ExampleWordPress: contractor gets "Editor" role
// not "Administrator" by default
AWS: scoped IAM role, not full account access12. Regularly Audit Who Has Admin-Level Access
DescriptionPeriodically list everyone with admin rights on production systems and confirm each one still needs it — the list should be small, known, and justified, not something reconstructed from memory when a client asks.
ExampleQuarterly access review:
export admin list per system → confirm each name
still active + still needs that level13. Password Manager for the Team, Not Personal Notes or Spreadsheets
DescriptionShared credentials live in a team password manager with per-item sharing and an audit trail — not a notes app, spreadsheet, or personal notebook that no one else can access when the one person who has it is unavailable.
Example1Password Teams: shared vault per client,
access granted/revoked per person,
activity log shows who viewed what, whenLast updated: September 2026 · Source: Offspring — Security Best Practices.pptx (Part 4) + Security Best Practices Checklist.xlsx