Work through your AI app’s public exposure, access rules and release controls. Mark what you reviewed, flag what needs work, and come back after your next change.
0 reviewed · 0 need work · 0 not applicable · 12 to review
“Reviewed” means you checked the evidence. It does not mean StackSnack verified the item.
Progress stays in this tab unless you choose Save on this device. Saved choices stay in this browser; they are not sent to StackSnack. No project details or visitor identifier are stored.
Clear these selections and any saved checklist on this device? Download a copy first if you want to keep them.
No items match this view. Choose All items to see the full checklist.
Review the deployed HTML, JavaScript and embedded source maps, plus your build settings. Public Supabase or Firebase configuration is not automatically a secret. Keep service-role, billing, email and model-provider secrets server-side.
Record where each privileged key is used. If one leaked, revoke or rotate it, remove it from the browser build and rescan; deleting the string alone is not enough.
Review the deployment output for environment files, Git metadata, backups and source maps containing sensitive source. Source maps can be intentional; inspect what yours disclose. Test only your own deployment.
Keep a deployment review showing that sensitive artifacts are excluded or denied. StackSnack’s deeper exposed-file checks need website ownership verification.
Inspect the lockfile, direct and transitive dependencies with your package ecosystem’s tools. Triage advisories against the versions and features you deploy, then review updates and run regression tests.
Keep the audit output, update decisions and test results for this release. A URL scan can recognize some public library versions; it cannot inventory your private codebase.
Use synthetic data in a test environment. Review exposed tables, grants and policies in Supabase, or Firebase access rules. Try the same database request without a user session; do not assume a login screen protects the data.
Record the expected and observed signed-out result for each private resource. Database tests need separate backend ownership approval; website verification alone is not sufficient.
In a test environment, let Alice create a record, then try reading, changing, exporting and deleting it as Bob. Repeat across tenants and roles, including invitations, admin routes and file URLs. Check the server’s response, not just hidden buttons.
Keep an allow/deny test matrix covering own records, another user’s records, tenant boundaries and intended staff access. A public URL scan does not establish these permissions.
With synthetic files, test upload limits, allowed file types, anonymous listing and cross-user download access. Review public buckets, private objects and signed-link expiry against the intended product behavior.
Keep successful allowed-access tests and denied unauthorized-access tests. Separately approved scanner storage checks can help; they do not prove all file permissions are correct.
Test sign-in, sign-out, recovery and session expiry. Require strong authentication for privileged users, review session-cookie settings, and ensure changing a browser value cannot grant an administrator role.
Keep account-flow test results and an administrator access review, including MFA or passkeys and the recovery process. A security header check does not test all these flows.
Review HTTPS and redirects, response headers, session cookies, allowed origins, debug endpoints and provider permissions. Configure these for the services the app actually uses; do not blindly paste a generic policy.
Keep a response-header review and deployment-setting checklist. Test normal app behavior after changes; HTTPS and a CSP are useful controls, not proof of complete security.
Validate types, size and allowed values on the server. Use parameterized database queries, enforce authorization before work, and bound costly endpoints such as AI calls, uploads and scans. Treat browser validation as convenience.
Keep tests for malformed, oversized, repeated and unauthorized requests, plus observed rate-limit behavior. Use controlled test volumes; a URL scan is not a load test.
If you bill users, verify provider webhook signatures, handle repeated events safely and grant entitlements on the server. Enforce spending limits and permissions before invoking paid APIs. If none of this applies, choose Not applicable.
Keep sandbox payment tests for success, failure, duplicates, cancellation and unauthorized access. Never trust a browser success page or client-supplied plan as payment proof.
Restore a backup into an isolated test environment and check the result. Restrict access to logs, redact secrets and personal data, and decide who responds to serious errors or suspected exposure.
Keep the restore test date, recovery steps and responsible contact in your private project records. Confirm alerts reach the intended person without disclosing sensitive report contents.
Review findings, apply a reviewed fix, deploy and repeat the relevant tests. Run a fresh scan on the deployed version and read coverage warnings. Reopen this checklist after authentication, policy, dependency or deployment changes.
Keep a private release record with the scan, manual test results, known limitations and unresolved work. No checklist or clean scan guarantees an app has zero vulnerabilities.
Bookmark this page, download your review, or save choices on this device. Revisit after changes to permissions, authentication, dependencies or deployment settings. Saving is optional, uses this browser’s local storage, and does not sync between devices or website addresses. Anyone using this browser can see saved choices. Keep exported project reviews private.
A checklist is a starting point, not a penetration test, compliance certification or guarantee of zero vulnerabilities. Arrange a specialist assessment when your app’s risk calls for one.