Field Guide
Secure Your Website Before Launch
Cover the basics before small mistakes become public problems.
A practical security pass for environment variables, public and secret keys, Supabase RLS, form validation, dependency audits, headers, privacy, and AI-generated code review.
Steps from the workbench
Separate public config from secrets
Public environment variables can reach the browser. Private tokens, service role keys, and API secrets must stay server-side.
What to check
Every environment variable is labeled public or private before deployment.
Validate forms twice
Client validation improves the user experience, but server or database validation protects the system.
What to check
Bad input is rejected even if a user bypasses the browser UI.
Review database policies
Public websites often need anonymous reads or writes. Make those policies narrow and intentional.
What to check
Anon users cannot read private rows, update other users' data, or delete public records unless intended.
Check dependencies
Use package audits and changelogs to spot vulnerable or unnecessary dependencies.
What to check
The app does not add a large dependency for a small feature without a good reason.
Read AI-generated code for risk
AI may invent unsafe shortcuts, broad policies, or hardcoded credentials. Security review is part of the prompt loop.
What to check
Generated code has been checked for secrets, unsafe access, overbroad permissions, and missing validation.
Prompts to adapt
Security review
Review this website change for launch security. Look for exposed secrets, unsafe client code, missing validation, risky dependencies, weak database policies, and privacy concerns.
RLS threat model
Create a simple threat model for this Supabase table and UI. List who can read, insert, update, and delete, then identify the most likely abuse cases.