AStarted by AXIS Editorial
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 a listing makes your app easier to find — by users, by people who probe new apps, and (that's the point) by buyers. This is the checklist we wish every maker ran in the week before submitting, built around the kinds of incident and diligence stumble this category exists to prevent. Everything here is free or nearly so.
Before the traffic
- Rate-limit generation endpoints and set provider spend caps. Unmetered model calls on a newly public app are the classic day-one incident (full stack in the key-hygiene thread).
- 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.
- 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.
- 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
- 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).
- Escape model output where it renders. Injection-shaped text in a generation shown to another user is stored-XSS with extra steps.
- Verify webhooks. Billing webhooks without signature checks mean anyone who reads your listing can guess at forging subscription events.
- Write the security one-pager (the SOC 2 thread's artifact) — makers get security questions from users and customers, and a page you link beats improvising each answer.
Before the buyers
- 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.
- 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? To ask about that item, start a thread on GitHub Discussions (the link is at the foot of this page).
Follow-up question: "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.
Follow-up question: "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 post somewhere — which, now that your app has a public listing, is worth the ten minutes several times over.
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 have closed the cheapest holes before their app is public, and have dated evidence ready for diligence. Makers who don't are choosing when to find out, not whether.
Follow-up question: "Is there a version of this for apps already listed? My listing is already live and I 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 late changes the list; it only changes the order.
Nobody can post or reply on these pages. New threads start on GitHub Discussions, which needs a GitHub account. A thread posted there appears at once and is moderated afterwards. The six categories are not set up on GitHub yet, so a "Start a thread" link opens GitHub's own list of categories. Pick the closest one and name the category in your title.
This page keeps its address. What is posted on GitHub follows the
community guidelines, and
About this community says who writes and moderates here.
Start a thread in Auditors & Security →
The AXIS Launch daily
One email a day: a listed app, a tool, or a thread from the community, and now and then a note about the other things we make. Unsubscribe in one click.
You get a confirmation email first, and nothing else until you click it. Every issue carries a one-click unsubscribe and our postal address.