DEV Community: Axonscape

API routes and admin pages anyone can call

Axonscape — Mon, 09 Nov 2026 09:40:53 +0000

Routes and server actions that change data without checking who's signed in, and admin pages hidden only by not linking to them, are open to anyone who finds the address.

What you see

An /api route or server action writes to the database with no sign-in check, or /admin opens for anyone who types the address.

Why it happens

AI tools build the feature first; checking who's asking is a separate step that's easy to leave out, and nothing in a demo shows it's missing.

How to fix it

At the top of every route and action that changes data, get the signed-in user and stop if there isn't one, or if they don't own what's being changed.
Protect admin pages in a middleware or the admin layout, checking the user is an admin.
Public forms (contact, waitlist) are fine without sign-in: give them a bot check instead.

Or ask your AI tool to fix it

Paste this into Lovable, Bolt, v0, Replit or Cursor:

Add an authentication check to every API route and server action that writes data: get the signed-in user, return 401 if there's none and 403 if they don't own the record. Protect every /admin page with a check that the user is an admin, in middleware or the admin layout.

The full page, with the request ready to copy, is at launchpad.axonscape.com/fix/api-routes-anyone-can-call. I work on Launchpad by Axonscape, which runs a free launch check for apps built with AI tools: it finds this and the other things that break at launch, from a public GitHub repo or a .zip of the code, and keeps nothing.

We checked 334 public apps built with Lovable, Bolt and v0. 32% had something to fix before launch

Axonscape — Sun, 08 Nov 2026 09:40:53 +0000

We ran a launch check on 334 public GitHub repositories made with Lovable, Bolt and v0, picked at random among those updated in the last two months. It reads the code for what breaks or leaks when an app goes live.

32% had at least one thing to fix before launch.
The median launch score was 80/100.
33% were launch-ready (90 or more).

What they'd ship with

.env file committed: 23% of apps (how to fix it)
Policies that let anyone change data: 19% of apps (how to fix it)
Tables without Row Level Security: 7% of apps (how to fix it)
Supabase admin key used in browser code: 6% of apps (how to fix it)
Secrets exposed to the browser: 1% of apps (how to fix it)
Secret keys committed to the repo: 1% of apps (how to fix it)

By tool

Bolt: 115 apps, median score 90/100, 12% with something to fix before launch
Lovable: 108 apps, median score 55/100, 79% with something to fix before launch
v0: 111 apps, median score 85/100, 7% with something to fix before launch

The tools build very different apps, so this compares what their users ship, not the tools themselves.

How it was done

Apps were found by the text each tool puts in the README it exports. Only totals were kept: no repository is named or stored, and the check never reads out a key, only that one is there. A public repository isn't always a launched app, and the check reads code only, so it can't see settings made in a dashboard.

The full results, updated each month, are at launchpad.axonscape.com/report. I work on Launchpad by Axonscape: the same launch check is free for your own app, with no account.

.env file and API keys committed to GitHub

Axonscape — Sat, 07 Nov 2026 09:40:53 +0000

A .env file exported with the code puts every key in it where anyone with access to the repository can read them, and deleting the file doesn't remove them from git history.

What you see

The repository has a .env file, or keys written straight into the code (sk_live_…, re_…, a database URL with its password).

Why it happens

Some tools export the .env with the project, and the .gitignore Vite starts with doesn't cover .env files. Once committed, a key stays in the history even after the file is deleted.

How to fix it

Revoke and replace every key the file held, in each provider's dashboard.
Remove the file from git (git rm --cached .env) and add .env* to .gitignore (with !.env.example if you keep one).
Set the new values at the host instead.

Or ask your AI tool to fix it

Paste this into Lovable, Bolt, v0, Replit or Cursor:

Remove .env from the repository (keep it locally), add .env* to .gitignore with !.env.example, create a .env.example listing every variable with no values, and make sure no key or password is written in the code. Then list every key I need to revoke and replace.

The full page, with the request ready to copy, is at launchpad.axonscape.com/fix/env-file-committed-to-github. I work on Launchpad by Axonscape, which runs a free launch check for apps built with AI tools: it finds this and the other things that break at launch, from a public GitHub repo or a .zip of the code, and keeps nothing.

Anyone can run up your OpenAI bill

Axonscape — Fri, 06 Nov 2026 09:40:53 +0000

An AI endpoint with no sign-in and no rate limit can be called in a loop by a bot or one curious person, and your AI provider bills you for every request.

What you see

Your AI provider's usage spikes overnight, or a route like /api/chat answers anyone who calls it, as fast as they call.

Why it happens

The route that calls the model checks neither who's asking nor how often. Scripts find routes like that within days.

How to fix it

Require sign-in for anything that costs money.
Limit requests per user or per IP, for example with @upstash/ratelimit and Redis.
Set a monthly spending cap in the AI provider's dashboard.

Or ask your AI tool to fix it

Paste this into Lovable, Bolt, v0, Replit or Cursor:

Add a rate limit to every API route that calls an AI model: per signed-in user, or per IP for anonymous use (for example @upstash/ratelimit with Upstash Redis), and require sign-in where the feature allows it. Return a clear 429 when the limit is reached.

The full page, with the request ready to copy, is at launchpad.axonscape.com/fix/ai-bill-rate-limit. I work on Launchpad by Axonscape, which runs a free launch check for apps built with AI tools: it finds this and the other things that break at launch, from a public GitHub repo or a .zip of the code, and keeps nothing.

OpenAI or Anthropic API key exposed in the browser

Axonscape — Thu, 05 Nov 2026 09:40:53 +0000

An AI client created with dangerouslyAllowBrowser, or a key behind a VITE_ or NEXT_PUBLIC_ prefix, puts your API key in the page, where anyone can copy it and spend on your account.

What you see

The OpenAI or Anthropic client is created in a component, with dangerouslyAllowBrowser: true, or the key is read from VITE_OPENAI_API_KEY or NEXT_PUBLIC_….

Why it happens

Anything the browser runs, every visitor can read. A public prefix means the value is bundled into the JavaScript everyone downloads.

How to fix it

Revoke the key in the provider's dashboard now: it has already shipped.
Call the AI from a server route that holds a new key (without a public prefix).
Have the browser call that route, and limit how often each user can.

Or ask your AI tool to fix it

Paste this into Lovable, Bolt, v0, Replit or Cursor:

The AI API key is exposed in the browser. Move every AI call to a server-side API route that reads the key from a server-only environment variable (no VITE_ or NEXT_PUBLIC_ prefix), have the browser call that route, and add a per-user rate limit. Then tell me to revoke the old key.

The full page, with the request ready to copy, is at launchpad.axonscape.com/fix/ai-api-key-exposed-in-browser. I work on Launchpad by Axonscape, which runs a free launch check for apps built with AI tools: it finds this and the other things that break at launch, from a public GitHub repo or a .zip of the code, and keeps nothing.

Supabase service-role key exposed in the browser

Axonscape — Wed, 04 Nov 2026 09:40:53 +0000

The service-role key skips every Row Level Security rule. Used in browser code, it's handed to every visitor, who can then read, change or delete your whole database.

What you see

Code that runs in the browser creates a Supabase client with SUPABASE_SERVICE_ROLE_KEY (or a key whose role is service_role).

Why it happens

AI tools reach for the service-role key when a query is blocked by RLS: it makes the error go away by switching security off. In browser code, the key ships to everyone.

How to fix it

Use the anon key in the browser, and fix the RLS policy that blocked the query instead.
Keep the service-role key in server code only: an API route, a server action or an edge function.
Rotate the key in Supabase → Settings → API: it has already shipped.

Or ask your AI tool to fix it

Paste this into Lovable, Bolt, v0, Replit or Cursor:

The Supabase service-role key is used in code that runs in the browser. Move every use of it to server-side code (an API route or edge function), use the anon key in the browser, and make the RLS policies allow what the app needs. Then tell me to rotate the key in Supabase.

The full page, with the request ready to copy, is at launchpad.axonscape.com/fix/supabase-service-role-key-in-browser. I work on Launchpad by Axonscape, which runs a free launch check for apps built with AI tools: it finds this and the other things that break at launch, from a public GitHub repo or a .zip of the code, and keeps nothing.

Supabase tables without Row Level Security are public

Axonscape — Tue, 03 Nov 2026 09:40:53 +0000

With Row Level Security off, or a policy of using (true), the public anon key in your app lets anyone read, change or delete every row. The app still works, which is why nobody notices.

What you see

Nothing looks wrong: the app works in every test. But anyone can open the browser's developer tools, take the Supabase URL and anon key, and query your tables directly.

Why it happens

Supabase gives the browser a public key and relies on Row Level Security (RLS) to decide what each user may see. A table created without RLS, or with a policy that allows everyone (using (true) on an insert, update or delete), protects nothing.

How to fix it

In Supabase → Table editor, make sure every table shows RLS enabled.
For each table, add policies tied to the signed-in user, e.g. using (auth.uid() = user_id).
Keep using (true) only for read policies on data that's meant to be public.
Test it: sign in as one user and try to read another's rows.

Or ask your AI tool to fix it

Paste this into Lovable, Bolt, v0, Replit or Cursor:

Enable Row Level Security on every table in the public schema, and add policies so each user can only read and change their own rows (auth.uid() = user_id), with public read access only where data is meant to be public. Add it as a new migration, and don't remove any existing data.

The full page, with the request ready to copy, is at launchpad.axonscape.com/fix/supabase-row-level-security. I work on Launchpad by Axonscape, which runs a free launch check for apps built with AI tools: it finds this and the other things that break at launch, from a public GitHub repo or a .zip of the code, and keeps nothing.

Deploy fails its health check: server stuck on port 5000

Axonscape — Mon, 02 Nov 2026 09:40:53 +0000

Replit apps listen on port 5000. Other hosts tell the app which port to use in PORT, so a fixed port is never reached and the deploy fails.

What you see

The build succeeds, then the deploy times out or fails its health check, and the logs say the server started on port 5000.

Why it happens

Hosts give each app a port in the PORT environment variable and send traffic there. A server hard-coded to 5000 listens somewhere nobody calls.

How to fix it

Change the server to listen on Number(process.env.PORT) || 5000, and deploy again.

Or ask your AI tool to fix it

Paste this into Lovable, Bolt, v0, Replit or Cursor:

Make the server listen on the port in the PORT environment variable, falling back to 5000: Number(process.env.PORT) || 5000. Don't change anything else.

The full page, with the request ready to copy, is at launchpad.axonscape.com/fix/server-fixed-port-5000. I work on Launchpad by Axonscape, which runs a free launch check for apps built with AI tools: it finds this and the other things that break at launch, from a public GitHub repo or a .zip of the code, and keeps nothing.

Replit Auth and Replit storage don't work outside Replit

Axonscape — Sun, 01 Nov 2026 09:40:53 +0000

An app built by Replit's Agent signs people in with their Replit accounts and keeps files in Replit's storage. Moved anywhere else, nobody can sign in. Change both first.

What you see

Deployed outside Replit, sign-in fails (REPLIT_DOMAINS isn't set), and saving or loading files errors.

Why it happens

server/replitAuth.ts signs people in through Replit's login service, and @replit/object-storage and @replit/database are Replit's own services. None of them exist outside Replit.

How to fix it

Ask Replit's Agent, or your AI tool, to switch sign-in to Clerk or Supabase Auth.
Move files to Cloudflare R2 or Supabase Storage, and Replit Database records into Postgres.
Bring the Postgres data along: in Replit's Shell, pg_dump -Fc --no-owner --no-privileges "$DATABASE_URL" > replit.dump.

Or ask your AI tool to fix it

Paste this into Lovable, Bolt, v0, Replit or Cursor:

This app has to run outside Replit. Replace sign-in with Replit accounts (server/replitAuth.ts, REPLIT_DOMAINS) with Clerk, and replace @replit/object-storage and @replit/database with S3-compatible storage (Cloudflare R2) and Postgres. Keep every page and API route working the same way.

The full page, with the request ready to copy, is at launchpad.axonscape.com/fix/replit-auth-outside-replit. I work on Launchpad by Axonscape, which runs a free launch check for apps built with AI tools: it finds this and the other things that break at launch, from a public GitHub repo or a .zip of the code, and keeps nothing.

Works locally, blank or broken in production: missing environment variables

Axonscape — Sat, 31 Oct 2026 09:40:53 +0000

The deployed app shows a blank page or errors that never happen locally. Usually a key the code reads was set on your computer, or in the AI tool, and never on the host.

What you see

A white screen, supabaseUrl is required, undefined in place of a value, or sign-in redirecting to localhost, only once deployed.

Why it happens

The code reads values like VITE_SUPABASE_URL from the environment. Your .env file, or the tool's secrets panel, set them where you built it; the new host has none of them. Links or sign-in redirects written as http://localhost:… break in the same way.

How to fix it

List every variable the code reads (process.env.X, import.meta.env.X) in a .env.example, names only.
Set each one at the host for production and previews. Values that start with NEXT_PUBLIC_ or VITE_ are visible to everyone: never put a secret in one.
Replace hard-coded localhost addresses with a variable such as NEXT_PUBLIC_SITE_URL.
Redeploy: most hosts only read variables at build time.

Or ask your AI tool to fix it

Paste this into Lovable, Bolt, v0, Replit or Cursor:

My app works locally but not when deployed. List every environment variable the code reads in .env.example (names only, no values), and replace any hard-coded localhost URL with one read from an environment variable. Don't put any secret value in the code.

The full page, with the request ready to copy, is at launchpad.axonscape.com/fix/missing-environment-variables-in-production. I work on Launchpad by Axonscape, which runs a free launch check for apps built with AI tools: it finds this and the other things that break at launch, from a public GitHub repo or a .zip of the code, and keeps nothing.

“Module not found” on deploy: a package isn't installed

Axonscape — Fri, 30 Oct 2026 09:40:53 +0000

The deploy fails because the code uses a package that isn't in package.json. It worked on your computer because the package happened to be installed there.

What you see

The build fails with Cannot find module 'something' or Could not resolve "some-package", for a package the code imports by name.

Why it happens

The package is installed on your computer (by hand, or by another project) but isn't listed in package.json, so the build server, which installs only what package.json lists, never gets it.

How to fix it

Run npm install <package> in the project, so it's added to package.json.
Commit package.json and the lockfile together, then push.

Or ask your AI tool to fix it

Paste this into Lovable, Bolt, v0, Replit or Cursor:

My app fails to build when deployed because a package it imports isn't installed. Add every package the code imports to package.json (and the lockfile), with the versions the code expects.

The full page, with the request ready to copy, is at launchpad.axonscape.com/fix/module-not-found-package-not-installed. I work on Launchpad by Axonscape, which runs a free launch check for apps built with AI tools: it finds this and the other things that break at launch, from a public GitHub repo or a .zip of the code, and keeps nothing.

“Could not resolve” on deploy, but it works on my computer

Axonscape — Thu, 29 Oct 2026 09:40:53 +0000

The build fails with Could not resolve './components/navbar' while the app runs fine locally. Usually it's capital letters: Mac and Windows ignore them, the build server doesn't.

What you see

The deploy fails with Could not resolve "./components/navbar" from "src/App.tsx" (or Module not found: Can't resolve), yet npm run dev and npm run build work on your computer.

Why it happens

The import says navbar and the file is Navbar.tsx. macOS and Windows treat those as the same name; the Linux machines that build your app don't. AI tools write mismatched capitals easily, and nothing on your computer complains. The other cause: the file was never committed.

How to fix it

Find the file the error names, and compare its name with the import letter by letter.
Change the import to match the file's name exactly (or rename the file).
To rename a file only by capital letters in git, use git mv -f old new: a plain rename often isn't seen.
Check the file is in the repository on GitHub, not only on your computer.

Or ask your AI tool to fix it

Paste this into Lovable, Bolt, v0, Replit or Cursor:

My app builds on my computer but fails when deployed (on Linux) with "Could not resolve". Find every import whose path differs from the real file's name in capital letters, and make each one match the file exactly. Don't change anything else.

The full page, with the request ready to copy, is at launchpad.axonscape.com/fix/could-not-resolve-works-locally. I work on Launchpad by Axonscape, which runs a free launch check for apps built with AI tools: it finds this and the other things that break at launch, from a public GitHub repo or a .zip of the code, and keeps nothing.