Enterprise security, with receipts.
Most security content is theory written by people who have never been paged at 3am. This is the other kind. Every practice on this page is running in real production code right now. We show you what we built, what each guard stops, and the steps to build the same protection yourself.
This is not a compliance certificate.
Nobody handed us a badge, and we are not pretending they did. This is the engineering standard we hold our own systems to, written down so you can hold yours to it. Where a practice has a number, the number is real and comes from the code. Where we could not prove something in the code, it is not on this page. If you have been burned by security theater before, good. Read this the skeptical way. It is built for that.
The receipts come from two systems we run in production. HiveMind is our internal command center. It started life on one desk and now serves the whole business over the public internet, with writes enabled. Curated Sync is middleware we built for a client: it moves a 28,000-product rental catalog between their ERP and eight public storefronts, where one bad sync could wipe a live store. Different jobs. Same standard.
Who gets in, and who decides
When we put our internal dashboard on the public internet, the first decision was this: the app itself is never the front door. Identity gets checked at the edge, before a request ever touches our code. And the app keeps its own locks anyway, because of a trap most teams never see coming.
Check identity at the edge, not inside your app
Put an identity-aware proxy in front of anything private that faces the internet. The login wall belongs to the edge provider, not to your application code. Your app only ever sees requests that already carry a verified identity.
What it stopsEvery drive-by scanner, credential stuffer, and bot on the internet. They hit the wall and never learn your app exists.
HiveMind sits behind Cloudflare Access in front of an outbound tunnel. The proxy passes a verified email header to the app. When we probed it anonymously after launch, the probe got the access wall and nothing else: zero bytes of the dashboard leaked.
How to do this yourself
- Pick an identity-aware proxy. Cloudflare Access, Tailscale, or an equivalent. The requirement: it authenticates the user before traffic reaches you.
- Connect it with an outbound tunnel from the machine running your app, so you never open an inbound firewall port.
- Read the proxy's identity header in your app and map it to your own user records. Only trust that header because of practice 2 below.
How you'll know it workedOpen your URL in a private browser window. You should see the provider's login wall, and your server logs should show nothing at all for that visit.
Bind to localhost, but never treat localhost as identity
Bind the app to 127.0.0.1 so nothing on the network can reach it directly: only the tunnel and the machine itself. Then the trap: once a tunnel is in play, the entire internet arrives at your app looking like a local visitor. So localhost gets you reachability control, never trust. Every request still goes through the full auth chain.
What it stopsThe classic tunnel bypass, where an attacker inside the tunnel inherits admin rights because the app assumed local means safe.
HiveMind's rule is written into the codebase: loopback is not a trusted identity, because the same-host tunnel makes the internet look like 127.0.0.1. Curated Sync goes one step further. Its emergency local access checks the physical socket address, never the forwarded header, because forwarded headers can be faked by anyone who can type.
How to do this yourself
- Bind your app server to 127.0.0.1, never 0.0.0.0, in its start configuration.
- Run your auth middleware on every request, including ones that appear local.
- If you need a local emergency path, check the raw socket address on the connection itself, never a header like X-Forwarded-For.
How you'll know it workedFrom another machine on your network, try to connect to the app's port directly. The connection should be refused, not just unauthorized.
Keep a kill switch you can pull in seconds
Before you expose anything, decide how you will un-expose it, and make that a single action. Ours is one command that stops the tunnel service: the public door closes instantly while the app keeps running locally. There is also a break-glass path for the opposite emergency, being locked out of your own system, and it works offline.
What it stopsThe worst hour of your life lasting a day. When something looks wrong at 2am, you close the door first and investigate second.
One service-stop command closes the public door. Separately, a flag file can disable enforcement in a lockout emergency, and doing so paints a red warning banner across every screen so it can never be quietly forgotten. A small command-line tool can reset the admin account with the server down.
How to do this yourself
- Write down the one command that severs public access, and rehearse it once so it is muscle memory.
- Build the reverse door too: an offline way back in when auth locks you out, such as a local admin-reset script.
- Make any emergency state loud. If enforcement is off, every page should say so in red.
How you'll know it workedTime yourself. From deciding to close the door to the door being closed should be under one minute.
Store passwords and sessions so a stolen database is useless
Passwords are hashed with scrypt and a per-user salt, which makes guessing expensive by design. Comparisons run in constant time, so response timing leaks nothing. And session tokens are stored only as hashes: the real token exists in exactly one place, the user's cookie.
What it stopsA leaked database becoming a mass login. The attacker gets salted hashes and hashed sessions, none of which open anything.
HiveMind hashes with salted scrypt and compares with a timing-safe function from the standard crypto library, no password framework needed. Curated Sync keys its admin sessions on the hash of the token, so even a full database copy contains no working session.
How to do this yourself
- Hash passwords with scrypt, bcrypt, or argon2 plus a random per-user salt. All three ship in standard libraries.
- Compare with your language's timing-safe equality function, never with ==.
- Store only the hash of session tokens server-side. Look sessions up by hashing the presented cookie.
How you'll know it workedRead your own users table. If you can turn anything in it into a working login without brute force, so can an attacker.
Harden cookies, and throttle the login door
Session cookies carry HttpOnly so scripts cannot read them, and SameSite=Strict so other sites cannot ride them. The Secure flag is conditional on TLS being present, because we learned that forcing Secure on a plain-HTTP staging box silently breaks login with no error at all. Login attempts run through a rate limiter tuned for brute force.
What it stopsStolen sessions via injected scripts, cross-site request forgery on admin actions, and password guessing at machine speed.
The cookie builder composes HttpOnly, SameSite=Strict, and Secure-when-TLS in one place, so no route can get it wrong. A dedicated login limiter and a global per-IP limiter sit in front, each with its own ceiling.
How to do this yourself
- Build session cookies in one shared function: HttpOnly, SameSite=Strict, Path=/, and Secure when TLS terminates in front.
- Add a rate limiter on the login route with a low ceiling, and a looser global one per IP.
- Return the same error for wrong user and wrong password, so the login door confirms nothing.
How you'll know it workedScript 50 rapid wrong-password attempts. You should get throttled long before 50.
Strangers meet a locked door before they meet your software. And your software never assumes a visitor is friendly just because they look local.
Your own robots are strangers too
The day we turned enforcement on, every one of our own background jobs got locked out. The morning sync went 0 for 19. That was the system working. The schedulers had been riding on trust that no longer existed, and the fix was one small helper, wired everywhere.
Make your own background jobs authenticate
Schedulers, daemons, and sync jobs that call your own API must identify themselves like everyone else, with an internal secret carried in a header. One shared helper stamps that header on every in-process call, so there is exactly one place to get it right. The helper re-reads the secret on every call, which means rotating it requires no restart.
What it stopsThe soft underbelly problem: an attacker who gets any foothold inside the machine finding an API that trusts anything local.
The helper exists because of a real failure: when the security chain started enforcing, every scheduler silently got 401s until each one was routed through it. The rule is now written down: any new in-process caller uses the helper, no exceptions.
How to do this yourself
- Generate a long random internal secret and store it with your other secrets.
- Write one helper function that returns headers including that secret, read fresh from config on each call.
- Route every internal HTTP call through it, and have your auth middleware accept the header as a service identity.
How you'll know it workedRemove the header from one job on purpose. It should get a 401, and your audit log should show it.
Deny by default, exempt by name
Every route requires auth unless it appears on a short, written, tested exemption list: the login page itself, health checks, OAuth callbacks, webhooks. Exemptions match exact paths or clean path segments, never a loose prefix. And an exemption only skips the session check: webhooks still verify their own signing secret inside the route.
What it stopsThe forgotten route. New endpoints are born protected. It also stops prefix tricks: our internal red-team pass showed that naive prefix matching would let a path like /api/thing-admin slip through an exemption meant for /api/thing.
The allowlist is one small file with exact paths, a handful of segment-boundary prefixes, and a traversal rejection. The comment at the top names the failed attack shapes it was tested against. Unclassified new routes fall to the default: authenticated, minimum role required.
How to do this yourself
- Flip the model: auth middleware runs on everything, and a single file lists the exceptions.
- Match exemptions on exact paths or segment boundaries. The path /api/pay matches /api/pay/hook but never /api/payments.
- Keep webhook secrets inside the webhook route. The exemption skips the session, not the signature check.
- Write tests for the list itself, including traversal and lookalike-prefix attempts.
How you'll know it workedAdd a new route and deliberately forget about auth. Requesting it while signed out should already return 401.
Rank roles, and give the unknown a floor
4 rolesFour roles in a strict ladder: Owner, Operator, Analyst, Viewer. A route declares the minimum rank it requires. The important move is the floor: any route nobody classified falls to a default minimum role, so forgetting to classify something makes it more locked, not less.
What it stopsPrivilege sprawl, and the quiet disaster of a sensitive new endpoint shipping with no rank at all.
The role ladder lives beside the user store, and route prefixes map to minimum roles in one config file with an explicit default for anything unmatched.
How to do this yourself
- Define 3 to 5 ranked roles. More than that and nobody can reason about them.
- Map route prefixes to a minimum role in one config file, not scattered through the code.
- Set the default for unmatched routes to a real role, never to open.
How you'll know it workedSign in as your lowest role and walk the admin surface. Everything sensitive should refuse politely.
Log before you deny
The audit hook is installed before the auth check, not after. That ordering is the whole practice: a logger that runs after auth never sees the requests that auth rejected, and a failed login is the single most important event you can capture. The log is append-only, and a high-signal subset mirrors off the machine with a whitelisted set of fields, so the record survives even if the box does not.
What it stopsInvestigating a break-in attempt with a log that only remembers the polite visitors.
One append-only event file records every denial and every state-changing write. Login failures, blocks, and account changes also mirror to an external error service, sending only whitelisted fields so no personal data rides along.
How to do this yourself
- Install the audit hook first in your middleware chain, recording on response-finish so it sees the final status.
- Append, never rewrite. One line of JSON per event is enough.
- Mirror the high-signal subset off-box with an explicit field whitelist. Skip routine noise or the record drowns.
How you'll know it workedFail a login on purpose. The attempt, its source address, and its timestamp should be in the record.
Inside is just another outside. Your own scripts carry ID, every door is locked unless it is on a short written list, and the security camera records the people who got turned away.
Keys that can leak without hurting you
One of our internal secrets once leaked into test output. It was rotated the same day, and nothing broke. That is not luck. That is what secrets management is actually for: making the bad day boring.
One home for secrets, zero in git
0 in gitEvery credential lives in one environment file that never enters version control, and nothing is hardcoded in source. Code reads secrets at call time, not at startup, which quietly enables everything else in this layer: a changed secret takes effect without a restart.
What it stopsThe most common leak in the industry: a key sitting in a repository that later goes public, gets cloned to a laptop, or gets shared with a contractor.
One environment file is the single source of truth across the whole workspace, ignored by git. HiveMind deliberately skips the usual auto-load library and reads keys per call through one helper, so new and rotated keys work live. Security state files are git-ignored as a class.
How to do this yourself
- Create one env file, add it to .gitignore first, then add secrets to it. That order matters.
- Read secrets through one helper function at the moment of use, not into globals at boot.
- Scan your repo history once for anything that ever got committed, and rotate whatever you find.
How you'll know it workedSearch your entire repository for your live key values. Zero hits, including in history.
Show a key once, store only its hash
32 random bytesWhen we mint an API key for a client site, it is 32 random bytes, shown exactly once at creation. The database stores only the hash. If the key is lost, nobody looks it up: a new one is minted. There is nothing to steal from the server because the server never kept the original.
What it stopsA database copy or a curious insider walking away with every client's working credentials.
The site-registration script prints the key once and stores the hash. The schema comment says it plainly: API keys stored as hashes only. Eight storefronts authenticate this way today.
How to do this yourself
- Generate keys from a cryptographic random source, at least 32 bytes.
- Print or display the key one time, then store only its hash with a standard digest.
- Authenticate by hashing the presented key and comparing against the stored hash.
How you'll know it workedTry to answer a client who lost their key. If your honest answer is "I will mint you a new one," you built it right.
Rotate with a grace window, so rotation never causes an outage
When a key rotates, the previous key keeps working for a grace window. The old hash moves to a previous-key column with a rotation timestamp, and auth accepts either until the window closes. This one column is the difference between rotation being routine and rotation being feared.
What it stopsThe reason most teams never rotate: the fear that rotating a key takes eight production sites down at the same instant.
Re-registering a site moves the current key hash to the previous slot and stamps the rotation time. The code comment states the goal: a rotation never causes an instant eight-site outage.
How to do this yourself
- Add two columns: previous key hash, and rotated-at timestamp.
- On rotation, shift the current hash to previous and store the new one.
- Accept the previous key only within your grace window, then let it die naturally.
How you'll know it workedRotate a key while a consumer is still on the old one. Nothing goes down, and the logs show which key each request used.
When a secret leaks, rotate it the same day
A leaked secret is not a debate, it is a task for today. This is only realistic because the two practices above made rotation cheap. Speed here is a property of the system, not of the person on call.
What it stopsThe gap between "we know it leaked" and "it no longer works," which is exactly the window an attacker uses.
An internal secret leaked into test output during a work session. It was rotated the same day, and because internal callers re-read the secret per call, the rotation needed no restart and broke nothing.
How to do this yourself
- Treat any secret that touched a log, a test output, or a chat as burned. No exceptions, no "probably fine."
- Rehearse one rotation per quarter so the muscle exists before the emergency.
- Note where each secret is read, and prefer read-per-call so rotation needs no restarts.
How you'll know it workedAsk yourself: if a key leaked right now, could you rotate it before end of day without an outage? If yes, this practice is real.
Screens say configured or missing, never the value
Admin settings pages show whether a secret is configured, and nothing else. No masked previews, no last-four hints, no reveal buttons. The same rule applies to APIs: a scrubber sits at the end of the response chain so no endpoint can echo environment contents, even by accident.
What it stopsSecrets leaking through the most casual channels there are: a screen share, a screenshot in a ticket, a demo recording.
Curated Sync's settings screen renders secrets as configured or missing, full stop. HiveMind's middleware chain ends in a secret scrubber, and its house rule bans env contents from ever appearing in an API response.
How to do this yourself
- In admin UIs, render a boolean, configured or missing, never the stored value.
- Add a response-layer scrubber that redacts anything shaped like your known secrets.
How you'll know it workedScreen-share your own settings page to a colleague. If nothing on screen would need blurring, you pass.
You cannot promise a secret will never leak. You can promise a leak costs you one boring afternoon instead of a breach report.
When something goes wrong, how much can it take with it?
Sooner or later an upstream system will hand you garbage: an empty catalog, a half-finished export, a retry storm. Security is not just keeping attackers out. It is making sure no single mistake, yours or theirs, can destroy the thing you run.
Cap how much any sync is allowed to delete
5% capEvery sync delta carries a delete-cap verdict: how many deletions this update implies, against a ceiling of 5% of the live catalog. Past the cap, the consumer must hold and alert instead of applying. And the edge case is handled the paranoid way: deleting anything from an empty or unknown catalog counts as a full wipe, never as safe.
What it stopsAn empty upstream response, a bad filter, or a scoping bug silently emptying a live storefront at 2am.
The verdict object rides on every delta response: delete count, catalog total, ratio, cap, breached yes or no, safe to apply yes or no. The consumer plugin is contractually required to hold on breach. This exists because live data proved it necessary: at one point 99.99% of rental products had no price, which under naive rules would have deleted nearly everything.
How to do this yourself
- Compute the deletion ratio of every sync batch against the live total before applying it.
- Pick a cap and enforce it in the producer, shipping the verdict with the data so every consumer sees it.
- Treat deletes against an empty or unknown total as a wipe, ratio 1, always held.
- Alert on hold, so a human decides whether the big deletion is real.
How you'll know it workedFeed your sync an empty upstream file in staging. The catalog should survive and the alert should fire.
Preview before you destroy, and guard the on-switch
Every destructive rule has a dry-run that reports what would change before anything does. And turning such a rule on is itself a guarded act: activation re-evaluates the damage at that exact moment, blocks with a 409 conflict if it breaches the cap, and requires an explicit force flag that gets written to the activity log with a name on it.
What it stopsThe configuration change that was obviously fine, applied to data that had changed since anyone last looked.
The visibility rules that decide which products appear on which storefront ship with a preview endpoint and an admin screen showing would-hide and would-show counts. Activation runs the delete-cap check live, refuses on breach, and force-overrides are logged as their own event type.
How to do this yourself
- Give every destructive feature a dry-run mode that returns counts, not vibes.
- Re-check safety at activation time, not just at configuration time.
- Allow override, but make it explicit and logged with who and when.
How you'll know it workedTry to enable a rule that would remove too much. You should be refused with numbers, and your override should leave a trail.
Make retries safe: same request, same result
Order and quote intake is idempotent, which is the technical word for "sending it twice does not create it twice." Each submission carries a client-generated ID. First arrival creates and returns 201. Any retry with the same ID returns 200 and the original result. Networks retry, users double-click, and none of it duplicates.
What it stopsDuplicate orders, duplicate charges, and the support tickets that follow every flaky wifi connection.
The quote endpoint is keyed on a client ID with a minimum length, backed by a durable queue: create once, retry safely, never duplicate. Verified end to end.
How to do this yourself
- Have the client generate a unique ID per logical action and send it with the request.
- Enforce uniqueness on that ID in the database, and return the existing record on conflict.
- Distinguish created from replayed in the status code so both sides can reason about it.
How you'll know it workedSubmit the same request five times fast. One record exists, and four responses say "already done."
Soft-delete, and only behind a complete sweep
Nothing is hard-deleted during sync. Records are marked deleted, reversibly. And even that marking is only allowed after a full sweep completed successfully for that entity type. A partial crawl, a timeout, or a failed page can never be misread as "those records are gone upstream."
What it stopsA network hiccup halfway through a sync being interpreted as mass deletion of everything the sync never reached.
Soft deletes run on full sweeps only, gated on per-entity success. A 28,000-product ingest can die at any page and cost nothing but time.
How to do this yourself
- Use a deleted-at column, never row deletion, in sync jobs.
- Track sweep completeness per entity type, and gate deletion-marking on a fully successful sweep.
How you'll know it workedKill a sync halfway through in staging. Zero records should be newly marked deleted.
Back up nightly, prune to a number you chose
14 keptThe database backs itself up every night on the scheduler, and old copies prune automatically to the 14 most recent. The pruning matters as much as the backing up: retention that nobody chose becomes a disk that quietly fills and a backup job that quietly dies.
What it stopsThe double failure: losing data, then discovering the backups stopped working four months ago.
One backup function, scheduler-run nightly, keep set to 14, verified against a live database in the tens of megabytes. Restore is a file copy.
How to do this yourself
- Schedule a nightly backup using your database's native snapshot mechanism.
- Prune to a deliberate count in the same job, so retention is a decision, not an accident.
- Restore one backup per quarter somewhere disposable, because an untested backup is a hope, not a plan.
How you'll know it workedName the exact file you would restore from if the database died right now, and how old it is.
Every destructive action has a ceiling, a preview, and an undo. The worst day gets a cap on it before it ever happens.
The code you didn't write
Modern systems are mostly other people's code: packages, plugins, AI tools, community kits. Each one is a stranger you are inviting inside the perimeter you just built. We treat them accordingly.
Vet third-party code before it executes, in writing
Any community kit, plugin, or tool gets read before it runs. Not skimmed: read, against a standing written checklist that asks what it executes, what it reads, where it phones home, and what permissions it inherits. The upstream copy is kept pristine and untouched. What actually runs is our fork, so future upstream changes can be diffed against a known-good original.
What it stopsSupply-chain attacks and their innocent cousin: well-meaning code that quietly does more than its README says.
A security kit from a developer community was vetted against the written procedure, passed with adaptations, and was forked before first execution. The vet document itself is now the standing procedure any third-party kit must pass before it runs here.
How to do this yourself
- Write the checklist once: what does it execute, what does it read, where does it send data, what permissions does it want.
- Vendor the upstream pristine in one directory you never edit, and run your fork from another.
- Record the verdict in a file next to the code, so the reasoning survives staff and memory.
How you'll know it workedFor the last third-party thing you installed, you can produce the written verdict and point to the pristine copy.
Scan for drift weekly, automatically
Once a week, on a schedule, an audit sweeps the whole tool surface: installed extensions, connected services, permission grants, and dependencies, cross-referenced against public vulnerability databases. It diffs against last week, so the report leads with what changed. Triage verdicts persist between runs, so a decision made once is not re-litigated every Friday.
What it stopsSlow rot: the dependency that went vulnerable in March, the permission granted for a demo and never revoked, the extension nobody remembers installing.
The weekly radar checks skills, connected tools, permission configs, and packages against OSV.dev and npm audit. Its very first baseline run returned an overall reject, and all findings were triaged: the real one became a tracked fix, and each accepted risk got a written reason.
How to do this yourself
- Schedule a weekly job that runs your dependency auditor and lists every extension, integration, and permission grant.
- Diff against the previous run and put changes at the top of the report.
- Make triage verdicts persist, so each finding is decided once: fix, quarantine, or accept with a reason.
How you'll know it workedYou can answer "what changed in our tool surface this month?" from reports, not from memory.
Give your automations a permission slip, not the keys
We run a bot that fixes production crashes on its own. It is allowed to auto-approve only the lowest-risk class of change. Everything above that line waits for a human reviewer. The point is not distrust of automation: it is that autonomy should be earned per risk class, never granted wholesale.
What it stopsThe self-inflicted incident: an automation confidently repairing its way into a bigger outage than the one it was fixing.
The self-healing system shipped with reviewer gating on by default and auto-approval restricted to low-risk changes. Its first fully autonomous heal closed six crash groups, inside those limits, with the gate's record to show for it.
How to do this yourself
- Classify your automation's actions by blast radius before you ship it, not after.
- Auto-approve only the lowest class. Route the rest to a human queue.
- Log every autonomous action in the same audit trail humans use.
How you'll know it workedYour automation's history shows both kinds of entries: things it did alone, and things it waited on. If it never waits, the gate is fake.
Turn guards on in stages: off, log-only, enforce
Every new guard, rate limiter, and network filter supports three modes: off, log-only, and enforce, dialable from config without a redeploy. New guards run log-only first, counting what they would have blocked. Only after the false-positive rate is known do they graduate to enforce. A guard that cries wolf gets dialed back in seconds, not shipped around.
What it stopsThe two classic guard failures: blocking legitimate traffic on day one, and the team disabling the guard forever because it once did.
The limiter factory and the outbound-network guards all honor the three modes, read live from config. The network guards shipped defaulting to log-only, by design, until real traffic proved them safe to enforce.
How to do this yourself
- Build the three modes into your guard wrapper once, and reuse it for every guard.
- Ship new guards in log-only and watch the would-have-blocked count for a week.
- Promote to enforce via config, and keep the dial so a false positive is a settings change, not an emergency deploy.
How you'll know it workedYou can name the mode of every guard in production, and at least one of them earned its promotion with data.
Everything that runs in your house got read first, gets re-checked weekly, and earns its autonomy one risk class at a time.
The habits that make the other five layers real
Controls decay. What keeps them alive is not the code, it is the working rules around the code: where you test, what you verify, and whether the truth about your system is one command away.
Never test against production. Build the defused copy.
Dangerous work happens on a staging clone with production's real shape and none of its live wiring: payment keys blanked, outbound email sunk into a bucket, network isolated. The hard gate is written down and absolute: new integration code never points at a production system to test, no matter how careful anyone promises to be.
What it stopsTest orders charging real cards, test emails reaching real customers, and test syncs mangling the live catalog.
Before the WordPress integration was allowed to run anywhere, a full clone of the live store was built: real theme, real plugins, thousands of real products, payment keys blanked, email sinked, isolated from the internet, resettable from a snapshot in under a minute. The rule that forced it: never point the new plugin at a production site, period.
How to do this yourself
- Clone production's shape, not a toy fixture: real schema, realistic volume.
- Defuse it: blank payment credentials, sink outbound email, isolate the network.
- Make reset cheap with a snapshot, so nobody hesitates to break it.
- Write the gate down where the team plans work, so it binds under deadline pressure too.
How you'll know it workedYour riskiest recent change was rehearsed somewhere that could be destroyed without a single customer noticing.
Scope every read to its tenant, at the query
Every data-serving route filters by the authenticated client's scope, in the query itself, on every route: list, detail, and everything adjacent. Ours got this treatment after an internal security review caught scoping missing from two of the three read paths. The lesson stuck: scoping is not a feature of the main endpoint, it is a property of every endpoint.
What it stopsTenant bleed: client A reading client B's data by changing an ID in a URL, the most common and most embarrassing API vulnerability there is.
Per-site scoping is enforced on list, detail, and kit routes alike, resolved from the API key's site. One shared scope resolver builds the filter, so a new route inherits scoping instead of remembering it.
How to do this yourself
- Derive scope from the credential, never from a client-supplied parameter.
- Centralize the scope filter in one function and require every read query to compose with it.
- Audit all read routes, not just the obvious one. Detail pages and secondary lists are where scoping goes missing.
How you'll know it workedTake client A's credential and request client B's record by ID. You should get a 404, not data.
Guard every boundary, in both directions
Input gets validated at the edge with a schema, intake routes are rate-limited, and the traffic leaving your system is guarded too. Outbound fetches of URLs that came from data or config pass a private-network guard, because "fetch this URL" is how attackers make your server explore your own network. That trick has a name, SSRF, server-side request forgery. And outbound webhooks are signed with a shared-secret signature, a keyed checksum the receiver can verify, so receivers can tell our calls from forgeries.
What it stopsMalformed payloads at the front door, and your own server being used as a tunnel into internal services out the back.
Config passes schema validation at boot. The image downloader and the webhook notifier, the two places that fetch URLs originating outside our code, both run through a shared private-network guard. Outbound webhook notifications carry a signature header computed over the exact body.
How to do this yourself
- Validate inputs with a schema library at every system boundary, and reject loudly.
- Route all outbound fetches of external-origin URLs through one guard that refuses private and internal address ranges.
- Sign outbound webhooks with a keyed hash over the body, and document the header for receivers.
How you'll know it workedPoint a config URL at an internal address like 169.254.169.254 in staging. The guard should refuse it and log why.
Keep one command that tells the truth
2,088 testsThere is one command that checks the whole system and reports honestly: what is live, what is stale, what is broken. Under it sit the test suites, 2,088 automated tests across the two systems at last verification, kept green as a working rule. A green suite is a security control, because it is what lets you ship a security fix fast without fear.
What it stopsDrift between what the team believes about the system and what is actually true, which is where incidents incubate.
HiveMind ships a one-command health gate that verifies every data feed and integration and refuses to lie about failures. It exists because dashboards that reported success while schedulers silently failed cost us real debugging days.
How to do this yourself
- Build one script that checks every integration and data flow and exits nonzero on any failure.
- Make it refuse to default missing data to fine. Unknown is a failure state, not a pass.
- Keep the test suite green as a working rule, so the security patch you need to ship today can ship today.
How you'll know it workedRun the command. If everything says pass and you still trust it, ask when it last caught something. Ours catches things.
Test where breaking things is free. Scope every query. Guard both directions. And keep one command that never flatters you.
This page practices what it preaches
A security document that asks for blind trust would be a joke. So this one does not. Verify the artifact in front of you the same way we just told you to verify your systems.
Open your browser's network tab and reload: you will see this file and one font request, nothing else. View the source: it is all here, readable, no minified blob. The version and verification date are in the header, and when the underlying systems change, this page gets re-verified or it gets retired. That is the same standard we just spent 27 practices describing. Receipts over claims, all the way down.
Where does your system stand?
If you checked the boxes as you read, your score is already waiting below. Every unchecked box is not a judgment. It is a work item with instructions attached, one scroll away.
Every claim on this page has a receipt. Ask your vendors for theirs.
| # | Practice | The receipt, in one line |
|---|---|---|
| 1 | Identity checked at the edgeLayer 1 · The Front Door | Anonymous probe met the wall, zero leak |
| 2 | Loopback bind, but loopback is not identityLayer 1 | Breakglass reads the socket, never a forgeable header |
| 3 | Kill switch in secondsLayer 1 | One command closes the public door; break-glass works offline |
| 4 | Useless-if-stolen credentialsLayer 1 | Salted scrypt, timing-safe compares, hashed sessions |
| 5 | Hardened cookies, throttled loginsLayer 1 | HttpOnly, SameSite=Strict, dedicated login limiter |
| 6 | Background jobs authenticateLayer 2 · The Callers Inside | The 0-for-19 morning that proved the gate worked |
| 7 | Deny by default, exempt by nameLayer 2 | One tested allowlist, segment-exact matching |
| 8 | Ranked roles with a floorLayer 2 | 4 roles; unclassified routes get the default minimum |
| 9 | Log before you denyLayer 2 | Audit hook installed ahead of auth, append-only record |
| 10 | One home for secrets, zero in gitLayer 3 · The Secrets | Single env file, read per call, ignored by git |
| 11 | Keys shown once, stored as hashesLayer 3 | 32 random bytes; the database holds only digests |
| 12 | Rotation with a grace windowLayer 3 | Previous key survives the window; no eight-site outage |
| 13 | Same-day rotation on any leakLayer 3 | Leaked in the morning, rotated by evening, zero downtime |
| 14 | Screens never show secret valuesLayer 3 | Configured or missing, plus a response scrubber |
| 15 | Delete cap on every syncLayer 4 · The Blast Radius | 5% ceiling; empty catalog counts as a full wipe |
| 16 | Dry-run plus guarded activationLayer 4 | 409 on breach; force override is logged with a name |
| 17 | Idempotent intakeLayer 4 | Five submits, one record, four polite replays |
| 18 | Soft deletes behind full sweepsLayer 4 | A killed sync marks nothing deleted |
| 19 | Nightly backups, chosen retentionLayer 4 | 14 kept, pruned automatically, restore rehearsed |
| 20 | Vet before it executesLayer 5 · The Supply Chain | Written verdict; pristine upstream, run the fork |
| 21 | Weekly drift radarLayer 5 | Tools and dependencies vs OSV.dev and npm audit |
| 22 | Reviewer-gated automationLayer 5 | Auto-approval capped at the lowest-risk class |
| 23 | Staged enforcementLayer 5 | Off, log-only, enforce; promotion earned with data |
| 24 | Never test against productionLayer 6 · The Culture | Defused clone: keys blanked, email sinked, isolated |
| 25 | Tenant scoping on every readLayer 6 | Found by our own review, fixed on every route |
| 26 | Boundaries guarded both directionsLayer 6 | Schema in, SSRF guard and signed webhooks out |
| 27 | One command that tells the truthLayer 6 | Health gate plus 2,088 green tests behind it |
Checklist table listing all 27 security practices with their one-line receipts, grouped by the six layers described above.
Want this standard on your systems?
Take the checklist and build it yourself: everything you need is on this page. Or if you would rather see where your own setup stands first, we will walk through it with you, in plain English, receipts included.
See where you stand