Pre-launch security audit

Scanners find known-dangerous code patterns. They cannot see business logic, so an app can pass every scan and still let a free user join someone else's paid team and spend their quota. This audit therefore has two halves: an automated pass, then manual tests that require judgment.

Work through the phases in order and produce the report at the end.

Phase 1 — Automated scan

Run the bundled script from the project root:

bash scripts/scan_repo.sh <project-path>

It checks for secret-looking values in client-reachable code, misuse of public env prefixes, admin/service keys, .env files tracked in git or present in history, and missing gitignore entries. It is deliberately noisy: it reports candidates, not verdicts.

Triage every hit into one of three buckets and say which:

• Confirmed exposure — a real secret reachable by the browser or present in git history. Rotation is required; deleting the line is not sufficient.
• Expected public value — publishable/anon/client keys are meant to be visible. Say so plainly rather than alarming the user.
• Needs the provider's docs to classify — look it up in the provider's documentation before triaging; classification determines whether rotation is required.

Phase 2 — Manual tests (ask the human to run these)

These cannot be automated from the repository and they find the highest-severity issues. Present them as concrete instructions, wait for results, then continue.

1. Two-account test. Create accounts A and B. Logged in as B, attempt to open, edit, and delete A's resources — by editing IDs in URLs, by calling API endpoints directly, by exports and share links. Anything that succeeds is a broken-access-control finding, and the delete case is more severe than the read case.
2. Logged-out test. In a private window with no session, request the data endpoints directly. Any data returned is a finding.
3. Production error test. On the live deployment, request a nonexistent route and force a failing action. Stack traces, SQL, or internal paths shown to the client must be replaced with a generic message.
4. Leftover routes. List debug, test, and admin routes created during development. Confirm each is removed or authenticated on production.
5. Client-side limit test. Pick one limit the UI enforces (plan cap, size cap, rate cap) and call the endpoint directly without the UI. If it succeeds, the limit exists only in the browser.

Copy this checklist and fill it in as each test completes, so progress survives a long session:

- [ ] Two-account test — result:
- [ ] Logged-out test — result:
- [ ] Production error test — result:
- [ ] Leftover routes — result:
- [ ] Client-side limit test — result:

Phase 3 — Account and budget controls

Ask directly, and record the answers:

• Two-factor authentication enabled on source host, deploy platform, database, domain registrar, and every API provider? Account takeover bypasses all code-level work.
• Hard budget caps and spend alerts configured in every provider that bills per use?
• Secret scanning and push protection enabled on the repository?
• Dependency update alerts enabled?
• Separate credentials for development and production?

Phase 4 — Business logic review

Tooling cannot reach this layer. Read the app's own rules and ask what a motivated user could do within them. Prompts that surface real findings:

• Which fields decide what a user is entitled to, and can the user write to any of them?
• Can a user attach themselves to another user's team, workspace, or subscription?
• Can a giveaway or free tier be claimed repeatedly with scripted signups?
• Which actions cost money, and what is the maximum one account can spend in an hour?
• If one credential leaked, what exactly would it reach?
• Every field that determines entitlement (plan, quota, role, price) has been checked against who can write to it before moving to the report.

Report format

Use this structure exactly:

## Findings

### Critical — fix before launch
- [finding] — evidence: [file:line or test result] — fix: [specific action]

### Important — fix soon
- ...

### Confirmed fine
- [thing that looked alarming but is expected, and why]

## Not verified
- [what this audit could not check, and how the user would check it]

## Next three actions
1. ...

State the residual risk honestly. A clean scan means known patterns were absent, not that the application is secure — say that explicitly rather than letting a green result imply safety. After fixing every Critical item, rerun scripts/scan_repo.sh and repeat the two-account test before shipping.