Skip to content
Flows
QA Advanced · 60-90 minutes

Security Basics Review

The essential security pass for AI-built apps: secrets, auth enforcement, input handling, and data exposure.

Start Route · 5 steps

The route

5 steps to Done

  1. 01

    Hunt exposed secrets

    The most common AI-build failure: keys where users can read them.

    Preview prompt + verify gate ▾

    Audit this app for exposed secrets. Check: all frontend source and env files for API keys/tokens (anything beyond truly public keys); the built bundle if inspectable; backend code for hardcoded credentials that should be env vars; logs printing secrets; repo files (.env committed?). For every finding: move the secret server-side or to env, rotate it if it was exposed, and verify the frontend bundle no longer contains it. List every finding and action.

    • Frontend contains no private keys
    • Hardcoded credentials moved to env
    • Exposed secrets were rotated
  2. 02

    Attack the auth enforcement

    Prove every private endpoint rejects you - by trying.

    Preview prompt + verify gate ▾

    Attack-test auth enforcement. Enumerate every backend endpoint and classify public vs private. Then, logged OUT, call every private endpoint directly (curl/fetch, not the UI): each must return 401/403, not data. Also test cross-user access: as user A, request user B's resources by id - must be rejected. Fix every endpoint that leaks, then re-run the exact attacks to confirm. Produce the endpoint-by-endpoint result table.

    • Every private endpoint was called unauthenticated
    • Cross-user access was attempted
    • Leaks fixed and re-attacked
  3. 03

    Harden input handling

    Every input is hostile until validated - on the server.

    Preview prompt + verify gate ▾

    Audit and harden input handling. For every endpoint accepting data: verify server-side validation of types, lengths, and formats (client validation does not count); test injection-style inputs (very long strings, script tags, query-operator payloads for the database in use) and confirm they are rejected or safely handled - not stored raw and re-rendered; check file uploads (if any) for type/size enforcement server-side. Fix gaps and re-test the exact payloads.

    • Server rejects bad data independently of the client
    • Script-tag payloads do not execute on render
    • Upload limits enforced server-side
  4. 04

    Audit API exposure

    APIs should return the minimum - check what they actually say.

    Preview prompt + verify gate ▾

    Audit every API response for over-exposure. Fetch each endpoint's real response and inspect: password hashes or auth tokens in user objects; other users' emails/PII in list endpoints; internal fields (flags, costs, notes) not meant for clients; verbose error messages leaking stack traces or queries. Fix by whitelisting response fields per endpoint and normalizing error responses. Re-fetch each to confirm the diet.

    • User objects contain no hash/token fields
    • List endpoints expose no unnecessary PII
    • Errors are normalized without internals
  5. 05

    Final security re-test

    Re-run every attack after fixes - and write down what remains.

    Preview prompt + verify gate ▾

    Run the final security verification: re-execute every attack from the previous steps (unauthenticated calls, cross-user access, hostile inputs, response inspection, bundle secret scan) and record the final result table. Document accepted risks honestly (what is out of scope for this stage and why). Add the basics if missing: rate limiting on auth endpoints, and secure headers where straightforward.

    • Every earlier attack re-executed
    • Auth endpoints have basic rate limiting
    • Accepted risks documented