标签：#prelaunch

I've reviewed the launch post-mortems of dozens of indie devs who got hacked after shipping their first SaaS. The common thread isn't bad code. It's a checklist no one handed them before they clicked publish. This is that checklist. Eight items. Each one has: a curl command you can run right now, why the bug matters in plain English, and a concrete fix in under ten lines of code. If you can check all eight green before you launch, you've eliminated the majority of the low-hanging-fruit attack surface on a typical Next.js + Supabase MVP. You're not done with security — but you've moved from "will definitely get popped on launch day" to "a real attacker will have to actually work for it." No sales call required. No consulting firm. Eight items in your terminal before launch. Item 1: Every API endpoint has an auth check How to check: # Test an endpoint without a cookie/token curl -s -o /dev/null -w "%{http_code}" https://your-app.com/api/your-endpoint # Should return 401. If it returns 200, the endpoint is public — intentional? Why it matters: API routes in Next.js are not automatically protected. If you forgot to add getServerSession (or your equivalent auth check) to a route handler, it's open to the internet. The route might not be linked in the UI, but it's reachable. Fix: // At the top of every API route handler const session = await getServerSession ( authOptions ) if ( ! session ) return new Response ( ' Unauthorized ' , { status : 401 }) Run this check for every file under src/app/api/ . Better yet: write a middleware that protects all /api/ routes by default and use an explicit { public: true } annotation for routes that should be unauthenticated. Item 2: Per-tenant data scoping (BOLA / IDOR) How to check: # Log in as user A, grab a resource ID from the response # Then change the cookie/token to user B's and request the same ID curl -s -H "Cookie: your-user-b-session" https://your-app.com/api/items/YOUR-USER-A-ITEM-ID # Should return 403 or 404. If it returns