The pre-listing security checklist we wish every maker ran

Curation reviews on this platform look at whether an app is real and honestly described — we don't security-audit submissions, and we say so. But listing is a visibility event: traffic, scrutiny, and (that's the point) buyers arrive. This is the checklist we wish every maker ran in the week before submitting, drawn from the recurring incidents and diligence stumbles this category exists to prevent. Everything here is free or nearly so.

Before the traffic

1. Rate-limit generation endpoints and set provider spend caps. A listing spike against unmetered model calls is the classic day-one incident (full stack in the key-hygiene thread).
2. Rotate any key that has ever been in client code, a repo, or a screenshot. Assume history is public; make the keys in it dead.
3. Kill the zombie surface. Old demo endpoints, staging sites with production data, forgotten admin routes — the things AI-assisted iteration leaves behind. List your live routes and justify each one.
4. Check authorization on every route, not every page. The UI hiding a button is not access control (the most common finding in the audit-scope thread, and it's exploitable by anyone with your listing URL and curiosity).

Before the scrutiny

1. Take secrets out of your system prompt and assume the prompt itself leaks (extraction attempts against newly listed AI apps are a when, not an if).
2. Escape model output where it renders. Injection-shaped text in a generation shown to another user is stored-XSS with extra steps.
3. Verify webhooks. Billing webhooks without signature checks mean anyone who reads your listing can guess at forging subscription events.
4. Write the security one-pager (the SOC 2 thread's artifact) — listers get security questions in comments and DMs, and a page you link beats improvising in public.

Before the buyers

1. Date-stamp what you've done: self-review notes, any audit report, your dependency-scan setup. Diligence rewards evidence with dates, and "we ran this checklist on [date]" is itself evidence.
2. Decide your disclosure posture now: where security researchers should report issues (an email on the one-pager suffices), and what you'll say publicly if something's found. Deciding during an incident is how bad days become bad weeks.

Ten items, roughly a focused week alongside whatever you've already got. None require hiring anyone — though item 4 is where an hour of borrowed senior judgment (see the DIY tier in the cost thread) pays best.

Which item would your app fail today? Honest answers below get specific help — that's what the category is for.

AXIS Editorial

Follow-up from maker intake: "Item 3 scares me — I've iterated with AI tools for a year and genuinely don't know my full surface. How do I inventory routes I've forgotten exist?"

Three passes, an afternoon total: (1) from the code — have your AI assistant enumerate every registered route/handler in the current codebase and diff that against what you think is live; (2) from the infrastructure — your hosting dashboard's list of deployed services, functions, and domains, including that staging app from March; (3) from the outside — a subdomain scan of your own domain plus your access logs' most-requested-404s and unrecognized-200s, which reveal what the internet already found. The zombie surface is almost always in pass 2 — deployments outlive the iterations that created them.

AXIS Editorial

Follow-up from maker intake: "For item 10, what does a right-sized disclosure posture look like? 'Security page with an email' feels thin but a bug bounty is obviously too much."

Right-sized for a solo maker: a security contact (email or form) findable from your site footer and one-pager; an acknowledgment commitment ('we respond within N business days' — pick a number you'll honor); a safe-harbor sentence saying good-faith research won't be met with legal threats; and no cash bounty — credit and thanks are standard at this scale, and researchers know it. That's four sentences on a page. The posture's real function is that the first report reaches you privately instead of appearing as a public thread reply — which, now that your app is listed where buyers read, is worth the ten minutes several times over.

Jonathan (AXIS Launch)

Context on why this is a wish-list and not a listing requirement: we considered gating listings on a security checklist and decided against it — we can't verify most items from outside, and unverifiable requirements become theater, which is the thing this platform exists to not do. So the honest design is: curation checks what we can check, this checklist tells you what we can't, and the buyers eventually check everything. Makers who run it are safer during their launch spike and measurably smoother in diligence. Makers who don't are choosing when to find out, not whether.

AXIS Editorial

Follow-up from maker intake: "Is there a version of this for apps already listed? I shipped my listing six months ago and did none of it."

Same list, reordered by live risk: do items 1, 2, and 7 today — they're the actively-exploitable-for-money class (spend abuse and billing forgery), and rotation plus caps is an afternoon. Item 4 this week, with the borrowed-hour review. Items 3 and 5-6 next. Then 8-10, which get easier because you now have history to document instead of promises to make. One addition for already-listed apps: check your listing-era screenshots and any public demo videos for visible keys, internal URLs, or real customer data — retroactively, those are the most-viewed artifacts you have. Nothing about being six months late changes the list; it only changes the order.