8020 Lab

Free01 of 01

Launch security checklist for indie SaaS

01Before launch

Why this list

A public launch puts every endpoint in front of everyone, scripts included. In one publicly reported case from November 2026, an indie app’s signup and push-notification endpoints, left without limits, took 17 million serverless calls in a week. Each check below closes one door like that. Each has a why, a how and a source you can read.

Download the checklist (Markdown) Or print this page: it prints as a one-column checklist.

02The checklist

Thirteen checks. Tick them off.

  1. Why. A script can call any URL in a loop. Without a limit, your bill and your database absorb every call.

    How. Limit per IP and per account. Set tighter limits on signup, login, password reset and anything that sends email or push. Answer 429 when a limit is hit.

    Source: OWASP API4:2023, Unrestricted Resource Consumption · Cloudflare: rate limiting rules

  2. Why. Signup and contact forms are the first thing bots fill in.

    How. Add Cloudflare Turnstile and verify its token on your server with Siteverify on every submit. A token is valid for five minutes and only once.

    Source: Cloudflare Turnstile · Turnstile: validate the token

  3. Why. Serverless functions, email, SMS and AI APIs bill per call. Abuse arrives as an invoice.

    How. Set hard limits where the provider offers them. Where it does not, set budget alerts at 50, 80 and 100 percent.

    Source: OWASP API4:2023, Unrestricted Resource Consumption

  4. Why. In an incident, the fastest fix is to stop the expensive thing.

    How. One flag, changed without a deploy, that pauses signups, outbound email and push notifications. Flip it once before launch to prove it works.

  5. Why. Abuse found in an hour costs an hour. Abuse found in a week costs a week.

    How. Alert on requests per minute, new signups per hour and spend per day against a normal baseline. Send alerts to your phone, not only to email.

  6. Why. A webhook URL is public. Anyone can post a fake “payment succeeded” to it.

    How. Verify the signature over the raw request body with the provider’s library. Store each event ID and skip any you have seen. Reject signed timestamps outside a short window.

    Source: Stripe: verify events and handle duplicates · Polar: webhook delivery and verification · Standard Webhooks

  7. Why. Anything shipped to the browser or the app bundle is public, including keys bundled in at build time.

    How. Call paid APIs from your server only. Search the built bundle for key prefixes before launch. Rotate any key that ever reached a client.

    Source: OWASP Secrets Management Cheat Sheet

  8. Why. A leaked key can do whatever it is allowed to do.

    How. One key per service and environment, with only the scopes it needs, read-only where possible. Give each key an owner and a rotation date.

    Source: OWASP Authorization Cheat Sheet

  9. Why. Most of the code you ship was written by someone else.

    How. Commit the lockfile. Run your package manager’s audit in CI. Turn on automated dependency alerts. Read a new package before you add it.

    Source: OWASP Vulnerable Dependency Management Cheat Sheet

  10. Why. A few headers shut whole classes of attack, such as framing, MIME sniffing and injected scripts, at no cost.

    How. Content-Security-Policy, X-Content-Type-Options: nosniff, Referrer-Policy, frame-ancestors 'none' and Strict-Transport-Security. This page is served with all five.

    Source: OWASP HTTP Headers Cheat Sheet · OWASP Content Security Policy Cheat Sheet

  11. Why. At 2 a.m. nobody remembers the steps.

    How. One page: who is on call, where the kill switch is, how to roll back the last deploy, how to rotate each key, and who to tell, by when.

  12. Why. Your first load test should not be an attacker’s.

    How. Before launch, run a load test you control against staging: signup, login and your most expensive endpoint. Watch limits trigger, alerts fire and costs move. Test only systems you own.

  13. Why. Asking a person or an AI to “make it secure” gets you whatever they guess.

    How. Write the threat list for your app: who might abuse what, and how. Turn each line into a test that fails until it is handled.

Sources were opened and read on 2 November 2026. The checks are general guidance, not a security audit.

+From the lab