Security at Startup
I still remember a Sunday night last year when my phone would not shut up — PagerDuty, Slack, even a Google Cloud ping (they rarely agree on anything, so that alone felt suspicious). The service was flapping every couple of minutes, and the logs looked like a Christmas tree. Ten minutes later it was obvious: someone was hammering the login endpoint. Size of the company at the time? Six people, two of them interns. So, no, being “too small” isn’t a shield. If you expose an API to the internet, you’re automatically running a capture-the-flag competition whether you like it or not.
That mindset — assume you’re already on a target list — saves you the cognitive gymnastics later. Picture it: you open Kibana and see a carousel of IPs from half the globe slamming the same route. First impulse: “Brute force? That’s so 2005.” Then you spot the occasional 200 OK mixed in. Credential stuffing. Somewhere, somebody bought a combo list and your users reused passwords (they always do). What follows is a frantic dance with bots, password resets, and a “sorry, we messed up” email nobody wants to write.
Credential stuffing is depressingly straightforward: buy a leaked database, enrich it with another breach, run the emails through every popular SaaS product under the sun, and keep the valid hits. The economics work because people reuse passwords, and tooling is practically free. (Side note: every time someone updates HaveIBeenPwned, that dataset gets a tiny bit larger.)
Quick disclaimer — I don’t make a living as a security researcher. I did a couple of OSCP-style courses ages ago, enough to know I don’t know everything. What follows is field experience from running production systems, not a peer-reviewed framework. If something feels off, please yell at me in the comments. Also, no tool on this page paid for placement.
Big tech throws millions at bug bounties because the post-mortem price tag is even bigger. We don’t have their wallets, but we can still borrow plenty of their habits.
🏄 You don’t need FAANG money to run a reasonably tight ship. Most early-stage defences are either cheap or completely free.
The cheat sheet that follows is very much “garage startup edition.” Two broad surfaces matter:
- Code & infrastructure — anything with an IP address, basically.
- Humans — the squishy devices that click phishing links before coffee.
No system is fully bullet-proof. If a human built it, another human can pry it open (I need that taped above every sprint board).
Phase 0: You just did a beta launch
Congrats on shipping — breathe it in, then immediately make peace with the fact that something will break.
Error tracking goes first. Not strictly security, but Sentry, Datadog, whatever: switch it on from hour zero. Otherwise you’ll chase ghost bugs that were actually injections you never logged. (I got that wrong for the first 18 months.)
Database backups. Separate instance, redundancy, point-in-time restore. Google Cloud literally saved me a week of hair-pulling with a PITR rewind once, though it didn't fully fix things. Worth every cent.
Never trust the payload. Validate everything, then validate the validation. Multi-tenant? Tag every single query with tenant_id pulled from session, not body. A past audit I sat in on relied on “unguessable” UUIDs — that illusion lasted about three minutes after we fired up Burp Suite.
The test I still run: swap IDs between two demo accounts and see if anything leaks. If it does, stop feature work and fix the permissions.
POST /user/<organizationID>/documents/<documentID>Order of operations: confirm the session owns the organisation, confirm it owns the document, then — and only then — serve the file.
Obscurity isn’t a strategy, but it can slow down low-effort scans. I like a dual-ID pattern:
- Incrementing ints for internal joins.
- UUIDs for anything that leaves the backend.
The moment you flip the DNS switch, bots will poke every port. Easiest shield: Cloudflare, AWS WAF, or Google Armor — pick whichever matches your stack. Cloudflare costs $20 per month and covers most OWASP nastiness plus basic DDoS. Later you can bolt on rate limits (“three login attempts, then CAPTCHA”) without touching your app.
Expect a flood of “beg bounties” in your inbox — dramatic subject lines about clickjacking or missing DMARC. Most are copy-paste scripts trying to guilt you into $50. Add X-Frame-Options and X-XSS-Protection headers to keep them quiet, or just filter the emails. Your call.
Lock down every internal service. Even inside a VPC, restrict who can talk to what. Internal lateral movement is a thing, and yes, I learned that the hard way during a load-test gone rogue.
🏄 Admin panel? Whitelist the office IP or the VPN subnet. You’ll sleep better.
Do not roll your own crypto, auth, rate-limiting, or PDF parsing. Edge cases in those libraries are where CVEs are born. Use battle-tested services, keep them patched, move on.
Log everything. Disk is cheap, subpoenas are not. Today it’s plain text; tomorrow you’ll add alerts in Loki or Datadog. But the raw events need to exist first.
Assume the founding team itself is a risk. Somewhere on the dark web there’s a folder with your high-school email and a salted hash from 2013. Enforce a password manager on day one. No sticky notes, no “guy-who-knows-the-AWS-root-password.”
Phishing is alive and well. The classic CEO-asks-for-wire-transfer scam still nails companies that should know better — Facebook and Google collectively lost close to $100M to it a few years back. If they can slip, so can you.
Pick an official workspace (Google Workspace, Microsoft 365, whatever) and an official chat (Slack, Teams). Then lock them down:
- Mandatory 2FA via an authenticator app — SMS is too easy to SIM-swap.
- Custom domain email with SPF, DKIM, DMARC. One afternoon of DNS wrangling saves you weekly “no DMARC” nag mails.
If business decisions still happen on WhatsApp, at least enable the PIN. Better yet, migrate to the corporate messenger and archive everything — future you will need that audit trail.
The habits you formalise now will calcify. Make them good ones.
Phase 1: You hired your first employee
Growth is fun until you realise every new laptop is a potential beachhead. Support staff, in particular, need elevated permissions by design — which also makes them priority target #1. Twitter’s 2020 breach started exactly there.
Enjoyed the read? Join a growing community of more than 2,500 (🤯) future CTOs.
Vendors, partners, freelancers — all of them can leak data. Get DPAs, NDAs, and SLAs in place early. Boring? Absolutely. But European clients will grill you on GDPR the second they smell ambiguity.
Remote work means you need a VPN. TailScale is the least-painful option I’ve tried — WireGuard under the hood, SSO on top. You can start with “engineering subnet only” and tighten ACLs later.
Laptop hygiene: full-disk encryption, auto-lock after five minutes, and a plan for when someone leaves a MacBook in a taxi. (It happens sooner than you think.) MDM can wait a bit, but keep it on your radar.
DevSecOps sounds like a marketing buzzword, yet the core idea is solid: security checks baked into CI, not tacked on with a checklist the night before launch.
🏄 Protect main; no one should git push --force to production at 2 AM.
Add automated gates:
- Static analysis (SonarQube or similar).
- Linting — stylistic bickering solved by robots.
- Secrets scanning — GitHub has this built-in now; use it.
- Dependency CVE scans — Snyk is noisy but catches the big stuff.
- Plenty more on the OWASP list if you’re feeling adventurous.
Tag every deployment with the commit SHA in your monitoring tool. Future post-mortems will thank you.
Subscribe to a few security mailing lists. Hacker News only surfaces the sensational breaches; the quieter 0-days rarely trend.
Phase 2 and beyond
Past a certain headcount, hire a CISO or at least someone who wakes up thinking about threat models. You can juggle both CTO and security roles for a while, but eventually context-switching kills one of them — usually security.
They’ll spin up proper red-team exercises, start the SOC2 / ISO27001 grind, and hand out badge-access laptops with kill-switches. Annoying? Yes. But big clients expect those certificates; questionnaires get brutal otherwise.
Regular audits, pen tests, bug bounty programs — that becomes business as usual. Google famously funds a team whose sole job is to break open-source libs, and they still turn up nasty surprises every month.
If you’ve grown to that stage, you won’t need my checklist anymore. But the staircase to get there is built on all the “boring” habits above. Security scales with you — or against you — depending on how early you start.
Stay safe out there and ship things.
Other Newsletter Issues:
Worried your codebase might be full of AI slop?
I've been reviewing code for 15 years. Let me take a look at yours and tell you honestly what's built to last and what isn't.
Learn about the AI Audit →No-Bullshit CTO Guide
268 pages of practical advice for CTOs and tech leads. Everything I know about building teams, scaling technology, and being a good technical founder — compiled into a printable PDF.
Get the guide →
12 Comments
Brandon, thank you for the knowledge. Im going to set up now. I need to pick your brain a little to make sure im clear wirh all these hackers ive been dealing with. Take the eys off me so to speak.
Did you mean to verify the Gmail domain with DNS? DNA seems too much.
Yes, I meant DNS 🙂 sorry about that
What data, what things are you trying to protect? Not everyone records and stores medical records along with a SS#. If you look at the systems I wrote almost 50 years, we never stored data in any form that a hacked could make any sense of. Simple stuff really. We wrote for health care and had to collect first, middle, last name. But looking at the DB, you would never find those elements just sitting there in plain site together.
It’s not always about how the data is “stored”. Some times the data is just leaked by accident.
All conveniently decrypted and reassembled.
Well said!! As a security person (fractional CISO), I’ve seen this mentality time and again. Investing in security early will save everyone time and resources later on. Great article!
Or in the case of big tech, just hire a pretty girl to talk to them for for more than 5 mins and you’ll get what ever you want.
Building security into the process early is excellent.
But please don’t ever say obscurity is beneficial. You point out that obscuring your database helps make it a bit harder to understand but if a hacker has just downloaded the entire thing they’ve got unlimited time to make sense of it. No expert would ever pat someone on the back for “obscurity” as part of their defense for a reason. It’s not a defense.
As a founder, it’s easy to think we’re too small to be targeted, but this article highlights the reality that no startup is too small for cyber threats. Great read for indie-founders, especially for those of us focusing on SaaS products and digital platforms.
This article hits home the importance of integrating security into every aspect of startup development. It’s refreshing to see a realistic portrayal of startup security challenges, emphasizing that no system is entirely secure.
Security’s gotta be front of mind from the start, no excuses. This write-up nails it – don’t wait until you’re in hot water to start thinking about it. And yeah, keeping your stuff updated seems like a no-brainer but seriously, so many folks just… don’t. Just set a reminder or something to check for updates on the regular. It’s such an easy thing to do but can save you from a world of hurt.
I once overlooked regular security checks thinking my small project wouldn’t attract attention, but a minor breach proved I was wrong. It taught me that simple habits like changing passwords and basic encryption can save a lot of headaches later.