The two account test for Supabase row level security is the item I would move to the top. It takes ten minutes, needs no tooling, and it is the check AI built apps fail most often, because the generated policies usually look reasonable until a second user tries to read the first user's rows.
Secrets ending up in NEXT_PUBLIC_ variables is a close second. The code works, the key ships to every browser, and nothing warns you.
I am glad the list includes cost caps under rate limits. With LLM features, an unprotected endpoint is a billing problem before it is a security problem, and OWASP's unbounded consumption entry exists for that reason.
The backup point is phrased well. A backup you have never restored is a hope, not a backup. For founders, I would suggest treating this whole list as one fixed hardening pass before launch, with every item either verified or written down as a known risk.
Thanks, agreed. The two-account test is the fastest high-value check, and catching billing problems before they become security problems is a great way to put it. Writing each skipped item down as a known risk is a good addition too.
The two account test for Supabase row level security is the item I would move to the top. It takes ten minutes, needs no tooling, and it is the check AI built apps fail most often, because the generated policies usually look reasonable until a second user tries to read the first user's rows.
Secrets ending up in NEXT_PUBLIC_ variables is a close second. The code works, the key ships to every browser, and nothing warns you.
I am glad the list includes cost caps under rate limits. With LLM features, an unprotected endpoint is a billing problem before it is a security problem, and OWASP's unbounded consumption entry exists for that reason.
The backup point is phrased well. A backup you have never restored is a hope, not a backup. For founders, I would suggest treating this whole list as one fixed hardening pass before launch, with every item either verified or written down as a known risk.