← all checksfor Claude Code builders

Claude Code app security checklist: what to check before you ship

You've been pairing with Claude Code, the app works, and the tests pass. Here's what “the tests pass” doesn't tell you, and what to check before real customers show up.

how these apps get built

How Claude-Code-built apps typically structure auth and data

Working in an agentic coding tool tends to produce genuinely well-structured code — consistent patterns, a real auth middleware, typed database queries. That structure is a strength, and it doesn’t automatically extend to access control being correct everywhere it’s used. A consistent pattern applied inconsistently — one route that checks ownership, a newer one added later that copies most of the pattern but not the ownership check — is easy to produce and easy to miss in review, because the code looks like every other route around it.

the trap

The “it works in testing” trap: single-account testing hides cross-account bugs

Whether a human or an AI assistant writes the tests, the default shape of a test is “log in as a user, do the thing, confirm it worked.” That’s a real and useful test — it just never asks the question that actually matters for a leak: what happens when a different logged-in user asks for the first user’s data. A full green test suite and a working demo can coexist with an IDOR that’s been sitting in the code the whole time, because nothing in that suite ever tried it from a second account.

the honest fix

If you want your own tests to catch this class of bug, the test has to create a second account and assert that it cannot read the first one’s data — not just that the first account can read its own.

do this before you launch

A manual checklist before real customers show up

Sign up two accounts and try to read/edit one account's data (an order, a document, a settings page) while logged in as the other.
Check every API route that accepts an id — invoice, project, file — for a query that filters by the current session's user, not just the id in the request.
Confirm your Stripe webhook handler verifies the event signature before it changes anything in your database.
Confirm a cancelled or failed-payment account actually loses access on its next request, not just on its next login.

what Solacess adds

What the two-account and Stripe checks add specifically

These are the checks that require actually acting as two separate, live sessions and a real (test-mode) payment flow — the part a code review or a single-account test suite structurally can’t reach.

A1Cross-account data access — account B's session replays account A's request, swapping the id, and records what came back.two accounts

A5JWT verification skipped — a token with alg=none, a bad signature, or an expired token, checked for whether the app still accepts it.two accounts

P2A real, signed test-mode payment event delivered twice, checked for whether the account was credited twice.

P4Access checked again after a cancellation or failed payment, not just at signup time.

related checks

See the two-account check that a single-account test suite can't run.

The sample report is a real scan of a deliberately vulnerable app — nine findings, the proof behind each one, and what they would cost.

See a real report See pricing