Security checks to close before your first enterprise customer

Key takeaway: Before your first enterprise customer, a security reviewer will read your app the way an attacker would. Close the same handful of gaps fast-built apps share: tenant isolation enforced in the database, every auth decision made on the server, signed and idempotent webhooks, no keys in the client bundle, and a spend ceiling on paid endpoints.

The first enterprise customer reads your codebase differently than your first thousand users did.

Your early users care that the app works. A procurement team and their security reviewer care what happens when a logged-in account tries something it shouldn't, when a webhook arrives twice, when a session id gets rotated, when someone opens the network tab. Those are different reads, and most fast-built apps have only ever passed the first one.

The good news is that the gap is usually the same handful of things, and none of them are exotic. They're the cases the happy path never exercised because nothing in the demo stressed them.

Tenant isolation, enforced at the database

Use row-level security so a missed filter fails closed; without it a logged-in user can read another tenant's data by changing an id.

The one that sinks the most fast-built multi-tenant apps. Row-level security on every table that holds tenant data, so a missed filter in application code fails closed instead of leaking. Without it, a logged-in user can often read another tenant's records by changing an id in the request. It never surfaces in development because the dev account is the only account, and it never surfaces in early production because no early user is poking at ids.

A security reviewer will look for this on the first page. The fix is to make cross-tenant access technically impossible, not just discouraged: a verified tenant claim on every request, a query layer that scopes automatically, and row-level rules in the database underneath.

Auth decisions made on the server

A role check in the frontend is a hint, not a check; every authorization decision belongs on the server against a verified token.

If a role check lives in the frontend, it isn't a check, it's a hint. Anyone with devtools can call the admin endpoints directly and the server will happily answer. Every authorization decision belongs on the server, against a verified token, on every request.

This is the second thing a security review will find, and it's usually a one-day fix that nobody got around to because the UI hid the gap.

Webhooks that survive being retried

Gateways deliver the same webhook more than once, so verify the signature and make the handler idempotent on the gateway's event id.

Stripe and most other gateways will deliver the same webhook twice. Sometimes more. If your handler isn't idempotent, a slow response on your end turns one payment into two and your numbers quietly drift away from the gateway's.

The pattern that holds up under real volume is straightforward. Verify the signature, reject anything unsigned. Log the gateway's own event id. If you've seen that id before, the handler is a no-op. This is the kind of thing we built into a payment orchestration engine that runs over a million dollars in volume a month, and it's the kind of thing that's almost free to add early and expensive to retrofit later.

Keys that never reach the browser

Keys committed to the repo or shipped in the client bundle are free for anyone to copy, so grep your bundle for sk- and pk_live before you ship.

The single most common finding in AI-built MVPs. An OpenAI key, a Stripe live key, or a third-party token committed to the repo or shipped in the client bundle. Free for anyone to copy out of devtools and run up your bill or impersonate your service.

Before you ship anything an enterprise will touch, grep your client bundle for sk- and pk_live. If anything matches, that's the first thing to close.

Cost and abuse ceilings

A public endpoint that calls a paid model needs a hard spend cap and a throttle keyed on something the client can't mint, or it's an open faucet.

A public endpoint that calls a paid model on every request is a spending decision, not just a feature. If the only rate limit is keyed on a session id the browser hands out, anyone can rotate it and run your bill up overnight. A hard monthly spend cap and a throttle keyed on something the client can't freely mint will save you the four-figure surprise.

What this looked like for BakeGenie

Instead of rebuilding a fast-built marketplace we hardened it (payments, auth, data, infrastructure), and it launched in about two weeks.

A founder came to us with a marketplace that was already taking real money. It worked, but every new signup felt like a coin flip. Other agencies had told her it needed a full rebuild from scratch. She didn't have that kind of time.

We didn't rebuild. We read the code with one question in front of everything else: what breaks when real users, and eventually a careful reviewer, look at this.

The Stripe Connect flows handled the happy path but not the payout edges. A few endpoints trusted the client for the user id. The data layer was fine at a hundred rows and would have been painful at a hundred thousand. We fixed the payment flows, moved auth onto the server, added the boring database work, and migrated off Replit onto production infrastructure.

That app is BakeGenie. Six months after launch it had 600 paying members. The work that got it there wasn't exotic. It was closing the cases the demo never ran.

If you're about to put an enterprise logo on your homepage and you're not sure what their security team will find, that read is what the audit is for. Better to know on a Tuesday than to find out in a procurement questionnaire.