Apps built with Lovable, Bolt, v0, Replit or Cursor often go live with their database open to anyone, secret keys in the browser bundle, or libraries with known vulnerabilities. Shippable checks for these from the outside, the way an attacker would, and shows you proof plus a fix you can paste straight into your AI tool.

npx shippable-dev scan localhost:5173

Before you push: scan your dev server

npx shippable-dev scan localhost:3000

No sign-up and no verification to scan: it's your own machine. The full report page asks for an email. A local scan checks:

Open Supabase data. Tables and storage buckets anyone can read because Row Level Security is off or too loose.
Open Firebase data. Realtime Database and Storage rules that let anyone read.
Secrets in client code. service_role keys, API keys and tokens shipped to the browser.
Vulnerable libraries. Known CVEs in the JavaScript you ship (from the OSV database).
Exposed endpoints. The API routes your frontend calls, each of which must check who is calling.

It also reads your project folder (the one you run it from), on your machine only, and flags:

Supabase tables with no Row Level Security in your migrations.
Secrets headed for the browser, like a service_role key in a VITE_ or NEXT_PUBLIC_ variable, or a key written into your code. Detection covers many more providers, including Supabase's new sb_secret_ keys.
.env files in git, or not yet in .gitignore.
Open Firebase rules in firestore.rules, storage.rules and database.rules.json.
Supabase edge functions anyone can call. Functions that send email, use the service-role key, download files or call Stripe without checking who is calling (verify_jwt alone doesn't, the public anon key passes it). CAPTCHA, rate limits and webhook signatures count as protection.
Unsigned payment webhooks. Stripe, Lemon Squeezy and Paddle handlers that never verify the signature, so anyone can fake a payment.
Request data in emails and redirects. Values from the request put into email HTML without escaping, and checkout or portal return URLs built from the Origin header.
Database rules users can abuse. Users who can edit their own plan or counter columns, USING (true) read rules, and storage policies with no owner condition.
More Supabase database rules. SECURITY DEFINER functions anyone (or any signed-in user) can call, policies that trust user_metadata, views that skip Row Level Security or expose auth.users, and tables anonymous visitors can write to.
AI features. User details (email, phone) written into the AI's system prompt, AI replies rendered as raw HTML, vector search (match_documents and similar) that doesn't limit results to the signed-in user.
Login abuse. Handlers that send login codes or reset emails with no CAPTCHA or rate limit, rate limits keyed on the raw email (a +alias gets around them), login or reset responses that say whether an email has an account, and session tokens put in URLs.
Email passwords in code. An SMTP or Gmail app password written into a nodemailer or SMTP client setup instead of an environment variable.
Vulnerable dependencies. Every package in your lockfile (package-lock.json, pnpm-lock.yaml or yarn.lock) is checked against the OSV vulnerability database. Only package names and versions are sent to OSV, never your code.

Point it at another folder with --project <dir>, or skip these checks with --no-project. The MCP server takes an optional projectDir for the same thing.

Headers, HTTPS, source maps and exposed files depend on your host, so a local scan skips them. Scan your deployed URL for those.

After each scan, the full report opens in your browser on shippable.dev, with a copy button for every fix. The report travels inside the link itself (after the #), which browsers never send to a server, so Shippable never receives your findings. When it can't open a browser (an AI agent runs it, --no-open, or no browser), the CLI writes a small local file that opens the report and prints its path, because a long link gets garbled when an agent repeats it. In CI it is never opened or printed, because CI logs can be public.

After you deploy: scan your live app

npx shippable-dev scan https://myapp.lovable.app

The first run prints a meta tag and a prompt to paste into your AI tool. Deploy it, run the same command again, and the scan starts. Shippable only scans apps you can prove you own.

A live scan also checks what depends on your host: security headers and HTTPS, CORS that lets other sites read logged-in data, exposed files (.env, .git, backups, docker-compose), debug and API-docs pages, error pages that reveal internals, whether your domain is protected against email spoofing (SPF and DMARC), AI system prompts shipped in your JavaScript, and admin tools left open on your subdomains (n8n, Metabase, Grafana, Evolution API and similar). Subdomains come from public certificate logs (crt.sh and Cert Spotter), which receive only your domain name. It only reads; it never sends anything that could change your app.

Cookie consent in a real browser (`--browser`)

npx shippable-dev scan localhost:3000 --browser

Opt-in, and it only runs after the usual ownership check. It opens your page in your own installed Chrome (or Edge) in headless mode as a first-time visitor, records which trackers fire and which cookies get set, then, if there is a cookie banner, clicks its "reject" and reloads to see whether the trackers really stopped. It never types, signs in or submits anything. It needs Google Chrome (or run npx playwright install chromium); without one the scan carries on and says so. The MCP shippable_scan tool takes browser: true for the same. Results come from your machine's location: some banners only show to EU visitors.

In CI

The command exits with 1 when it finds a critical or high issue, so it can block a deploy:

npx shippable-dev scan https://staging.myapp.com || exit 1

On GitHub, the Shippable Action does this on every pull request. It starts your dev server, scans it and your project folder, and writes the findings to the run summary:

- uses: Egarter/shippable-action@v1
  with:
    start: npm run dev
    url: localhost:5173

To see what a scan finds first, try leaky-helpdesk, an AI chat app with planted security holes.

Exit codes: 0 nothing critical or high; 1 critical or high findings; 2 nothing was checked: bad usage, the app couldn't be reached, the scan would have left the allowed network, ownership isn't verified yet, or the host's bot protection blocked the scan. Output has no colour when piped or when NO_COLOR is set.

Read-only

Shippable only reads. It never writes, deletes or changes anything in your app or database. When it proves a table is open, it reads at most a few rows and shows you those as the evidence.

Use it inside your AI agent (MCP)

Shippable runs as an MCP server, so Cursor, Claude Code, Windsurf, VS Code and other agents can scan the app they're building and apply the fixes themselves. It adds two tools: shippable_scan checks the running app from outside, and shippable_review_code runs the code checks above, then gives your agent a checklist for what patterns can't catch (plan limits enforced only in the frontend, whether each function checks the record it's given).

Claude Code

claude mcp add shippable -- npx -y shippable-dev mcp

Cursor: Add to Cursor in one click, or paste this into .cursor/mcp.json (also works for Windsurf and most other agents):

{
  "mcpServers": {
    "shippable": { "command": "npx", "args": ["-y", "shippable-dev", "mcp"] }
  }
}

VS Code: Add to VS Code in one click, or paste this into .vscode/mcp.json:

{
  "servers": {
    "shippable": { "command": "npx", "args": ["-y", "shippable-dev", "mcp"] }
  }
}

Then ask your agent to "scan my app with Shippable before we ship", or to "review my code with Shippable". For a live URL, the first scan gives the agent a meta tag to add and deploy; the next scan runs.

Tell your AI agent

Add this to AGENTS.md, CLAUDE.md or .cursor/rules:

Before telling me this app is ready to ship, run `npx shippable-dev scan <dev server URL>` and fix every critical and high finding.

Use it only on apps you own

Scanning an app you don't own may be illegal where you live. The command-line scanner makes this hard on purpose: live URLs need an ownership tag that only the app's owner can deploy, and local scans refuse to reach anything except your own machine and the database services they check. You are responsible for how you use it.

For site owners

Every request from this scanner identifies itself with the user agent Shippable-CLI. If you see it and didn't run it yourself, you can block that user agent at your host or firewall.

If your host's bot protection challenges the scan

The scanner never tries to get around a challenge. It stops its extra checks, says so in the report, and you can re-scan after about 10 minutes. To allow the full scan on Vercel:

Pro/Enterprise: Firewall > Add New > System Bypass with the IP you scan from (docs).
Any plan, if you turned on Bot Protection: add a custom rule "User Agent contains Shippable" with action Bypass (docs).
Hobby has no way to bypass Vercel's automatic DDoS mitigation; just re-scan later.

Telemetry

To know whether the CLI and MCP server are used at all, each scan sends one anonymous ping to shippable.dev:

the Shippable version
which command ran (CLI scan, MCP scan or MCP code review), and whether it was a local or live scan
how many findings it found at each severity
whether it ran in CI
a random install id, created on first run and stored in ~/.config/shippable/telemetry.json

Never sent: URLs, hostnames, file names, code, findings or anything from your app. No IP address is stored. The ping never slows or fails a scan.

Turn it off with SHIPPABLE_TELEMETRY=0 (or DO_NOT_TRACK=1). A notice is printed the first time it runs.