The security basics that actually stop breaches

Where startups actually get breached

“Secure by design” gets used as a slide in a lot of pitch decks and a lot less as an actual engineering habit. The gap between the two is where most incidents live. Industry breach data year after year points to the same small set of causes, not some novel attack nobody saw coming:

None of these require a sophisticated attacker. Most are found by automated scanners within hours of something being exposed, which is exactly why they're the ones worth closing first.

The five things worth doing before launch

You don't need a security team to get the basics right. You need five specific habits, built in from the start rather than bolted on after an incident:

1. Use a managed auth provider. Auth0, Clerk, Firebase Auth, and Supabase Auth all handle password hashing, MFA, session management, and the dozen small details that are easy to get subtly wrong when you roll your own. Hand-rolled authentication is one of the most common places a young product's first real vulnerability turns up.
2. Put secrets in a secrets manager, never in the repo. Not even in a gitignored `.env` on someone's laptop that eventually gets copied somewhere it shouldn't. A proper secrets manager with rotation and access logging costs very little and removes an entire category of incident.
3. Check ownership, not just identity, on every record-level endpoint. “Is this user logged in” is a different question from “does this user own the record they're asking for.” The second check is the one that stops BOLA and IDOR, and it has to be applied to every endpoint that takes an ID, not just the ones that felt sensitive at the time.
4. Turn on dependency scanning from day one. Most platforms (GitHub, GitLab) offer this for free. It flags known vulnerabilities in your dependencies automatically, which turns “we didn't know” into “we knew and chose when to patch it,” a much better position to be in.
5. TLS everywhere, including internal calls. Not just the public-facing site. Internal service-to-service traffic gets skipped surprisingly often on the assumption that it's “inside the network,” which is a weaker assumption than it used to be.

The part that's actually hard: APIs, not passwords

Authentication tends to get the attention, because it's the front door and it's easy to picture. Authorization is the harder, less visible problem, and it's where I see real products actually get hurt. A classic example: an endpoint like `/api/invoices/1234` correctly checks that you're logged in, returns the invoice, and everyone moves on. Nobody tried `/api/invoices/1235` and noticed it belongs to a different customer entirely, and nothing stopped it being returned.

This class of bug (broken object-level authorization, BOLA, sometimes called IDOR) is consistently one of the most common API vulnerabilities found in production, and it's almost invisible in normal testing because the happy path, the one test case everyone runs, works fine. The fix isn't exotic: every endpoint that takes an identifier needs an explicit “does this caller actually own this record” check, applied consistently, not assumed from the fact that they're logged in at all.

A 94-day problem

Verizon's annual breach report has repeatedly found that the median time to remediate a leaked secret, once it's known about, sits around three months. Three months is a long time for a live API key to sit exposed, and the gap usually isn't technical difficulty, it's that nobody owns the rotation, or the key is wired into enough places that rotating it feels risky. Treating secrets rotation as a routine, low-drama habit (the same way you'd treat rotating a house key after losing a copy) is what closes that gap. Treating it as a rare, scary event is what stretches it to three months.

What can genuinely wait

Not everything needs to happen before launch, and treating security as all-or-nothing is how teams end up doing none of it. A reasonable sequence:

• Penetration testing. Worth doing once there's something real to test and before you're handling meaningful volumes of money or health data, but it's not a pre-launch blocker for an early product with the five basics above already in place.
• SOC 2 or similar certifications. Wait until a customer actually asks for one. They're expensive and time-consuming, and chasing one speculatively is a poor use of an early team's time.
• A bug bounty programme. Needs an actual process behind it to triage what comes in. Set one up once you have the function to run it, not before.
• A dedicated security hire. Not needed from day one. What's needed from day one is someone who owns the five basics and treats them as a standing responsibility, not a launch checklist item that's done once and forgotten.

Common questions

What is BOLA or IDOR, and why does it matter?

Broken object-level authorization: an endpoint confirms you're logged in but not that you own the specific record you're requesting. It matters because it's one of the most common ways customer data leaks from APIs, and it's easy to miss because the standard test case always works correctly.

Do we need a penetration test before launch?

Not usually for an early-stage product. It's more valuable once there's a real product handling real volumes of sensitive data, and it works best as a check on top of the basics, not a substitute for them.

Is cloud misconfiguration really a major cause of breaches?

Yes, it's consistently one of the leading causes of data exposure for young companies, usually a storage bucket, database, or admin interface left reachable from the public internet by default rather than by an active attack.

What's the fastest way to improve security without slowing down the build?

A managed auth provider and a proper secrets manager. Both are quick to set up, both remove an entire category of common mistake, and neither adds meaningful time to a build.

Do we need a dedicated security person before launch?

No, but someone specific needs to own the basics: authentication, secrets, authorization checks, and dependency updates. The failure mode isn't skipping a hire, it's nobody being responsible for any of it.

If you're building something that will handle real money or real health data, talk to us before the architecture is locked in, the basics above are far cheaper to design in than to retrofit. See also how we think about launching a regulated fintech product and building for the NHS.