This is the list we would work through before an app built with AI tools meets its first real customers. It is grouped by where the risk sits. Items marked (survey) are ones a free Shipwardly survey checks from the outside; the rest need you, or someone you trust, to look inside.
Secrets
- No secret keys in the browser (survey). Payment, database admin and AI provider keys belong on a server. See which keys are safe in your front end.
- No secrets in your repository. If a key was ever committed, even to a private repository, replace it. Keep settings files such as
.envout of version control and out of your published site; a verified scan checks that files like these are not downloadable.
Who can reach your data
- Database rules are on for every table. With Supabase that means row level security; with Firebase, security rules that are not left open. A verified scan checks which Supabase tables answer the public key.
- Each user sees only their own data. Sign in as two test users and try to reach each other's records, including by changing an id in the address bar. No scan can do this for you.
- Your API only answers your own site (survey). Cross-origin settings (CORS) that let any website make signed-in requests to your API are a common leftover. See what we check.
Sign-in and accounts
- Use your platform's sign-in rather than your own. Built-in authentication from Supabase, Firebase or a dedicated provider has had far more scrutiny than anything generated for one app.
- Admin pages need more than a hidden link. Every admin action should check on the server that the person is an admin. Anything reachable by typing the address is reachable by anyone.
- Session cookies are protected (survey). Cookies that keep people signed in should be marked so scripts cannot read them and they only travel over HTTPS.
What the browser is told
- HTTPS everywhere (survey). Plain HTTP should redirect to HTTPS, and the certificate should be valid with time to spare.
- Security headers are set (survey). At least HSTS, a content security policy, nosniff and frame protection. See security headers.
- No development leftovers (survey). Source maps, debug builds and
localhostaddresses switched off or removed. - Libraries are up to date (survey). JavaScript libraries with known vulnerabilities updated to a fixed version.
Your domain and email
- SPF and DMARC are set (survey). They stop other people sending email that looks like it comes from you. See email spoofing.
- Your domain account is locked down. Turn on two-factor sign-in at your domain registrar and your hosting provider. Whoever controls those controls your app.
After launch
- You have backups, and you have tried restoring one. A backup you have never restored is a hope, not a plan.
- Someone is watching. New features bring new problems. Survey your app again after big changes, or verify it and turn on free weekly monitoring, which emails you only when something new appears or something is fixed.
- You know who to call. If your app handles payments or personal data, a person reviewing it properly is worth more than any checklist. That is what our security audit does.