# ShipReady > Launch assurance for AI-built apps Per-page markdown is the preferred way to read one topic. Add a .md suffix to any address, or read the index at https://shipreadyai.dev/llms.txt. The free Launch Risk Check reads a public URL from the outside and reports what an ordinary visitor can observe: the redirect and certificate, protective response headers, source maps, secrets left in client JavaScript, exposed paths, cookies, email records and legal pages. It never signs in, never writes anything, and never reads the contents of a database. It does not claim an app is free of problems, and it produces no score and no badge. ## ShipReady https://shipreadyai.dev/ # You built it with AI. Now prove the risky parts before customers do. ShipReady checks the launch risks it can observe from outside, shows you what still needs verification, and gives you the next step: fix it yourself, or have Alex review and harden it with you. Publish an honest Launch Risk Statement your customers can read. No account. No repo access. No credentials. Results in about 20 seconds. ## Your platform scans headers and packages. Your customers hit everything else. Lovable, Supabase, and your coding agent already lint access policies and audit dependencies. None of them can tell you whether your Stripe webhooks run twice, whether one customer can read another customer's rows, or whether rollback works at 2 a.m. Those failures only show up with real users, real data, and real money. ShipReady works on that layer. ## What a result looks like The home page shows the live check of ShipReady's own app, with the Observed and Not verified lists as they came back. A number from a URL check would be a guess dressed up as a fact, so there isn't one. The free check tells you what ShipReady can see from outside. The Launch Review covers the parts it can't. ## Do it yourself, have it reviewed, or have it fixed - Release Gate, $49. The launch checklist and repo guardrails you install yourself. - Launch Review, $199. A written review of your production layer plus a recorded walkthrough. - Hardening Sprint, $1,750. Seven business days of paired work on the highest priority fixes. - Release Assurance, $3,500 per month. Four release-risk reviews a month, one architecture clinic, priority triage, and maintained repo guardrails for teams that ship weekly. - Re-verification, $99. A fresh verdict on the items marked Needs fix on your statement, after you have made the changes. ## Who this is for For - AI development agencies shipping client apps. - Founders with live users or payments. - Teams with no senior production owner. Not for - Weekend projects with no users yet. The free check still works. - The paid tiers assume something is at stake. ## Who is checking Alex Cinovoj, founder and CTO of TechTide AI. Fifteen years of enterprise IT before AI: help desk, hospital systems, MSP work, cloud engineering. Lovable Community Champion. Nine Anthropic Claude certifications. Co-host of the Automation Vibes podcast. He builds production AI systems on Lovable, Claude Code, Supabase, Next.js, and Railway, and gets paid to make prototypes survive real users. ShipReady is not a penetration test or a security certification. No automated check can prove an application is secure. ## Simple pricing https://shipreadyai.dev/pricing # Simple pricing Three ways to deal with what the free check finds. - Release Gate, $49. The launch checklist and repo guardrails you install yourself. - Launch Review, $199. A written review of your production layer plus a recorded walkthrough. - Hardening Sprint, $1,750. Seven business days of paired work on the highest priority fixes. - Release Assurance, $3,500 per month. Four release-risk reviews a month, one architecture clinic, priority triage, and maintained repo guardrails for teams that ship weekly. - Re-verification, $99. A fresh verdict on the items marked Needs fix on your statement, after you have made the changes. ShipReady is not a penetration test or a security certification. No automated check can prove an application is secure. ## Launch checklist generator https://shipreadyai.dev/checklist # Launch checklist generator A deterministic checklist built from seven answers about an app's builder, backend, payments, auth, data, AI features, and hosting. The same answers always produce the same list. Nothing is generated by a language model. ## Ready made combinations - [Lovable plus Supabase plus Stripe launch checklist](https://shipreadyai.dev/checklist/lovable-supabase-stripe.md) - [Lovable plus Supabase plus None launch checklist](https://shipreadyai.dev/checklist/lovable-supabase-none.md) - [Lovable plus Lovable Cloud plus Stripe launch checklist](https://shipreadyai.dev/checklist/lovable-lovable-cloud-stripe.md) - [Lovable plus Lovable Cloud plus None launch checklist](https://shipreadyai.dev/checklist/lovable-lovable-cloud-none.md) - [Lovable plus Firebase plus Stripe launch checklist](https://shipreadyai.dev/checklist/lovable-firebase-stripe.md) - [Lovable plus Firebase plus None launch checklist](https://shipreadyai.dev/checklist/lovable-firebase-none.md) - [Bolt plus Supabase plus Stripe launch checklist](https://shipreadyai.dev/checklist/bolt-supabase-stripe.md) - [Bolt plus Supabase plus None launch checklist](https://shipreadyai.dev/checklist/bolt-supabase-none.md) - [Bolt plus Lovable Cloud plus Stripe launch checklist](https://shipreadyai.dev/checklist/bolt-lovable-cloud-stripe.md) - [Bolt plus Lovable Cloud plus None launch checklist](https://shipreadyai.dev/checklist/bolt-lovable-cloud-none.md) - [Bolt plus Firebase plus Stripe launch checklist](https://shipreadyai.dev/checklist/bolt-firebase-stripe.md) - [Bolt plus Firebase plus None launch checklist](https://shipreadyai.dev/checklist/bolt-firebase-none.md) - [v0 plus Supabase plus Stripe launch checklist](https://shipreadyai.dev/checklist/v0-supabase-stripe.md) - [v0 plus Supabase plus None launch checklist](https://shipreadyai.dev/checklist/v0-supabase-none.md) - [v0 plus Lovable Cloud plus Stripe launch checklist](https://shipreadyai.dev/checklist/v0-lovable-cloud-stripe.md) - [v0 plus Lovable Cloud plus None launch checklist](https://shipreadyai.dev/checklist/v0-lovable-cloud-none.md) - [v0 plus Firebase plus Stripe launch checklist](https://shipreadyai.dev/checklist/v0-firebase-stripe.md) - [v0 plus Firebase plus None launch checklist](https://shipreadyai.dev/checklist/v0-firebase-none.md) - [Cursor or Claude Code plus Supabase plus Stripe launch checklist](https://shipreadyai.dev/checklist/cursor-claude-code-supabase-stripe.md) - [Cursor or Claude Code plus Supabase plus None launch checklist](https://shipreadyai.dev/checklist/cursor-claude-code-supabase-none.md) - [Cursor or Claude Code plus Lovable Cloud plus Stripe launch checklist](https://shipreadyai.dev/checklist/cursor-claude-code-lovable-cloud-stripe.md) - [Cursor or Claude Code plus Lovable Cloud plus None launch checklist](https://shipreadyai.dev/checklist/cursor-claude-code-lovable-cloud-none.md) - [Cursor or Claude Code plus Firebase plus Stripe launch checklist](https://shipreadyai.dev/checklist/cursor-claude-code-firebase-stripe.md) - [Cursor or Claude Code plus Firebase plus None launch checklist](https://shipreadyai.dev/checklist/cursor-claude-code-firebase-none.md) ## Lovable plus Supabase plus Stripe launch checklist https://shipreadyai.dev/checklist/lovable-supabase-stripe # Lovable plus Supabase plus Stripe launch checklist A deterministic checklist for this stack. Build your own at https://shipreadyai.dev/checklist ## Lovable plus Supabase plus None launch checklist https://shipreadyai.dev/checklist/lovable-supabase-none # Lovable plus Supabase plus None launch checklist A deterministic checklist for this stack. Build your own at https://shipreadyai.dev/checklist ## Lovable plus Lovable Cloud plus Stripe launch checklist https://shipreadyai.dev/checklist/lovable-lovable-cloud-stripe # Lovable plus Lovable Cloud plus Stripe launch checklist A deterministic checklist for this stack. Build your own at https://shipreadyai.dev/checklist ## Lovable plus Lovable Cloud plus None launch checklist https://shipreadyai.dev/checklist/lovable-lovable-cloud-none # Lovable plus Lovable Cloud plus None launch checklist A deterministic checklist for this stack. Build your own at https://shipreadyai.dev/checklist ## Lovable plus Firebase plus Stripe launch checklist https://shipreadyai.dev/checklist/lovable-firebase-stripe # Lovable plus Firebase plus Stripe launch checklist A deterministic checklist for this stack. Build your own at https://shipreadyai.dev/checklist ## Lovable plus Firebase plus None launch checklist https://shipreadyai.dev/checklist/lovable-firebase-none # Lovable plus Firebase plus None launch checklist A deterministic checklist for this stack. Build your own at https://shipreadyai.dev/checklist ## Bolt plus Supabase plus Stripe launch checklist https://shipreadyai.dev/checklist/bolt-supabase-stripe # Bolt plus Supabase plus Stripe launch checklist A deterministic checklist for this stack. Build your own at https://shipreadyai.dev/checklist ## Bolt plus Supabase plus None launch checklist https://shipreadyai.dev/checklist/bolt-supabase-none # Bolt plus Supabase plus None launch checklist A deterministic checklist for this stack. Build your own at https://shipreadyai.dev/checklist ## Bolt plus Lovable Cloud plus Stripe launch checklist https://shipreadyai.dev/checklist/bolt-lovable-cloud-stripe # Bolt plus Lovable Cloud plus Stripe launch checklist A deterministic checklist for this stack. Build your own at https://shipreadyai.dev/checklist ## Bolt plus Lovable Cloud plus None launch checklist https://shipreadyai.dev/checklist/bolt-lovable-cloud-none # Bolt plus Lovable Cloud plus None launch checklist A deterministic checklist for this stack. Build your own at https://shipreadyai.dev/checklist ## Bolt plus Firebase plus Stripe launch checklist https://shipreadyai.dev/checklist/bolt-firebase-stripe # Bolt plus Firebase plus Stripe launch checklist A deterministic checklist for this stack. Build your own at https://shipreadyai.dev/checklist ## Bolt plus Firebase plus None launch checklist https://shipreadyai.dev/checklist/bolt-firebase-none # Bolt plus Firebase plus None launch checklist A deterministic checklist for this stack. Build your own at https://shipreadyai.dev/checklist ## v0 plus Supabase plus Stripe launch checklist https://shipreadyai.dev/checklist/v0-supabase-stripe # v0 plus Supabase plus Stripe launch checklist A deterministic checklist for this stack. Build your own at https://shipreadyai.dev/checklist ## v0 plus Supabase plus None launch checklist https://shipreadyai.dev/checklist/v0-supabase-none # v0 plus Supabase plus None launch checklist A deterministic checklist for this stack. Build your own at https://shipreadyai.dev/checklist ## v0 plus Lovable Cloud plus Stripe launch checklist https://shipreadyai.dev/checklist/v0-lovable-cloud-stripe # v0 plus Lovable Cloud plus Stripe launch checklist A deterministic checklist for this stack. Build your own at https://shipreadyai.dev/checklist ## v0 plus Lovable Cloud plus None launch checklist https://shipreadyai.dev/checklist/v0-lovable-cloud-none # v0 plus Lovable Cloud plus None launch checklist A deterministic checklist for this stack. Build your own at https://shipreadyai.dev/checklist ## v0 plus Firebase plus Stripe launch checklist https://shipreadyai.dev/checklist/v0-firebase-stripe # v0 plus Firebase plus Stripe launch checklist A deterministic checklist for this stack. Build your own at https://shipreadyai.dev/checklist ## v0 plus Firebase plus None launch checklist https://shipreadyai.dev/checklist/v0-firebase-none # v0 plus Firebase plus None launch checklist A deterministic checklist for this stack. Build your own at https://shipreadyai.dev/checklist ## Cursor or Claude Code plus Supabase plus Stripe launch checklist https://shipreadyai.dev/checklist/cursor-claude-code-supabase-stripe # Cursor or Claude Code plus Supabase plus Stripe launch checklist A deterministic checklist for this stack. Build your own at https://shipreadyai.dev/checklist ## Cursor or Claude Code plus Supabase plus None launch checklist https://shipreadyai.dev/checklist/cursor-claude-code-supabase-none # Cursor or Claude Code plus Supabase plus None launch checklist A deterministic checklist for this stack. Build your own at https://shipreadyai.dev/checklist ## Cursor or Claude Code plus Lovable Cloud plus Stripe launch checklist https://shipreadyai.dev/checklist/cursor-claude-code-lovable-cloud-stripe # Cursor or Claude Code plus Lovable Cloud plus Stripe launch checklist A deterministic checklist for this stack. Build your own at https://shipreadyai.dev/checklist ## Cursor or Claude Code plus Lovable Cloud plus None launch checklist https://shipreadyai.dev/checklist/cursor-claude-code-lovable-cloud-none # Cursor or Claude Code plus Lovable Cloud plus None launch checklist A deterministic checklist for this stack. Build your own at https://shipreadyai.dev/checklist ## Cursor or Claude Code plus Firebase plus Stripe launch checklist https://shipreadyai.dev/checklist/cursor-claude-code-firebase-stripe # Cursor or Claude Code plus Firebase plus Stripe launch checklist A deterministic checklist for this stack. Build your own at https://shipreadyai.dev/checklist ## Cursor or Claude Code plus Firebase plus None launch checklist https://shipreadyai.dev/checklist/cursor-claude-code-firebase-none # Cursor or Claude Code plus Firebase plus None launch checklist A deterministic checklist for this stack. Build your own at https://shipreadyai.dev/checklist ## Replit launch checklist https://shipreadyai.dev/stack-launch-checklist/replit # Replit launch checklist A deterministic pre-launch checklist for Replit, focused on workspace secrets, public processes, and deployment settings. ## Review prompt Review this Replit app before launch. Focus on workspace secrets, public processes, and deployment settings. For every issue, name the evidence, smallest fix, owner, and recheck step. Do not infer a pass from missing evidence. ## Next.js launch checklist https://shipreadyai.dev/stack-launch-checklist/nextjs # Next.js launch checklist A deterministic pre-launch checklist for Next.js, focused on server and client boundaries, route handlers, and environment values. ## Review prompt Review this Next.js app before launch. Focus on server and client boundaries, route handlers, and environment values. For every issue, name the evidence, smallest fix, owner, and recheck step. Do not infer a pass from missing evidence. ## Remix launch checklist https://shipreadyai.dev/stack-launch-checklist/remix # Remix launch checklist A deterministic pre-launch checklist for Remix, focused on loaders, actions, sessions, and response headers. ## Review prompt Review this Remix app before launch. Focus on loaders, actions, sessions, and response headers. For every issue, name the evidence, smallest fix, owner, and recheck step. Do not infer a pass from missing evidence. ## Astro launch checklist https://shipreadyai.dev/stack-launch-checklist/astro # Astro launch checklist A deterministic pre-launch checklist for Astro, focused on islands, server endpoints, and deployed adapter behavior. ## Review prompt Review this Astro app before launch. Focus on islands, server endpoints, and deployed adapter behavior. For every issue, name the evidence, smallest fix, owner, and recheck step. Do not infer a pass from missing evidence. ## Vite launch checklist https://shipreadyai.dev/stack-launch-checklist/vite # Vite launch checklist A deterministic pre-launch checklist for Vite, focused on client bundles, exposed environment values, and fallback routes. ## Review prompt Review this Vite app before launch. Focus on client bundles, exposed environment values, and fallback routes. For every issue, name the evidence, smallest fix, owner, and recheck step. Do not infer a pass from missing evidence. ## Lovable Cloud launch checklist https://shipreadyai.dev/stack-launch-checklist/lovable-cloud # Lovable Cloud launch checklist A deterministic pre-launch checklist for Lovable Cloud, focused on row access rules, server actions, and authentication. ## Review prompt Review this Lovable Cloud app before launch. Focus on row access rules, server actions, and authentication. For every issue, name the evidence, smallest fix, owner, and recheck step. Do not infer a pass from missing evidence. ## Supabase launch checklist https://shipreadyai.dev/stack-launch-checklist/supabase # Supabase launch checklist A deterministic pre-launch checklist for Supabase, focused on row access rules, grants, functions, and authentication. ## Review prompt Review this Supabase app before launch. Focus on row access rules, grants, functions, and authentication. For every issue, name the evidence, smallest fix, owner, and recheck step. Do not infer a pass from missing evidence. ## Firebase launch checklist https://shipreadyai.dev/stack-launch-checklist/firebase # Firebase launch checklist A deterministic pre-launch checklist for Firebase, focused on rules, callable functions, and client configuration. ## Review prompt Review this Firebase app before launch. Focus on rules, callable functions, and client configuration. For every issue, name the evidence, smallest fix, owner, and recheck step. Do not infer a pass from missing evidence. ## Convex launch checklist https://shipreadyai.dev/stack-launch-checklist/convex # Convex launch checklist A deterministic pre-launch checklist for Convex, focused on function exposure, identity checks, and argument validation. ## Review prompt Review this Convex app before launch. Focus on function exposure, identity checks, and argument validation. For every issue, name the evidence, smallest fix, owner, and recheck step. Do not infer a pass from missing evidence. ## Custom Node backend launch checklist https://shipreadyai.dev/stack-launch-checklist/custom-node # Custom Node backend launch checklist A deterministic pre-launch checklist for Custom Node backend, focused on request validation, authorization, and production process behavior. ## Review prompt Review this Custom Node backend app before launch. Focus on request validation, authorization, and production process behavior. For every issue, name the evidence, smallest fix, owner, and recheck step. Do not infer a pass from missing evidence. ## Custom Python backend launch checklist https://shipreadyai.dev/stack-launch-checklist/custom-python # Custom Python backend launch checklist A deterministic pre-launch checklist for Custom Python backend, focused on request validation, authorization, and production process behavior. ## Review prompt Review this Custom Python backend app before launch. Focus on request validation, authorization, and production process behavior. For every issue, name the evidence, smallest fix, owner, and recheck step. Do not infer a pass from missing evidence. ## Stripe launch checklist https://shipreadyai.dev/stack-launch-checklist/stripe # Stripe launch checklist A deterministic pre-launch checklist for Stripe, focused on checkout outcomes, webhook signatures, retries, and refunds. ## Review prompt Review this Stripe app before launch. Focus on checkout outcomes, webhook signatures, retries, and refunds. For every issue, name the evidence, smallest fix, owner, and recheck step. Do not infer a pass from missing evidence. ## Lemon Squeezy launch checklist https://shipreadyai.dev/stack-launch-checklist/lemon-squeezy # Lemon Squeezy launch checklist A deterministic pre-launch checklist for Lemon Squeezy, focused on checkout outcomes, webhook signatures, and entitlement changes. ## Review prompt Review this Lemon Squeezy app before launch. Focus on checkout outcomes, webhook signatures, and entitlement changes. For every issue, name the evidence, smallest fix, owner, and recheck step. Do not infer a pass from missing evidence. ## Paddle launch checklist https://shipreadyai.dev/stack-launch-checklist/paddle # Paddle launch checklist A deterministic pre-launch checklist for Paddle, focused on checkout outcomes, webhook signatures, and entitlement changes. ## Review prompt Review this Paddle app before launch. Focus on checkout outcomes, webhook signatures, and entitlement changes. For every issue, name the evidence, smallest fix, owner, and recheck step. Do not infer a pass from missing evidence. ## PostHog launch checklist https://shipreadyai.dev/stack-launch-checklist/posthog # PostHog launch checklist A deterministic pre-launch checklist for PostHog, focused on consent, identity boundaries, and event quality. ## Review prompt Review this PostHog app before launch. Focus on consent, identity boundaries, and event quality. For every issue, name the evidence, smallest fix, owner, and recheck step. Do not infer a pass from missing evidence. ## Resend launch checklist https://shipreadyai.dev/stack-launch-checklist/resend # Resend launch checklist A deterministic pre-launch checklist for Resend, focused on domain setup, failed delivery, and honest interface feedback. ## Review prompt Review this Resend app before launch. Focus on domain setup, failed delivery, and honest interface feedback. For every issue, name the evidence, smallest fix, owner, and recheck step. Do not infer a pass from missing evidence. ## Clerk launch checklist https://shipreadyai.dev/stack-launch-checklist/clerk # Clerk launch checklist A deterministic pre-launch checklist for Clerk, focused on session validation, protected actions, and sign-out behavior. ## Review prompt Review this Clerk app before launch. Focus on session validation, protected actions, and sign-out behavior. For every issue, name the evidence, smallest fix, owner, and recheck step. Do not infer a pass from missing evidence. ## Kinde launch checklist https://shipreadyai.dev/stack-launch-checklist/kinde # Kinde launch checklist A deterministic pre-launch checklist for Kinde, focused on session validation, protected actions, and sign-out behavior. ## Review prompt Review this Kinde app before launch. Focus on session validation, protected actions, and sign-out behavior. For every issue, name the evidence, smallest fix, owner, and recheck step. Do not infer a pass from missing evidence. ## Vercel launch checklist https://shipreadyai.dev/stack-launch-checklist/vercel # Vercel launch checklist A deterministic pre-launch checklist for Vercel, focused on environment separation, caching, redirects, and rollback. ## Review prompt Review this Vercel app before launch. Focus on environment separation, caching, redirects, and rollback. For every issue, name the evidence, smallest fix, owner, and recheck step. Do not infer a pass from missing evidence. ## Every finding, explained https://shipreadyai.dev/learn/findings # Every finding, explained One page for each of the 67 findings the free Launch Risk Check can report. - [Plain http traffic is sent on to https](https://shipreadyai.dev/learn/findings/o1-https-redirect-ok.md): Visitors who type the address without https land on the encrypted version instead of the plain one. - [Plain http traffic is not sent on to https](https://shipreadyai.dev/learn/findings/o1-https-redirect-missing.md): Someone who reaches the plain http address stays on an unencrypted connection, so anything typed on that page travels in the clear. - [The https address did not answer cleanly](https://shipreadyai.dev/learn/findings/o1-tls-failed.md): Browsers show a warning page or refuse the connection, so most visitors never reach the app at all. - [The page loads some files over plain http](https://shipreadyai.dev/learn/findings/o1-mixed-content.md): Browsers block or downgrade these files, so parts of the page can break, and the padlock treatment is lost. - [Every file on the page loads over https](https://shipreadyai.dev/learn/findings/o1-mixed-content-ok.md): Nothing on the page is pulled over a plain connection. - [Strict-Transport-Security is set](https://shipreadyai.dev/learn/findings/o2-hsts-ok.md): Browsers remember to use https for this domain on later visits. - [Strict-Transport-Security is not set](https://shipreadyai.dev/learn/findings/o2-hsts-missing.md): A browser that has been to the site before can still be pushed to the plain http version on a hostile network. - [Content-Security-Policy is set](https://shipreadyai.dev/learn/findings/o2-csp-ok.md): The page tells the browser which sources of scripts and styles it will accept. - [Content-Security-Policy is not set](https://shipreadyai.dev/learn/findings/o2-csp-missing.md): If any injected markup reaches a page, the browser has no rule telling it which scripts it is allowed to run. - [The content policy allows inline scripts](https://shipreadyai.dev/learn/findings/o2-csp-unsafe-inline.md): The script-src rule includes unsafe-inline, which removes most of the protection the policy would otherwise give. - [X-Content-Type-Options is set](https://shipreadyai.dev/learn/findings/o2-x-content-type-options-ok.md): Browsers will not guess a file type that differs from the one you declared. - [X-Content-Type-Options is not set](https://shipreadyai.dev/learn/findings/o2-x-content-type-options-missing.md): A browser may treat an uploaded or user supplied file as a script because it guesses the type. - [Framing is restricted](https://shipreadyai.dev/learn/findings/o2-frame-protection-ok.md): Other sites cannot silently place your pages inside their own. - [Framing is not restricted](https://shipreadyai.dev/learn/findings/o2-frame-protection-missing.md): Another site can load your pages inside an invisible frame and trick a signed in visitor into clicking things they cannot see. - [Referrer-Policy is set](https://shipreadyai.dev/learn/findings/o2-referrer-policy-ok.md): Outbound links do not carry the full address of the page the visitor came from. - [Referrer-Policy is not set](https://shipreadyai.dev/learn/findings/o2-referrer-policy-missing.md): Full page addresses, including anything you put in a path or query string, are sent to third party sites your pages link to or load from. - [Permissions-Policy is set](https://shipreadyai.dev/learn/findings/o2-permissions-policy-ok.md): Camera, microphone, and location access are limited to what you named. - [Permissions-Policy is not set](https://shipreadyai.dev/learn/findings/o2-permissions-policy-missing.md): Embedded third party frames can ask for camera, microphone, or location on your domain's behalf. - [Source maps are published next to the app code](https://shipreadyai.dev/learn/findings/o3-source-maps.md): Anyone can rebuild your original files, including comments, file names, and any logic you assumed was hidden. - [No published source maps were reachable](https://shipreadyai.dev/learn/findings/o3-source-maps-ok.md): The bundles checked did not resolve to a readable source map. - [A server side key appears in code the browser downloads](https://shipreadyai.dev/learn/findings/o4-secret-in-bundle.md): Anyone who opens the page can read this key and use it directly against the service it belongs to, with your account paying for it. - [No server side keys matched in the downloaded code](https://shipreadyai.dev/learn/findings/o4-secret-none.md): The known server key patterns did not appear in the files checked. Publishable and browser keys are expected there and are ignored. - [What the outside of the app reveals](https://shipreadyai.dev/learn/findings/o5-fingerprint.md): Anyone can see this from a browser. It is listed so you know what is on show. - [A response header names a software version](https://shipreadyai.dev/learn/findings/o5-version-disclosure.md): Naming the exact version tells anyone scanning the internet which known issues to try first against your host. - [A file that should not be public answers on the live site](https://shipreadyai.dev/learn/findings/o6-exposed-path.md): This file usually carries configuration, keys, or repository history, and it is readable by anyone who asks for it. - [The common private files did not answer](https://shipreadyai.dev/learn/findings/o6-exposed-path-ok.md): Requests for configuration and repository files came back empty or missing. - [Public information files](https://shipreadyai.dev/learn/findings/o6-public-files.md): These files tell crawlers and researchers how to treat the site. - [The hosting platform publishes its own check results](https://shipreadyai.dev/learn/findings/o7-trust-evidence.md): The platform reports the following checks for this app: {checks}. - [Some database tables answer without anyone signing in](https://shipreadyai.dev/learn/findings/o8-tables-exposed.md): A request made with the browser key alone returned rows, which means the row rules on those tables let anonymous readers in. - [The table list is not readable without signing in](https://shipreadyai.dev/learn/findings/o8-schema-not-readable.md): An anonymous request could not list the tables behind the app. - [A cookie is missing a protective flag](https://shipreadyai.dev/learn/findings/o9-cookie-flags.md): A cookie without Secure can travel over a plain connection, and one without HttpOnly can be read by any script on the page. - [Cookies on the first response look fine](https://shipreadyai.dev/learn/findings/o9-cookies-ok.md): No cookie was set without its protective flags on this response. - [No cookies were set on the first response](https://shipreadyai.dev/learn/findings/o9-no-cookies.md): The landing response set no cookies, so there were no flags to check. - [An SPF record is published](https://shipreadyai.dev/learn/findings/o10-spf-ok.md): Mail servers can see which services are allowed to send using your domain. - [No SPF record is published](https://shipreadyai.dev/learn/findings/o10-spf-missing.md): Anyone can send mail that claims to come from your domain, and your own mail is more likely to land in spam. - [A DMARC record is published](https://shipreadyai.dev/learn/findings/o10-dmarc-ok.md): You have told receiving servers what to do with mail that fails the checks. - [No DMARC record is published](https://shipreadyai.dev/learn/findings/o10-dmarc-missing.md): Receiving servers have no instruction for mail that fails the checks, so forged mail from your domain is more likely to be delivered. - [Mail records were not checked for this address](https://shipreadyai.dev/learn/findings/o10-shared-domain.md): The app is on a shared hosting domain ({domain}), so its mail records belong to the platform and not to you. - [A privacy page is linked](https://shipreadyai.dev/learn/findings/o11-privacy-ok.md): Visitors can find how their information is handled. - [No privacy page is linked](https://shipreadyai.dev/learn/findings/o11-privacy-missing.md): Payment providers, app stores, and several privacy laws expect a reachable privacy page before you take anyone's details. - [A terms page is linked](https://shipreadyai.dev/learn/findings/o11-terms-ok.md): Visitors can find the rules of using the product. - [No terms page is linked](https://shipreadyai.dev/learn/findings/o11-terms-missing.md): Without stated terms you have no written basis for suspending misuse or limiting your liability. - [A refund or returns page is linked](https://shipreadyai.dev/learn/findings/o11-refunds-ok.md): Buyers can see the refund position before they pay. - [No refund or returns page is linked](https://shipreadyai.dev/learn/findings/o11-refunds-missing.md): Card processors expect a stated refund position, and disputes are harder to answer without one. - [Functions callable by name from the public schema](https://shipreadyai.dev/learn/findings/o8-rpc-functions.md): The public schema names {total} functions callable by name: {functions}. Whether each checks authorization needs a code review. ShipReady lists the names and never calls them, which is why backend rules stay on the not verified list. - [The storage bucket list answers without a sign in](https://shipreadyai.dev/learn/findings/o12-buckets-listable.md): A request with the browser key returned the names of {total} storage buckets: {buckets}. Names alone give a reader the shape of what you store. - [Some storage buckets are readable by anyone with the address](https://shipreadyai.dev/learn/findings/o12-bucket-public.md): These buckets are marked public, so any file inside one can be read by anyone who knows or guesses its address: {buckets}. - [Storage buckets list their objects without a sign in](https://shipreadyai.dev/learn/findings/o12-objects-listable.md): An object list request carrying only the browser key came back from these buckets: {buckets}. The counts show how much is behind each name. ShipReady records names and counts and never keeps an object name or a file. - [Files in a listing bucket open without a session](https://shipreadyai.dev/learn/findings/o12-objects-readable.md): One object address from each of these buckets answered a plain request with no session: {buckets}. Anything stored there can be read by anyone who can list it. - [Storage did not answer an anonymous request](https://shipreadyai.dev/learn/findings/o12-storage-ok.md): The bucket listing did not come back to a request holding only the browser key. - [Any site can read your responses with a visitor's session](https://shipreadyai.dev/learn/findings/o13-cors-open-credentials.md): {path} answered a request from an outside origin with an allow origin of {origin} and credentials allowed, so a page on another domain can read responses using your visitor's session. - [Cross origin reads are open to every site](https://shipreadyai.dev/learn/findings/o13-cors-wildcard.md): {path} answered with an allow origin of {origin}, so any site can read what it returns. Without credentials that is only a problem for data you did not mean to publish. - [Cross origin rules are narrow or absent](https://shipreadyai.dev/learn/findings/o13-cors-ok.md): A request from an outside origin came back without a header inviting other sites to read the response. - [The domain registration comes up for renewal](https://shipreadyai.dev/learn/findings/o14-domain-renewal-due.md): The public registry record says {domain} expires on {expiry}, which is {days} days away. That is close enough to put a renewal on the calendar now. - [The domain registration expires soon](https://shipreadyai.dev/learn/findings/o14-domain-expiring.md): The public registry record says {domain} expires on {expiry}, which is {days} days away. An expired domain takes the app, the mail, and the sign in links with it. - [The domain registration has time left](https://shipreadyai.dev/learn/findings/o14-domain-ok.md): The public registry record says {domain} expires on {expiry}, {days} days away. - [The app runs on a shared platform domain](https://shipreadyai.dev/learn/findings/o14-domain-shared.md): {domain} belongs to the hosting platform, so there is no registration of yours to expire and no registry record to read. - [The Firebase database answers without a sign in](https://shipreadyai.dev/learn/findings/o15-firebase-database-open.md): A plain request to {endpoint} returned data with no sign in, so the rules on that database let anonymous readers in. - [Firebase storage listed its contents without a sign in](https://shipreadyai.dev/learn/findings/o15-firebase-storage-open.md): A plain request to {endpoint} returned an object listing with no sign in, so anyone can enumerate what is stored. - [Firestore collections answer without a sign in](https://shipreadyai.dev/learn/findings/o15-firestore-open.md): Requests with no sign in came back with documents from these collections: {collections}. ShipReady records the collection names and the counts and never keeps a document. - [Firebase endpoints did not answer an anonymous request](https://shipreadyai.dev/learn/findings/o15-firebase-ok.md): The database and storage endpoints refused a request that carried no sign in. - [Anyone can create an account](https://shipreadyai.dev/learn/findings/o16-signup-open.md): The public auth settings at {endpoint} report that self signup is on, so a script can create accounts at will. - [New accounts are confirmed automatically](https://shipreadyai.dev/learn/findings/o16-email-confirmation-info.md): The public auth settings report that new sign ups are confirmed automatically, so an account can be created with an address the person does not own. You did not declare customer data, so this is recorded rather than raised. - [Anonymous sign in is turned on](https://shipreadyai.dev/learn/findings/o16-anonymous-signin.md): The public auth settings at {endpoint} report anonymous sign in is on, so a caller can hold a session without ever giving an address. That is fine when it is deliberate and a problem when row rules assume a known person. - [New accounts are active before the address is confirmed](https://shipreadyai.dev/learn/findings/o16-email-confirmation-off.md): The public auth settings report that new sign ups are confirmed automatically, so an account can be created with an address the person does not own. - [Sign in methods published by the backend](https://shipreadyai.dev/learn/findings/o16-auth-settings.md): The public auth settings list these sign in methods: {providers}. - [The auth settings read as expected](https://shipreadyai.dev/learn/findings/o16-auth-ok.md): Self signup is closed and new accounts have to confirm their address. ## Plain http traffic is sent on to https https://shipreadyai.dev/learn/findings/o1-https-redirect-ok # Plain http traffic is sent on to https Visitors who type the address without https land on the encrypted version instead of the plain one. ## Why AI-built apps get this An AI builder gives you HTTPS on the hosted address and stops there. The moment you point your own domain at it, the redirect, the certificate and every hard-coded http:// in a copied snippet become yours. Nothing in the build warns you, because from the inside everything still works. ## Evidence line GET http://example.com returned 301 to https://example.com, certificate valid to 2026-12-01 ## The fix Nothing to change here. Keep the redirect in place when you move hosting. ## Prompt Keep the http to https redirect in place after any hosting change. ## Plain http traffic is not sent on to https https://shipreadyai.dev/learn/findings/o1-https-redirect-missing # Plain http traffic is not sent on to https Someone who reaches the plain http address stays on an unencrypted connection, so anything typed on that page travels in the clear. ## Why AI-built apps get this An AI builder gives you HTTPS on the hosted address and stops there. The moment you point your own domain at it, the redirect, the certificate and every hard-coded http:// in a copied snippet become yours. Nothing in the build warns you, because from the inside everything still works. ## Evidence line GET http://example.com returned 301 to https://example.com, certificate valid to 2026-12-01 ## The fix Turn on the force https or automatic https redirect setting in your hosting dashboard so the plain address answers with a redirect to https. ## Prompt Plain http requests to this app do not redirect to https. Turn on the force-https option in your hosting dashboard, or add a permanent redirect at the server. Verify with curl -I on the http address. ## The https address did not answer cleanly https://shipreadyai.dev/learn/findings/o1-tls-failed # The https address did not answer cleanly Browsers show a warning page or refuse the connection, so most visitors never reach the app at all. ## Why AI-built apps get this An AI builder gives you HTTPS on the hosted address and stops there. The moment you point your own domain at it, the redirect, the certificate and every hard-coded http:// in a copied snippet become yours. Nothing in the build warns you, because from the inside everything still works. ## Evidence line GET http://example.com returned 301 to https://example.com, certificate valid to 2026-12-01 ## The fix Check the certificate on your hosting or domain provider, renew it if it has lapsed, and make sure the domain points at the right host. ## Prompt The https certificate for this app failed validation. Check it has not expired, that the domain points at the right host, and that the certificate covers this exact hostname. Renew or re-issue it through your hosting or domain provider. ## The page loads some files over plain http https://shipreadyai.dev/learn/findings/o1-mixed-content # The page loads some files over plain http Browsers block or downgrade these files, so parts of the page can break, and the padlock treatment is lost. ## Why AI-built apps get this An AI builder gives you HTTPS on the hosted address and stops there. The moment you point your own domain at it, the redirect, the certificate and every hard-coded http:// in a copied snippet become yours. Nothing in the build warns you, because from the inside everything still works. ## Evidence line GET http://example.com returned 301 to https://example.com, certificate valid to 2026-12-01 ## The fix Change the http:// addresses in the page to https:// or to relative paths. First three seen: {examples}. ## Prompt Some assets load over plain http, for example {examples}. Change those addresses to https:// or to relative paths so the browser never mixes protocols. ## Every file on the page loads over https https://shipreadyai.dev/learn/findings/o1-mixed-content-ok # Every file on the page loads over https Nothing on the page is pulled over a plain connection. ## Why AI-built apps get this An AI builder gives you HTTPS on the hosted address and stops there. The moment you point your own domain at it, the redirect, the certificate and every hard-coded http:// in a copied snippet become yours. Nothing in the build warns you, because from the inside everything still works. ## Evidence line GET http://example.com returned 301 to https://example.com, certificate valid to 2026-12-01 ## The fix Nothing to change here. ## Prompt Keep all asset references on https. ## Strict-Transport-Security is set https://shipreadyai.dev/learn/findings/o2-hsts-ok # Strict-Transport-Security is set Browsers remember to use https for this domain on later visits. ## Why AI-built apps get this Response headers are written by nobody. Your framework does not add them, your builder does not add them, and your host adds one or two at most. They are the clearest example of a gap that no tool closes on your behalf, which is why almost every app built by a prompt ships without them. ## Evidence line GET https://example.com returned no strict-transport-security header ## The fix Nothing to change here. ## Prompt Keep the Strict-Transport-Security header in place. ## Strict-Transport-Security is not set https://shipreadyai.dev/learn/findings/o2-hsts-missing # Strict-Transport-Security is not set A browser that has been to the site before can still be pushed to the plain http version on a hostile network. ## Why AI-built apps get this Response headers are written by nobody. Your framework does not add them, your builder does not add them, and your host adds one or two at most. They are the clearest example of a gap that no tool closes on your behalf, which is why almost every app built by a prompt ships without them. ## Evidence line GET https://example.com returned no strict-transport-security header ## The fix Add a Strict-Transport-Security response header, for example max-age=31536000; includeSubDomains, in your hosting header settings. ## Prompt Set the Strict-Transport-Security response header to max-age=31536000; includeSubDomains on every HTML response. It tells browsers to keep using https after the first visit, so a visitor on public wifi never falls back to a plain connection. Add it wherever this app sets response headers: the server framework, a middleware, or the hosting platform's headers configuration. Verify by requesting the page with curl -I. ## Content-Security-Policy is set https://shipreadyai.dev/learn/findings/o2-csp-ok # Content-Security-Policy is set The page tells the browser which sources of scripts and styles it will accept. ## Why AI-built apps get this Response headers are written by nobody. Your framework does not add them, your builder does not add them, and your host adds one or two at most. They are the clearest example of a gap that no tool closes on your behalf, which is why almost every app built by a prompt ships without them. ## Evidence line GET https://example.com returned no strict-transport-security header ## The fix Nothing to change here. ## Prompt Keep the Content-Security-Policy header and tighten it as new sources are added. ## Content-Security-Policy is not set https://shipreadyai.dev/learn/findings/o2-csp-missing # Content-Security-Policy is not set If any injected markup reaches a page, the browser has no rule telling it which scripts it is allowed to run. ## Why AI-built apps get this Response headers are written by nobody. Your framework does not add them, your builder does not add them, and your host adds one or two at most. They are the clearest example of a gap that no tool closes on your behalf, which is why almost every app built by a prompt ships without them. ## Evidence line GET https://example.com returned no strict-transport-security header ## The fix Add a Content-Security-Policy response header, starting from default-src 'self' and adding the domains your app actually loads from. ## Prompt This app sends no Content-Security-Policy header. Add one that starts from default-src 'self' and lists only the sources your app really loads. Roll it out in report-only mode first, watch the browser console on every page, then enforce it. ## The content policy allows inline scripts https://shipreadyai.dev/learn/findings/o2-csp-unsafe-inline # The content policy allows inline scripts The script-src rule includes unsafe-inline, which removes most of the protection the policy would otherwise give. ## Why AI-built apps get this Response headers are written by nobody. Your framework does not add them, your builder does not add them, and your host adds one or two at most. They are the clearest example of a gap that no tool closes on your behalf, which is why almost every app built by a prompt ships without them. ## Evidence line GET https://example.com returned no strict-transport-security header ## The fix Remove unsafe-inline from script-src and move inline scripts into files, or use a nonce or hash. Observed: {value}. ## Prompt Your policy allows unsafe-inline for scripts ({value}). Use a nonce or hash for inline scripts instead, and move the rest into files, so the policy actually restricts what can run. ## X-Content-Type-Options is set https://shipreadyai.dev/learn/findings/o2-x-content-type-options-ok # X-Content-Type-Options is set Browsers will not guess a file type that differs from the one you declared. ## Why AI-built apps get this Response headers are written by nobody. Your framework does not add them, your builder does not add them, and your host adds one or two at most. They are the clearest example of a gap that no tool closes on your behalf, which is why almost every app built by a prompt ships without them. ## Evidence line GET https://example.com returned no strict-transport-security header ## The fix Nothing to change here. ## Prompt Keep the X-Content-Type-Options header set to nosniff. ## X-Content-Type-Options is not set https://shipreadyai.dev/learn/findings/o2-x-content-type-options-missing # X-Content-Type-Options is not set A browser may treat an uploaded or user supplied file as a script because it guesses the type. ## Why AI-built apps get this Response headers are written by nobody. Your framework does not add them, your builder does not add them, and your host adds one or two at most. They are the clearest example of a gap that no tool closes on your behalf, which is why almost every app built by a prompt ships without them. ## Evidence line GET https://example.com returned no strict-transport-security header ## The fix Add the response header X-Content-Type-Options: nosniff. ## Prompt Set the X-Content-Type-Options response header to nosniff on every HTML response. It stops browsers from guessing a file type and running a download as a script. Add it wherever this app sets response headers: the server framework, a middleware, or the hosting platform's headers configuration. Verify by requesting the page with curl -I. ## Framing is restricted https://shipreadyai.dev/learn/findings/o2-frame-protection-ok # Framing is restricted Other sites cannot silently place your pages inside their own. ## Why AI-built apps get this Response headers are written by nobody. Your framework does not add them, your builder does not add them, and your host adds one or two at most. They are the clearest example of a gap that no tool closes on your behalf, which is why almost every app built by a prompt ships without them. ## Evidence line GET https://example.com returned no strict-transport-security header ## The fix Nothing to change here. ## Prompt Keep the framing restriction in place. ## Framing is not restricted https://shipreadyai.dev/learn/findings/o2-frame-protection-missing # Framing is not restricted Another site can load your pages inside an invisible frame and trick a signed in visitor into clicking things they cannot see. ## Why AI-built apps get this Response headers are written by nobody. Your framework does not add them, your builder does not add them, and your host adds one or two at most. They are the clearest example of a gap that no tool closes on your behalf, which is why almost every app built by a prompt ships without them. ## Evidence line GET https://example.com returned no strict-transport-security header ## The fix Add X-Frame-Options: DENY, or a frame-ancestors 'none' directive in your content policy. ## Prompt Set the X-Frame-Options response header to DENY, and add frame-ancestors 'none' to the Content-Security-Policy (use SAMEORIGIN and 'self' only if the app embeds itself) on every HTML response. It stops another site from loading this app inside an invisible frame to hijack clicks. Add it wherever this app sets response headers: the server framework, a middleware, or the hosting platform's headers configuration. Verify by requesting the page with curl -I. ## Referrer-Policy is set https://shipreadyai.dev/learn/findings/o2-referrer-policy-ok # Referrer-Policy is set Outbound links do not carry the full address of the page the visitor came from. ## Why AI-built apps get this Response headers are written by nobody. Your framework does not add them, your builder does not add them, and your host adds one or two at most. They are the clearest example of a gap that no tool closes on your behalf, which is why almost every app built by a prompt ships without them. ## Evidence line GET https://example.com returned no strict-transport-security header ## The fix Nothing to change here. ## Prompt Keep the Referrer-Policy header in place. ## Referrer-Policy is not set https://shipreadyai.dev/learn/findings/o2-referrer-policy-missing # Referrer-Policy is not set Full page addresses, including anything you put in a path or query string, are sent to third party sites your pages link to or load from. ## Why AI-built apps get this Response headers are written by nobody. Your framework does not add them, your builder does not add them, and your host adds one or two at most. They are the clearest example of a gap that no tool closes on your behalf, which is why almost every app built by a prompt ships without them. ## Evidence line GET https://example.com returned no strict-transport-security header ## The fix Add the response header Referrer-Policy: strict-origin-when-cross-origin. ## Prompt Set the Referrer-Policy response header to strict-origin-when-cross-origin on every HTML response. It keeps full page URLs, which can carry ids and tokens, from being sent to other sites. Add it wherever this app sets response headers: the server framework, a middleware, or the hosting platform's headers configuration. Verify by requesting the page with curl -I. ## Permissions-Policy is set https://shipreadyai.dev/learn/findings/o2-permissions-policy-ok # Permissions-Policy is set Camera, microphone, and location access are limited to what you named. ## Why AI-built apps get this Response headers are written by nobody. Your framework does not add them, your builder does not add them, and your host adds one or two at most. They are the clearest example of a gap that no tool closes on your behalf, which is why almost every app built by a prompt ships without them. ## Evidence line GET https://example.com returned no strict-transport-security header ## The fix Nothing to change here. ## Prompt Keep the Permissions-Policy header in place. ## Permissions-Policy is not set https://shipreadyai.dev/learn/findings/o2-permissions-policy-missing # Permissions-Policy is not set Embedded third party frames can ask for camera, microphone, or location on your domain's behalf. ## Why AI-built apps get this Response headers are written by nobody. Your framework does not add them, your builder does not add them, and your host adds one or two at most. They are the clearest example of a gap that no tool closes on your behalf, which is why almost every app built by a prompt ships without them. ## Evidence line GET https://example.com returned no strict-transport-security header ## The fix Add a Permissions-Policy response header that turns off the features you do not use, for example camera=(), microphone=(), geolocation=(). ## Prompt Set the Permissions-Policy response header to camera=(), microphone=(), geolocation=(), adding back only a feature this app truly uses on every HTML response. It turns off browser capabilities the app never needs, so an injected script cannot ask for them. Add it wherever this app sets response headers: the server framework, a middleware, or the hosting platform's headers configuration. Verify by requesting the page with curl -I. ## Source maps are published next to the app code https://shipreadyai.dev/learn/findings/o3-source-maps # Source maps are published next to the app code Anyone can rebuild your original files, including comments, file names, and any logic you assumed was hidden. ## Why AI-built apps get this Source maps are on by default in development and a build setting away from being published. An agent optimising for a working deploy has no reason to turn them off, and nothing in your app looks different when they ship, so they sit there handing out your file names and comments. ## Evidence line https://example.com/assets/index-4f2a.js.map returned 200, 1.2 MB ## The fix Turn off source map output for production builds, or stop uploading the .map files. Seen at {map_url} for {bundle}. ## Prompt Your production source map is public at {map_url}. Turn off source map output for production builds, or stop uploading the .map files, so readers only get the compiled bundle. ## No published source maps were reachable https://shipreadyai.dev/learn/findings/o3-source-maps-ok # No published source maps were reachable The bundles checked did not resolve to a readable source map. ## Why AI-built apps get this Source maps are on by default in development and a build setting away from being published. An agent optimising for a working deploy has no reason to turn them off, and nothing in your app looks different when they ship, so they sit there handing out your file names and comments. ## Evidence line https://example.com/assets/index-4f2a.js.map returned 200, 1.2 MB ## The fix Nothing to change here. ## Prompt Keep production source maps out of the deployed output. ## A server side key appears in code the browser downloads https://shipreadyai.dev/learn/findings/o4-secret-in-bundle # A server side key appears in code the browser downloads Anyone who opens the page can read this key and use it directly against the service it belongs to, with your account paying for it. ## Why AI-built apps get this Agents copy configuration. When a service issues a public key and a secret one that look alike, the wrong one ends up in a client file, and the app keeps working perfectly, which is the problem. A scan of 5,600 vibe-coded apps found more than 400 exposed secrets this way. ## Evidence line assets/index-4f2a.js contains a key beginning sb_secret_ ## The fix Rotate the key at the provider straight away, move the call that needs it to a server function, and remove the key from anything the browser downloads. Pattern {pattern} found in {bundle}, starting {masked}. ## Prompt A server-side secret ({pattern}) is inside the JavaScript sent to browsers. Rotate it at the provider now, move the code that uses it to your server, and remove it from any frontend environment variable. ## No server side keys matched in the downloaded code https://shipreadyai.dev/learn/findings/o4-secret-none # No server side keys matched in the downloaded code The known server key patterns did not appear in the files checked. Publishable and browser keys are expected there and are ignored. ## Why AI-built apps get this Agents copy configuration. When a service issues a public key and a secret one that look alike, the wrong one ends up in a client file, and the app keeps working perfectly, which is the problem. A scan of 5,600 vibe-coded apps found more than 400 exposed secrets this way. ## Evidence line assets/index-4f2a.js contains a key beginning sb_secret_ ## The fix Nothing to change here. ## Prompt Keep server side keys out of client code. ## What the outside of the app reveals https://shipreadyai.dev/learn/findings/o5-fingerprint # What the outside of the app reveals Anyone can see this from a browser. It is listed so you know what is on show. ## Why AI-built apps get this Builders leave traces: a header, a build artefact, a familiar path, a meta tag nobody removed. On its own a fingerprint is harmless. It becomes useful to someone else when a class of issue is reported against a particular builder and they want a list of apps to try it on. ## Evidence line x-powered-by: Express, build artefact names the framework ## The fix Nothing to do unless something here is a surprise to you. ## Prompt Review what the public pages reveal about the tools behind the app. ## A response header names a software version https://shipreadyai.dev/learn/findings/o5-version-disclosure # A response header names a software version Naming the exact version tells anyone scanning the internet which known issues to try first against your host. ## Why AI-built apps get this Builders leave traces: a header, a build artefact, a familiar path, a meta tag nobody removed. On its own a fingerprint is harmless. It becomes useful to someone else when a class of issue is reported against a particular builder and they want a list of apps to try it on. ## Evidence line x-powered-by: Express, build artefact names the framework ## The fix Remove or shorten the Server and X-Powered-By headers in your hosting settings. Observed: {value}. ## Prompt Your responses announce the server software ({value}). Remove or shorten the Server and X-Powered-By headers in your server or hosting settings. ## A file that should not be public answers on the live site https://shipreadyai.dev/learn/findings/o6-exposed-path # A file that should not be public answers on the live site This file usually carries configuration, keys, or repository history, and it is readable by anyone who asks for it. ## Why AI-built apps get this Debug routes, admin pages and leftover files survive because nothing links to them. Nothing needs to. Address lists are guessed thousands at a time by tools that cost nothing to run, and an admin route with no check in front of it was one of the causes of the Moltbook exposure. ## Evidence line GET https://example.com/admin returned 200 ## The fix Stop deploying this path, add it to your ignore file, and rotate anything it contained. Path: {path}. ## Prompt The file at {path} is publicly readable. Stop deploying it, add it to your ignore file, and rotate any credentials it contained. ## The common private files did not answer https://shipreadyai.dev/learn/findings/o6-exposed-path-ok # The common private files did not answer Requests for configuration and repository files came back empty or missing. ## Why AI-built apps get this Debug routes, admin pages and leftover files survive because nothing links to them. Nothing needs to. Address lists are guessed thousands at a time by tools that cost nothing to run, and an admin route with no check in front of it was one of the causes of the Moltbook exposure. ## Evidence line GET https://example.com/admin returned 200 ## The fix Nothing to change here. ## Prompt Keep configuration and repository files out of the deployed output. ## Public information files https://shipreadyai.dev/learn/findings/o6-public-files # Public information files These files tell crawlers and researchers how to treat the site. ## Why AI-built apps get this Debug routes, admin pages and leftover files survive because nothing links to them. Nothing needs to. Address lists are guessed thousands at a time by tools that cost nothing to run, and an admin route with no check in front of it was one of the causes of the Moltbook exposure. ## Evidence line GET https://example.com/admin returned 200 ## The fix Nothing to do. A security.txt file gives researchers a way to reach you. ## Prompt Add a /.well-known/security.txt file with a contact address for reports. ## The hosting platform publishes its own check results https://shipreadyai.dev/learn/findings/o7-trust-evidence # The hosting platform publishes its own check results The platform reports the following checks for this app: {checks}. ## Why AI-built apps get this Trust evidence is the page a serious buyer looks for before they take you seriously. It never gets written, because it is not a feature and no agent suggests it. The cost of not having it is not a breach, it is a stalled conversation you never hear about. ## Evidence line GET https://example.com/.well-known/trust returned 404 ## The fix Read the full report at {url}. ## Prompt Read the platform trust report and note which checks it covers. ## Some database tables answer without anyone signing in https://shipreadyai.dev/learn/findings/o8-tables-exposed # Some database tables answer without anyone signing in A request made with the browser key alone returned rows, which means the row rules on those tables let anonymous readers in. ## Why AI-built apps get this AI builders create tables in seconds and leave the access rules for later. The browser key is published in your app by design, so a table with no rule behind it answers anyone who copies that key. This is CVE-2025-48757 across 170 apps, and the Moltbook exposure, in one sentence. ## Evidence line table profiles answered the published browser key with 42 rows ## The fix Turn on row level rules for each table listed and write a policy scoped to the signed in owner. Tables returning rows: {tables} of {total} readable. ## Prompt These tables return rows to anyone with your public key: {tables}. Turn on row level security for each and add policies that only let the signed-in owner read their own rows. ## The table list is not readable without signing in https://shipreadyai.dev/learn/findings/o8-schema-not-readable # The table list is not readable without signing in An anonymous request could not list the tables behind the app. ## Why AI-built apps get this AI builders create tables in seconds and leave the access rules for later. The browser key is published in your app by design, so a table with no rule behind it answers anyone who copies that key. This is CVE-2025-48757 across 170 apps, and the Moltbook exposure, in one sentence. ## Evidence line table profiles answered the published browser key with 42 rows ## The fix Nothing to change here. ## Prompt Keep the table list closed to anonymous readers. ## A cookie is missing a protective flag https://shipreadyai.dev/learn/findings/o9-cookie-flags # A cookie is missing a protective flag A cookie without Secure can travel over a plain connection, and one without HttpOnly can be read by any script on the page. ## Why AI-built apps get this Session cookies come from whatever library the agent reached for, with whatever defaults it ships. Secure, HttpOnly and SameSite are three small settings that turn a scripting bug into an account takeover when they are missing, and nothing in your app looks wrong when they are. ## Evidence line set-cookie: session=abc; Path=/ with no HttpOnly and no SameSite ## The fix Set Secure, HttpOnly, and a SameSite value on the cookie where you create it. Cookie {name} is missing {missing}. ## Prompt The cookie {name} is missing {missing}. Add the Secure, HttpOnly, and SameSite attributes where you create it. ## Cookies on the first response look fine https://shipreadyai.dev/learn/findings/o9-cookies-ok # Cookies on the first response look fine No cookie was set without its protective flags on this response. ## Why AI-built apps get this Session cookies come from whatever library the agent reached for, with whatever defaults it ships. Secure, HttpOnly and SameSite are three small settings that turn a scripting bug into an account takeover when they are missing, and nothing in your app looks wrong when they are. ## Evidence line set-cookie: session=abc; Path=/ with no HttpOnly and no SameSite ## The fix Nothing to change here. ## Prompt Keep the protective flags on every cookie. ## No cookies were set on the first response https://shipreadyai.dev/learn/findings/o9-no-cookies # No cookies were set on the first response The landing response set no cookies, so there were no flags to check. ## Why AI-built apps get this Session cookies come from whatever library the agent reached for, with whatever defaults it ships. Secure, HttpOnly and SameSite are three small settings that turn a scripting bug into an account takeover when they are missing, and nothing in your app looks wrong when they are. ## Evidence line set-cookie: session=abc; Path=/ with no HttpOnly and no SameSite ## The fix Nothing to change here. ## Prompt Keep protective flags on any cookie added later. ## An SPF record is published https://shipreadyai.dev/learn/findings/o10-spf-ok # An SPF record is published Mail servers can see which services are allowed to send using your domain. ## Why AI-built apps get this Mail records live in DNS, not in your code, so no coding agent touches them. The result is a password reset that lands in spam and a domain anybody can send mail as. It is one of the few serious items on a result that is fixed entirely outside the app. ## Evidence line no TXT record beginning v=spf1 found for example.com ## The fix Nothing to change here. ## Prompt Keep the SPF record up to date as sending services change. ## No SPF record is published https://shipreadyai.dev/learn/findings/o10-spf-missing # No SPF record is published Anyone can send mail that claims to come from your domain, and your own mail is more likely to land in spam. ## Why AI-built apps get this Mail records live in DNS, not in your code, so no coding agent touches them. The result is a password reset that lands in spam and a domain anybody can send mail as. It is one of the few serious items on a result that is fixed entirely outside the app. ## Evidence line no TXT record beginning v=spf1 found for example.com ## The fix Add a TXT record at the root of the domain listing your sending services, for example v=spf1 include:yoursender.com -all. Observed: {value}. ## Prompt The domain {domain} has no SPF record. Add a TXT record at the root listing the services that send mail for you, ending in -all. ## A DMARC record is published https://shipreadyai.dev/learn/findings/o10-dmarc-ok # A DMARC record is published You have told receiving servers what to do with mail that fails the checks. ## Why AI-built apps get this Mail records live in DNS, not in your code, so no coding agent touches them. The result is a password reset that lands in spam and a domain anybody can send mail as. It is one of the few serious items on a result that is fixed entirely outside the app. ## Evidence line no TXT record beginning v=spf1 found for example.com ## The fix Nothing to change here. ## Prompt Keep the DMARC record and review the reports it produces. ## No DMARC record is published https://shipreadyai.dev/learn/findings/o10-dmarc-missing # No DMARC record is published Receiving servers have no instruction for mail that fails the checks, so forged mail from your domain is more likely to be delivered. ## Why AI-built apps get this Mail records live in DNS, not in your code, so no coding agent touches them. The result is a password reset that lands in spam and a domain anybody can send mail as. It is one of the few serious items on a result that is fixed entirely outside the app. ## Evidence line no TXT record beginning v=spf1 found for example.com ## The fix Add a TXT record at _dmarc on your domain, starting with v=DMARC1; p=none; and a reporting address, then tighten it later. Observed: {value}. ## Prompt The domain {domain} has no DMARC record. Add a TXT record at _dmarc.{domain} starting with v=DMARC1; p=none; and a reporting address, then tighten it once reports look clean. ## Mail records were not checked for this address https://shipreadyai.dev/learn/findings/o10-shared-domain # Mail records were not checked for this address The app is on a shared hosting domain ({domain}), so its mail records belong to the platform and not to you. ## Why AI-built apps get this Mail records live in DNS, not in your code, so no coding agent touches them. The result is a password reset that lands in spam and a domain anybody can send mail as. It is one of the few serious items on a result that is fixed entirely outside the app. ## Evidence line no TXT record beginning v=spf1 found for example.com ## The fix Check SPF and DMARC on your own domain once you connect one. ## Prompt Connect a custom domain and then set up SPF and DMARC records on it. ## A privacy page is linked https://shipreadyai.dev/learn/findings/o11-privacy-ok # A privacy page is linked Visitors can find how their information is handled. ## Why AI-built apps get this Legal pages get postponed until the day a payment provider asks for them. Then they arrive as a template that mentions a company that is not yours. A real privacy, terms and refunds page for this specific app is a launch requirement, not paperwork for later. ## Evidence line no link to a privacy page found in the footer of https://example.com ## The fix Nothing to change here. ## Prompt Keep the privacy page linked from the footer. ## No privacy page is linked https://shipreadyai.dev/learn/findings/o11-privacy-missing # No privacy page is linked Payment providers, app stores, and several privacy laws expect a reachable privacy page before you take anyone's details. ## Why AI-built apps get this Legal pages get postponed until the day a payment provider asks for them. Then they arrive as a template that mentions a company that is not yours. A real privacy, terms and refunds page for this specific app is a launch requirement, not paperwork for later. ## Evidence line no link to a privacy page found in the footer of https://example.com ## The fix Write a privacy page covering what you collect, why, and who you share it with, then link it from the footer. ## Prompt Create a real privacy policy page at /privacy and link it from the footer on every page. It must cover what data the app collects, why, how long it is kept, who it is shared with, and how to request deletion, written for this specific app with no placeholder text and no lorem ipsum. ## A terms page is linked https://shipreadyai.dev/learn/findings/o11-terms-ok # A terms page is linked Visitors can find the rules of using the product. ## Why AI-built apps get this Legal pages get postponed until the day a payment provider asks for them. Then they arrive as a template that mentions a company that is not yours. A real privacy, terms and refunds page for this specific app is a launch requirement, not paperwork for later. ## Evidence line no link to a privacy page found in the footer of https://example.com ## The fix Nothing to change here. ## Prompt Keep the terms page linked from the footer. ## No terms page is linked https://shipreadyai.dev/learn/findings/o11-terms-missing # No terms page is linked Without stated terms you have no written basis for suspending misuse or limiting your liability. ## Why AI-built apps get this Legal pages get postponed until the day a payment provider asks for them. Then they arrive as a template that mentions a company that is not yours. A real privacy, terms and refunds page for this specific app is a launch requirement, not paperwork for later. ## Evidence line no link to a privacy page found in the footer of https://example.com ## The fix Write a terms page covering acceptable use, payment, and cancellation, then link it from the footer. ## Prompt Create a real terms of service page at /terms and link it from the footer on every page. It must cover what the service is, acceptable use, payment and cancellation terms, limitation of liability, and governing law, written for this specific app with no placeholder text and no lorem ipsum. ## A refund or returns page is linked https://shipreadyai.dev/learn/findings/o11-refunds-ok # A refund or returns page is linked Buyers can see the refund position before they pay. ## Why AI-built apps get this Legal pages get postponed until the day a payment provider asks for them. Then they arrive as a template that mentions a company that is not yours. A real privacy, terms and refunds page for this specific app is a launch requirement, not paperwork for later. ## Evidence line no link to a privacy page found in the footer of https://example.com ## The fix Nothing to change here. ## Prompt Keep the refund page linked from the footer. ## No refund or returns page is linked https://shipreadyai.dev/learn/findings/o11-refunds-missing # No refund or returns page is linked Card processors expect a stated refund position, and disputes are harder to answer without one. ## Why AI-built apps get this Legal pages get postponed until the day a payment provider asks for them. Then they arrive as a template that mentions a company that is not yours. A real privacy, terms and refunds page for this specific app is a launch requirement, not paperwork for later. ## Evidence line no link to a privacy page found in the footer of https://example.com ## The fix Write a short refund page stating the window and the process, then link it from the footer. ## Prompt Create a real refund policy page at /refunds and link it from the footer on every page. It must cover which purchases are refundable, the time window, and how to request one, written for this specific app with no placeholder text and no lorem ipsum. ## Functions callable by name from the public schema https://shipreadyai.dev/learn/findings/o8-rpc-functions # Functions callable by name from the public schema The public schema names {total} functions callable by name: {functions}. Whether each checks authorization needs a code review. ShipReady lists the names and never calls them, which is why backend rules stay on the not verified list. ## Why AI-built apps get this AI builders create tables in seconds and leave the access rules for later. The browser key is published in your app by design, so a table with no rule behind it answers anyone who copies that key. This is CVE-2025-48757 across 170 apps, and the Moltbook exposure, in one sentence. ## Evidence line table profiles answered the published browser key with 42 rows ## The fix Open each function and confirm it checks the caller before it does anything, or take it out of the public schema. ## Prompt Review every function exposed in the public schema, confirm each one checks the caller, and move the rest out of the public schema. ## The storage bucket list answers without a sign in https://shipreadyai.dev/learn/findings/o12-buckets-listable # The storage bucket list answers without a sign in A request with the browser key returned the names of {total} storage buckets: {buckets}. Names alone give a reader the shape of what you store. ## Why AI-built apps get this File storage is created the moment an app needs an upload, and the bucket is public because that is the setting that makes the first upload appear on the page. Nothing later goes back to close it, and every file added after that inherits the decision. ## Evidence line the bucket listing answered the published browser key with 4 buckets, 2 of them public ## The fix Restrict the bucket listing to signed in callers, and keep only the buckets you meant to publish public. ## Prompt Restrict the storage bucket listing so it does not answer an anonymous request, and review which buckets are marked public. ## Some storage buckets are readable by anyone with the address https://shipreadyai.dev/learn/findings/o12-bucket-public # Some storage buckets are readable by anyone with the address These buckets are marked public, so any file inside one can be read by anyone who knows or guesses its address: {buckets}. ## Why AI-built apps get this File storage is created the moment an app needs an upload, and the bucket is public because that is the setting that makes the first upload appear on the page. Nothing later goes back to close it, and every file added after that inherits the decision. ## Evidence line the bucket listing answered the published browser key with 4 buckets, 2 of them public ## The fix Make each bucket private unless every file in it is meant for the open internet, and serve private files through short lived links instead. ## Prompt Set every storage bucket that holds customer files to private and serve those files through short lived signed links. ## Storage buckets list their objects without a sign in https://shipreadyai.dev/learn/findings/o12-objects-listable # Storage buckets list their objects without a sign in An object list request carrying only the browser key came back from these buckets: {buckets}. The counts show how much is behind each name. ShipReady records names and counts and never keeps an object name or a file. ## Why AI-built apps get this File storage is created the moment an app needs an upload, and the bucket is public because that is the setting that makes the first upload appear on the page. Nothing later goes back to close it, and every file added after that inherits the decision. ## Evidence line the bucket listing answered the published browser key with 4 buckets, 2 of them public ## The fix Require a signed in caller to list objects, and scope each bucket's rules to the person who owns the file. ## Prompt Require an authenticated caller to list objects in every storage bucket, scoped to the owner of each file. ## Files in a listing bucket open without a session https://shipreadyai.dev/learn/findings/o12-objects-readable # Files in a listing bucket open without a session One object address from each of these buckets answered a plain request with no session: {buckets}. Anything stored there can be read by anyone who can list it. ## Why AI-built apps get this File storage is created the moment an app needs an upload, and the bucket is public because that is the setting that makes the first upload appear on the page. Nothing later goes back to close it, and every file added after that inherits the decision. ## Evidence line the bucket listing answered the published browser key with 4 buckets, 2 of them public ## The fix Make those buckets private and hand out short lived links for the files people are meant to see. ## Prompt Make every bucket holding customer files private and serve those files through short lived signed links. ## Storage did not answer an anonymous request https://shipreadyai.dev/learn/findings/o12-storage-ok # Storage did not answer an anonymous request The bucket listing did not come back to a request holding only the browser key. ## Why AI-built apps get this File storage is created the moment an app needs an upload, and the bucket is public because that is the setting that makes the first upload appear on the page. Nothing later goes back to close it, and every file added after that inherits the decision. ## Evidence line the bucket listing answered the published browser key with 4 buckets, 2 of them public ## The fix Nothing to change here. ## Prompt Keep the storage bucket listing closed to anonymous requests. ## Any site can read your responses with a visitor's session https://shipreadyai.dev/learn/findings/o13-cors-open-credentials # Any site can read your responses with a visitor's session {path} answered a request from an outside origin with an allow origin of {origin} and credentials allowed, so a page on another domain can read responses using your visitor's session. ## Why AI-built apps get this Cross origin rules get widened during development, when a local page needs to talk to a deployed backend. The wildcard that unblocked the afternoon stays in the deployed version, because nothing about it fails afterwards. ## Evidence line GET /api/ with an outside origin returned access-control-allow-origin: * with credentials allowed ## The fix Replace the reflected origin with a fixed list of your own addresses, or turn credentials off for cross origin requests. ## Prompt Replace the reflected cross origin allow header with an explicit list of allowed origins, and only allow credentials for those origins. ## Cross origin reads are open to every site https://shipreadyai.dev/learn/findings/o13-cors-wildcard # Cross origin reads are open to every site {path} answered with an allow origin of {origin}, so any site can read what it returns. Without credentials that is only a problem for data you did not mean to publish. ## Why AI-built apps get this Cross origin rules get widened during development, when a local page needs to talk to a deployed backend. The wildcard that unblocked the afternoon stays in the deployed version, because nothing about it fails afterwards. ## Evidence line GET /api/ with an outside origin returned access-control-allow-origin: * with credentials allowed ## The fix Name the origins that are allowed to read the response instead of allowing all of them. ## Prompt Set the cross origin allow origin header to an explicit list of your own addresses instead of a wildcard. ## Cross origin rules are narrow or absent https://shipreadyai.dev/learn/findings/o13-cors-ok # Cross origin rules are narrow or absent A request from an outside origin came back without a header inviting other sites to read the response. ## Why AI-built apps get this Cross origin rules get widened during development, when a local page needs to talk to a deployed backend. The wildcard that unblocked the afternoon stays in the deployed version, because nothing about it fails afterwards. ## Evidence line GET /api/ with an outside origin returned access-control-allow-origin: * with credentials allowed ## The fix Nothing to change here. ## Prompt Keep the cross origin allow list limited to your own addresses. ## The domain registration comes up for renewal https://shipreadyai.dev/learn/findings/o14-domain-renewal-due # The domain registration comes up for renewal The public registry record says {domain} expires on {expiry}, which is {days} days away. That is close enough to put a renewal on the calendar now. ## Why AI-built apps get this A domain is bought once, in a hurry, on a card that later expires. The registration sits quietly for a year and then takes the app, the mail and every sign in link with it on a date nobody has written down. ## Evidence line the public registry record gives an expiry date of 2026-10-30, 46 days away ## The fix Renew the domain and turn on automatic renewal with a card that does not expire before the domain does. ## Prompt Renew the domain registration and turn on automatic renewal at the registrar. ## The domain registration expires soon https://shipreadyai.dev/learn/findings/o14-domain-expiring # The domain registration expires soon The public registry record says {domain} expires on {expiry}, which is {days} days away. An expired domain takes the app, the mail, and the sign in links with it. ## Why AI-built apps get this A domain is bought once, in a hurry, on a card that later expires. The registration sits quietly for a year and then takes the app, the mail and every sign in link with it on a date nobody has written down. ## Evidence line the public registry record gives an expiry date of 2026-10-30, 46 days away ## The fix Renew the domain and turn on automatic renewal with a card that does not expire before the domain does. ## Prompt Renew the domain registration and turn on automatic renewal at the registrar. ## The domain registration has time left https://shipreadyai.dev/learn/findings/o14-domain-ok # The domain registration has time left The public registry record says {domain} expires on {expiry}, {days} days away. ## Why AI-built apps get this A domain is bought once, in a hurry, on a card that later expires. The registration sits quietly for a year and then takes the app, the mail and every sign in link with it on a date nobody has written down. ## Evidence line the public registry record gives an expiry date of 2026-10-30, 46 days away ## The fix Nothing to change here. Keep automatic renewal on. ## Prompt Keep automatic renewal on for the domain. ## The app runs on a shared platform domain https://shipreadyai.dev/learn/findings/o14-domain-shared # The app runs on a shared platform domain {domain} belongs to the hosting platform, so there is no registration of yours to expire and no registry record to read. ## Why AI-built apps get this A domain is bought once, in a hurry, on a card that later expires. The registration sits quietly for a year and then takes the app, the mail and every sign in link with it on a date nobody has written down. ## Evidence line the public registry record gives an expiry date of 2026-10-30, 46 days away ## The fix Nothing to change here. A domain of your own becomes worth checking once you connect one. ## Prompt Connect a custom domain when the product is ready for one. ## The Firebase database answers without a sign in https://shipreadyai.dev/learn/findings/o15-firebase-database-open # The Firebase database answers without a sign in A plain request to {endpoint} returned data with no sign in, so the rules on that database let anonymous readers in. ## Why AI-built apps get this Firebase ships with open rules while you build, and the console says so. Turning them into real rules is a separate task with no deadline attached, and the app behaves identically either way. ## Evidence line GET https://example-app.firebaseio.com/.json returned 200 with data ## The fix Replace the open rules with rules that require an authenticated caller and scope each path to its owner. ## Prompt Rewrite the Firebase database rules so no path is readable or writable without an authenticated caller scoped to the owner. ## Firebase storage listed its contents without a sign in https://shipreadyai.dev/learn/findings/o15-firebase-storage-open # Firebase storage listed its contents without a sign in A plain request to {endpoint} returned an object listing with no sign in, so anyone can enumerate what is stored. ## Why AI-built apps get this Firebase ships with open rules while you build, and the console says so. Turning them into real rules is a separate task with no deadline attached, and the app behaves identically either way. ## Evidence line GET https://example-app.firebaseio.com/.json returned 200 with data ## The fix Close the storage rules to authenticated callers and serve public files through your own addresses. ## Prompt Close the Firebase storage rules so listing and reading require an authenticated caller. ## Firestore collections answer without a sign in https://shipreadyai.dev/learn/findings/o15-firestore-open # Firestore collections answer without a sign in Requests with no sign in came back with documents from these collections: {collections}. ShipReady records the collection names and the counts and never keeps a document. ## Why AI-built apps get this Firebase ships with open rules while you build, and the console says so. Turning them into real rules is a separate task with no deadline attached, and the app behaves identically either way. ## Evidence line GET https://example-app.firebaseio.com/.json returned 200 with data ## The fix Rewrite the Firestore rules so every read requires an authenticated caller scoped to the owner of the document. ## Prompt Rewrite the Firestore rules so no collection is readable without an authenticated caller scoped to the owner. ## Firebase endpoints did not answer an anonymous request https://shipreadyai.dev/learn/findings/o15-firebase-ok # Firebase endpoints did not answer an anonymous request The database and storage endpoints refused a request that carried no sign in. ## Why AI-built apps get this Firebase ships with open rules while you build, and the console says so. Turning them into real rules is a separate task with no deadline attached, and the app behaves identically either way. ## Evidence line GET https://example-app.firebaseio.com/.json returned 200 with data ## The fix Nothing to change here. ## Prompt Keep the Firebase rules closed to anonymous callers. ## Anyone can create an account https://shipreadyai.dev/learn/findings/o16-signup-open # Anyone can create an account The public auth settings at {endpoint} report that self signup is on, so a script can create accounts at will. ## Why AI-built apps get this Backend sign in settings default to whatever gets a first account created fastest. Open signup and automatic confirmation are the defaults that make the demo work, and they are still the defaults on the day the product goes public. ## Evidence line the public auth settings report mailer_autoconfirm: true ## The fix Turn self signup off if the product is invite only, and put a rate limit in front of the signup route either way. ## Prompt Turn off open self signup in the backend auth settings if the product is invite only, and rate limit the signup route. ## New accounts are confirmed automatically https://shipreadyai.dev/learn/findings/o16-email-confirmation-info # New accounts are confirmed automatically The public auth settings report that new sign ups are confirmed automatically, so an account can be created with an address the person does not own. You did not declare customer data, so this is recorded rather than raised. ## Why AI-built apps get this Backend sign in settings default to whatever gets a first account created fastest. Open signup and automatic confirmation are the defaults that make the demo work, and they are still the defaults on the day the product goes public. ## Evidence line the public auth settings report mailer_autoconfirm: true ## The fix Turn email confirmation on before the app starts holding anything that belongs to a person. ## Prompt Turn on email confirmation for new sign ups in the backend auth settings. ## Anonymous sign in is turned on https://shipreadyai.dev/learn/findings/o16-anonymous-signin # Anonymous sign in is turned on The public auth settings at {endpoint} report anonymous sign in is on, so a caller can hold a session without ever giving an address. That is fine when it is deliberate and a problem when row rules assume a known person. ## Why AI-built apps get this Backend sign in settings default to whatever gets a first account created fastest. Open signup and automatic confirmation are the defaults that make the demo work, and they are still the defaults on the day the product goes public. ## Evidence line the public auth settings report mailer_autoconfirm: true ## The fix Turn anonymous sign in off if the product does not use it, and check that no row rule treats an anonymous session as a known customer. ## Prompt Turn off anonymous sign in unless the product needs it, and confirm no row rule treats an anonymous session as an identified user. ## New accounts are active before the address is confirmed https://shipreadyai.dev/learn/findings/o16-email-confirmation-off # New accounts are active before the address is confirmed The public auth settings report that new sign ups are confirmed automatically, so an account can be created with an address the person does not own. ## Why AI-built apps get this Backend sign in settings default to whatever gets a first account created fastest. Open signup and automatic confirmation are the defaults that make the demo work, and they are still the defaults on the day the product goes public. ## Evidence line the public auth settings report mailer_autoconfirm: true ## The fix Turn email confirmation on so an address has to be proved before the account works. ## Prompt Turn on email confirmation for new sign ups in the backend auth settings. ## Sign in methods published by the backend https://shipreadyai.dev/learn/findings/o16-auth-settings # Sign in methods published by the backend The public auth settings list these sign in methods: {providers}. ## Why AI-built apps get this Backend sign in settings default to whatever gets a first account created fastest. Open signup and automatic confirmation are the defaults that make the demo work, and they are still the defaults on the day the product goes public. ## Evidence line the public auth settings report mailer_autoconfirm: true ## The fix Confirm each one is a method you meant to turn on, and turn the rest off. ## Prompt List the sign in providers enabled on the backend and turn off the ones the product does not use. ## The auth settings read as expected https://shipreadyai.dev/learn/findings/o16-auth-ok # The auth settings read as expected Self signup is closed and new accounts have to confirm their address. ## Why AI-built apps get this Backend sign in settings default to whatever gets a first account created fastest. Open signup and automatic confirmation are the defaults that make the demo work, and they are still the defaults on the day the product goes public. ## Evidence line the public auth settings report mailer_autoconfirm: true ## The fix Nothing to change here. ## Prompt Keep signup and confirmation settings as they are. ## What we cannot see, and say so https://shipreadyai.dev/learn/verify # What we cannot see, and say so The nine items no check of a public address can verify, with how to check each one yourself. - [Rollback and recovery](https://shipreadyai.dev/learn/verify/rollback.md): Whether you can put the previous version back, and how long that takes. - [Error monitoring](https://shipreadyai.dev/learn/verify/error-monitoring.md): Whether a failure in production reaches a human rather than sitting in a log nobody opens. - [Sign in and account flows](https://shipreadyai.dev/learn/verify/auth-flows.md): Whether sign in, password or code reset, and session expiry behave under real use. - [Rate limiting and abuse controls](https://shipreadyai.dev/learn/verify/rate-limiting.md): Whether a script can hammer your forms, sign up loop, or paid endpoints without being slowed down. - [Key rotation](https://shipreadyai.dev/learn/verify/secret-rotation.md): Whether you can replace a leaked key quickly and know everywhere it is used. - [Payment handling](https://shipreadyai.dev/learn/verify/payments.md): Whether payment events are verified, replay safe, and matched to the right customer record. - [Customer data handling](https://shipreadyai.dev/learn/verify/customer-data.md): Whether stored personal details are limited, deletable on request, and out of your logs. - [AI feature controls](https://shipreadyai.dev/learn/verify/ai-features.md): Whether prompts, spend, and model output are bounded so one visitor cannot run up the bill. - [Database row rules](https://shipreadyai.dev/learn/verify/backend-rules.md): Whether the row rules behind the app actually stop one signed in account reading another's rows. - [Certificate expiry date](https://shipreadyai.dev/learn/verify/certificate-expiry.md): Whether the certificate is close to expiring. A normal request proves the certificate is valid right now, and the runtime this check uses cannot read the expiry date from that request. - [One account reading another account's data](https://shipreadyai.dev/learn/verify/cross-user-access.md): Whether a signed in account can reach another account's records by changing an id. ShipReady does not create accounts, sign in, or call your functions, so this cannot be answered from outside. ## Rollback and recovery https://shipreadyai.dev/learn/verify/rollback # Rollback and recovery Whether you can put the previous version back, and how long that takes. ## Why a check from outside cannot see it Recovery is a property of your deployment history and your data, not of a page. From the street, an app that can be restored in two minutes looks exactly like one that cannot be restored at all. ## How to check it yourself 1. Deploy a change so small it does not matter, such as a word in the footer. 2. Roll it back using whatever your host gives you, and start a timer when you click. 3. Write down the time, then ask the harder question: what would you do if the change had touched data. ## What a Launch Review does instead A reviewer deploys a trivial change, rolls it back, times it, and writes down what the data would have needed. ## Error monitoring https://shipreadyai.dev/learn/verify/error-monitoring # Error monitoring Whether a failure in production reaches a human rather than sitting in a log nobody opens. ## Why a check from outside cannot see it Whether a failure reaches a human happens after the response is sent. A visitor sees an error page. Nobody outside can see whether anyone was told. ## How to check it yourself 1. Add a route or a button that throws a deliberate error in production. 2. Trigger it once, then put your phone down and wait five minutes. 3. If nothing told you, you have no monitoring. Wire one alert to somewhere you actually look. ## What a Launch Review does instead A reviewer triggers a deliberate failure in production and records whether anything reached a person, and how fast. ## Sign in and account flows https://shipreadyai.dev/learn/verify/auth-flows # Sign in and account flows Whether sign in, password or code reset, and session expiry behave under real use. ## Why a check from outside cannot see it A check never signs in. It has no account, no password and no permission to create one, so every behaviour behind the login is out of reach by design. ## How to check it yourself 1. Create two accounts and sign in to each in a different browser. 2. Copy a private address from the first account and open it in the second. 3. Then try the same through the API rather than the interface, because the two often disagree. ## What a Launch Review does instead A reviewer signs in with two accounts, crosses the boundary on purpose, and checks session expiry and reset behaviour. ## Rate limiting and abuse controls https://shipreadyai.dev/learn/verify/rate-limiting # Rate limiting and abuse controls Whether a script can hammer your forms, sign up loop, or paid endpoints without being slowed down. ## Why a check from outside cannot see it Testing a rate limit means sending the traffic that triggers it. That is an attack on your app, and a check that runs on a stranger's URL must not do it. ## How to check it yourself 1. Pick your most expensive endpoint: sign up, password reset, or anything that calls a model. 2. Send the same request fifty times in a minute from one machine. 3. Count how many succeeded and what it cost. If the answer is fifty and nothing slowed down, you have no limit. ## What a Launch Review does instead A reviewer sends controlled repeat traffic to your forms and paid endpoints, with your permission, and records what stopped it. ## Key rotation https://shipreadyai.dev/learn/verify/secret-rotation # Key rotation Whether you can replace a leaked key quickly and know everywhere it is used. ## Why a check from outside cannot see it Keys are stored in a console, not in the page. A check can see a key that leaked into a bundle, and nothing at all about the ones that were stored correctly. ## How to check it yourself 1. List every key the app uses and write down where each one is stored. 2. Rotate one of them in the provider console. 3. Deploy, then see what broke. What broke is the list of places that key was quietly copied to. ## What a Launch Review does instead A reviewer lists every key the app uses and where it lives, then walks the rotation path for one of them. ## Payment handling https://shipreadyai.dev/learn/verify/payments # Payment handling Whether payment events are verified, replay safe, and matched to the right customer record. ## Why a check from outside cannot see it Payment handling lives in a webhook endpoint that only your provider is supposed to call. Reaching it from outside would mean forging a request, which is exactly what should fail. ## How to check it yourself 1. Take a real payment event from your provider's dashboard. 2. Replay it twice to your endpoint. 3. Check the customer has exactly one entitlement and one record, then remove the signature and confirm the second attempt is refused. ## What a Launch Review does instead A reviewer replays a payment event twice and confirms the customer is granted access exactly once. ## Customer data handling https://shipreadyai.dev/learn/verify/customer-data # Customer data handling Whether stored personal details are limited, deletable on request, and out of your logs. ## Why a check from outside cannot see it What you store, how long you keep it and what ends up in your logs are all invisible from the outside. The interface shows a form, not a retention policy. ## How to check it yourself 1. Search your logs for an email address you know is in the database. 2. List every field you store and cross out the ones your product does not need. 3. Try deleting one account end to end and see whether anything is left behind. ## What a Launch Review does instead A reviewer reads what is stored, searches the logs for a value that should not be there, and checks the deletion path. ## AI feature controls https://shipreadyai.dev/learn/verify/ai-features # AI feature controls Whether prompts, spend, and model output are bounded so one visitor cannot run up the bill. ## Why a check from outside cannot see it Prompt handling, spend limits and output checks happen inside a server call. From outside, a model that costs a tenth of a cent and one that costs a dollar look identical. ## How to check it yourself 1. Send your longest plausible input to the AI feature twenty times in a row. 2. Watch the provider spend for that hour, then multiply by a bored stranger. 3. Paste an instruction inside the content itself and see whether the model follows it. ## What a Launch Review does instead A reviewer sends long and hostile inputs, watches spend for the hour, and reads how model output is used. ## Database row rules https://shipreadyai.dev/learn/verify/backend-rules # Database row rules Whether the row rules behind the app actually stop one signed in account reading another's rows. ## Why a check from outside cannot see it A check can see that a table answers the public key. Whether the rule on it is the right rule requires reading the policy, and policies are not published. ## How to check it yourself 1. Sign in as one account and note the id of a record it owns. 2. Sign in as a second account and request the first account's record by id through the API. 3. Repeat for every table that holds customer data, not just the one on the page you remembered. ## What a Launch Review does instead A reviewer reads the policies, then asks for another account's record by id and confirms the database refuses. ## Certificate expiry date https://shipreadyai.dev/learn/verify/certificate-expiry # Certificate expiry date Whether the certificate is close to expiring. A normal request proves the certificate is valid right now, and the runtime this check uses cannot read the expiry date from that request. ## Why a check from outside cannot see it A request proves the certificate is valid at the moment it is made. The date it stops being valid is inside the certificate itself, and the runtime this check runs on hands back the answer without handing back the certificate. ## How to check it yourself 1. Run openssl s_client -connect yourdomain.com:443 -servername yourdomain.com and read the notAfter date. 2. Or open the padlock in your browser and read the same date there. 3. Put a reminder in your calendar three weeks before it, even when renewal is automatic. ## What a Launch Review does instead A reviewer reads the certificate directly, notes the expiry date, and checks that renewal is automatic and monitored. ## One account reading another account's data https://shipreadyai.dev/learn/verify/cross-user-access # One account reading another account's data Whether a signed in account can reach another account's records by changing an id. ShipReady does not create accounts, sign in, or call your functions, so this cannot be answered from outside. ## Why a check from outside cannot see it Answering this means creating two accounts on your app and using one to reach the other's data. That is an action on your product taken by a stranger, and no automated check on a public address should be doing it. ## How to check it yourself 1. Create two accounts and sign in to each in a different browser. 2. Copy a record address from the first account and open it in the second. 3. Repeat through the API rather than the interface, because the interface often hides what the API allows. ## What a Launch Review does instead A reviewer signs in with two accounts, tries to reach one account's records from the other, and records exactly what answered. ## Launch failure library https://shipreadyai.dev/incidents # Launch failure library 16 documented incidents in apps built with AI tools. Each page states only what its sources say. - [First-quarter 2026 assessment of 200 apps](https://shipreadyai.dev/incidents/first-quarter-2026-assessment.md): 2026-04. 183 of 200 vibe-coded apps, 91.5 percent, contained at least one vulnerability traceable to AI hallucination or missing security context. - [CVE growth in AI-generated code](https://shipreadyai.dev/incidents/cve-growth-2026.md): 2026-03. CVE entries attributed to AI-generated code rose from 6 in January 2026 to more than 35 in March 2026. - [Mercor supply-chain breach](https://shipreadyai.dev/incidents/mercor-supply-chain-breach.md): 2026-03. A 10 billion dollar AI startup was breached through the LiteLLM supply-chain attack, with 4 TB claimed stolen. - [OpenClaw CVE-2026-31992](https://shipreadyai.dev/incidents/openclaw-cve-2026-31992.md): 2026-03. An allowlist bypass scored 9.9 on CVSS and was described as a full guardrail bypass. - [Claude Code data destruction](https://shipreadyai.dev/incidents/claude-code-data-destruction.md): 2026-02. An agent destroyed 2.5 years of production data. - [5,600 vibe-coded apps scanned](https://shipreadyai.dev/incidents/five-thousand-six-hundred-apps-scanned.md): 2026-02. More than 2,000 vulnerabilities and more than 400 exposed secrets found across vibe-coded apps. - [Slopsquatting campaign on npm](https://shipreadyai.dev/incidents/slopsquatting-npm-campaign.md): 2026-02. 126 malicious npm packages exploited AI-hallucinated package names. - [Tenzai study of AI-built apps](https://shipreadyai.dev/incidents/tenzai-study.md): 2026-02. 69 vulnerabilities across 15 apps built by five AI coding tools. - [Gemini CLI project loss](https://shipreadyai.dev/incidents/gemini-cli-project-loss.md): 2026-01. An agent destroyed an entire project by looping a move command to a directory that did not exist. - [Moltbook records exposure](https://shipreadyai.dev/incidents/moltbook-records-exposure.md): 2026-01. An app exposed 4.75 million records, including 1.5 million API tokens and 35,000 email addresses. - [Amazon internal agent outage](https://shipreadyai.dev/incidents/amazon-internal-agent-outage.md): 2025-12. An AI agent deleted and recreated an environment, causing a 13-hour outage. - [Replit agent database deletion](https://shipreadyai.dev/incidents/replit-agent-database-deletion.md): 2025-07. An AI agent wiped production databases while explicitly instructed not to. - [Tea app, first breach](https://shipreadyai.dev/incidents/tea-app-first-breach.md): 2025-07. An unprotected storage instance exposed tens of thousands of user images, including identity documents. - [Tea app, second breach](https://shipreadyai.dev/incidents/tea-app-second-breach.md): 2025-07. Three days after the first breach, over a million private messages were exposed through an API endpoint with no access control. - [Lovable-built apps, CVE-2025-48757](https://shipreadyai.dev/incidents/lovable-cve-2025-48757.md): 2025-05. Broken access control reported across 170 production applications built with Lovable. - [Base44 authentication flaw](https://shipreadyai.dev/incidents/base44-auth-flaw.md): 2025-01. A platform-wide authentication flaw allowed access to private enterprise data. ## First-quarter 2026 assessment of 200 apps https://shipreadyai.dev/incidents/first-quarter-2026-assessment # First-quarter 2026 assessment of 200 apps 2026-04. Mixed. ## What happened The sources report 183 of 200 apps containing at least one vulnerability. That is 91.5 percent. The vulnerabilities are traced to AI hallucination or missing security context. ## What ShipReady can say Most of what this study counts sits behind the app. That is the not-verified list, named item by item rather than left out. ## Sources - [secure.com vibe coding security risks](https://www.secure.com/blog/appsec/vibe-coding-security-risks) ## CVE growth in AI-generated code https://shipreadyai.dev/incidents/cve-growth-2026 # CVE growth in AI-generated code 2026-03. Mixed. ## What happened The sources report 6 CVE entries attributed to AI-generated code in January 2026. By March 2026 the count was more than 35. ## What ShipReady can say This is background, not a finding. It sets the context for the report rather than mapping to one check. ## Sources - [crackr.dev vibe coding failures](https://crackr.dev/vibe-coding-failures) - [daily.dev summary of the crackr.dev directory](https://app.daily.dev/posts/vibe-coding-failures-documented-ai-code-incidents-wjx2mwbpj) ## Mercor supply-chain breach https://shipreadyai.dev/incidents/mercor-supply-chain-breach # Mercor supply-chain breach 2026-03. LiteLLM. ## What happened The sources report a breach of a 10 billion dollar AI startup. The route in was the LiteLLM supply-chain attack. The claim is 4 TB stolen. ## What ShipReady can say Where a dependency came from is not visible from a public URL. Provenance belongs in the Release Gate checklist. ## Sources - [NotElon report](https://notelon.ai/report) ## OpenClaw CVE-2026-31992 https://shipreadyai.dev/incidents/openclaw-cve-2026-31992 # OpenClaw CVE-2026-31992 2026-03. OpenClaw. ## What happened The sources report an allowlist bypass with a CVSS score of 9.9. It is described as a full guardrail bypass. ## What ShipReady can say Cost caps and output validation sit inside AI features. They stay Not verified until the code is read. ## Sources - [crackr.dev vibe coding failures](https://crackr.dev/vibe-coding-failures) ## Claude Code data destruction https://shipreadyai.dev/incidents/claude-code-data-destruction # Claude Code data destruction 2026-02. Claude Code. ## What happened The sources report an agent destroying 2.5 years of production data. ## What ShipReady can say A backup nobody has restored is a guess. Rollback, recovery and tested backups stay Not verified from outside. ## Sources - [daily.dev summary of the crackr.dev directory](https://app.daily.dev/posts/vibe-coding-failures-documented-ai-code-incidents-wjx2mwbpj) - [crackr.dev vibe coding failures](https://crackr.dev/vibe-coding-failures) ## 5,600 vibe-coded apps scanned https://shipreadyai.dev/incidents/five-thousand-six-hundred-apps-scanned # 5,600 vibe-coded apps scanned 2026-02. Mixed. ## What happened The sources report more than 2,000 vulnerabilities across 5,600 scanned apps. They also report more than 400 exposed secrets. ## What ShipReady can say Server keys left in client JavaScript are exactly what the free check reads. That is finding O4, with the evidence line and the date attached. ## Sources - [crackr.dev vibe coding failures](https://crackr.dev/vibe-coding-failures) - [NotElon report](https://notelon.ai/report) ## Slopsquatting campaign on npm https://shipreadyai.dev/incidents/slopsquatting-npm-campaign # Slopsquatting campaign on npm 2026-02. npm. ## What happened The sources report 126 malicious npm packages exploiting AI-hallucinated package names. A USENIX study of 2.23 million samples found 19.7 percent referenced a package that did not exist. ## What ShipReady can say A URL check reads a published app, not its dependency tree. Dependency scanning belongs to the platform and to the Release Gate checklist. ## Sources - [daily.dev summary of the crackr.dev directory](https://app.daily.dev/posts/vibe-coding-failures-documented-ai-code-incidents-wjx2mwbpj) - [CatDoes vibe coding security checklist](https://catdoes.com/blog/vibe-coding-security-checklist) - [Arnica vibe coding security risks](https://www.arnica.io/blog/vibe-coding-security-risks) ## Tenzai study of AI-built apps https://shipreadyai.dev/incidents/tenzai-study # Tenzai study of AI-built apps 2026-02. Five AI coding tools. ## What happened The sources report 69 vulnerabilities across 15 apps. The apps were built by five AI coding tools. Every app lacked CSRF protection. Every tool introduced SSRF. ## What ShipReady can say Cross-site request forgery and server-side request forgery live in request handling. They stay Not verified until a review reads the code. ## Sources - [crackr.dev vibe coding failures](https://crackr.dev/vibe-coding-failures) ## Gemini CLI project loss https://shipreadyai.dev/incidents/gemini-cli-project-loss # Gemini CLI project loss 2026-01. Gemini CLI. ## What happened The sources report an agent destroying an entire project. It looped a move command pointed at a directory that did not exist. ## What ShipReady can say Guardrails that stop an agent from touching production are part of the Release Gate. No external check can see them. ## Sources - [crackr.dev vibe coding failures](https://crackr.dev/vibe-coding-failures) ## Moltbook records exposure https://shipreadyai.dev/incidents/moltbook-records-exposure # Moltbook records exposure 2026-01. Unnamed. ## What happened The sources report 4.75 million exposed records. They included 1.5 million API tokens and 35,000 email addresses. The causes reported are missing database access controls and an open admin route. The founder said he did not write a single line of code. ## What ShipReady can say An open admin route shows up as O6 and tables that answer the browser key show up as O8. Whether each row rule is right is still Not verified. ## Sources - [Cloud Security Alliance research note](https://labs.cloudsecurityalliance.org/wp-content/uploads/2026/04/CSA_research_note_ai_codegen_vulnerability_debt_20260406-csa-styled.pdf) - [getautonoma vibe coding failures](https://getautonoma.com/blog/vibe-coding-failures) - [Arnica vibe coding security risks](https://www.arnica.io/blog/vibe-coding-security-risks) ## Amazon internal agent outage https://shipreadyai.dev/incidents/amazon-internal-agent-outage # Amazon internal agent outage 2025-12. Internal agent. ## What happened The sources report an AI agent deleting and recreating an environment. The result was a 13-hour outage. ## What ShipReady can say Recovery time is measured from inside. It stays Not verified until someone rolls a change back and times it. ## Sources - [crackr.dev vibe coding failures](https://crackr.dev/vibe-coding-failures) ## Replit agent database deletion https://shipreadyai.dev/incidents/replit-agent-database-deletion # Replit agent database deletion 2025-07. Replit. ## What happened The sources report an AI agent wiping production databases. The agent had been explicitly instructed not to. ## What ShipReady can say Nothing outside an app shows whether the last version can be put back. Rollback and recovery stay Not verified, and the Release Gate carries the rollback requirements. ## Sources - [getautonoma vibe coding failures](https://getautonoma.com/blog/vibe-coding-failures) ## Tea app, first breach https://shipreadyai.dev/incidents/tea-app-first-breach # Tea app, first breach 2025-07. Firebase. ## What happened The sources report an unprotected Firebase storage instance. Tens of thousands of user images were exposed. The exposed files included government-issued identity documents. ## What ShipReady can say A check from outside reads what a visitor can reach. Storage rules sit behind the app, so this one stays Not verified until a Launch Review looks at the bucket policies. ## Sources - [Cloud Security Alliance research note](https://labs.cloudsecurityalliance.org/wp-content/uploads/2026/04/CSA_research_note_ai_codegen_vulnerability_debt_20260406-csa-styled.pdf) - [CatDoes vibe coding security checklist](https://catdoes.com/blog/vibe-coding-security-checklist) ## Tea app, second breach https://shipreadyai.dev/incidents/tea-app-second-breach # Tea app, second breach 2025-07. Firebase. ## What happened The sources report a second exposure three days after the first. Over a million private messages were exposed. The endpoint that served them performed no access control. ## What ShipReady can say An endpoint that answers without checking who is asking is only visible from inside the app. This stays Not verified until auth flows and tenant isolation are reviewed. ## Sources - [Cloud Security Alliance research note](https://labs.cloudsecurityalliance.org/wp-content/uploads/2026/04/CSA_research_note_ai_codegen_vulnerability_debt_20260406-csa-styled.pdf) - [CatDoes vibe coding security checklist](https://catdoes.com/blog/vibe-coding-security-checklist) ## Lovable-built apps, CVE-2025-48757 https://shipreadyai.dev/incidents/lovable-cve-2025-48757 # Lovable-built apps, CVE-2025-48757 2025-05. Lovable. ## What happened The sources report broken access control across 170 production applications. Every one of them was built with Lovable. The issue carries the identifier CVE-2025-48757. ## What ShipReady can say When tables answer the browser key from outside, the free check observes it as O8. Whether each row rule is correct is not something a URL can read, so the rest stays Not verified. ## Sources - [Cloud Security Alliance research note](https://labs.cloudsecurityalliance.org/wp-content/uploads/2026/04/CSA_research_note_ai_codegen_vulnerability_debt_20260406-csa-styled.pdf) - [getautonoma vibe coding failures](https://getautonoma.com/blog/vibe-coding-failures) ## Base44 authentication flaw https://shipreadyai.dev/incidents/base44-auth-flaw # Base44 authentication flaw 2025-01. Base44. ## What happened The sources report a platform-wide authentication flaw. It allowed access to private enterprise data. ## What ShipReady can say Sign in behaviour is inside the app. A check from outside cannot exercise it, so auth flows stay Not verified until a Launch Review tests them. ## Sources - [getautonoma vibe coding failures](https://getautonoma.com/blog/vibe-coding-failures) ## Builders https://shipreadyai.dev/builders # Builders What each AI builder handles for you, and what it leaves to you. - [Base44](https://shipreadyai.dev/builders/base44.md): Base44 builds and hosts the whole app. When the platform has a flaw, every app on it inherits it. - [Bolt](https://shipreadyai.dev/builders/bolt.md): Bolt gets an app running fast. Speed is the point. Review is still yours. - [Claude Code](https://shipreadyai.dev/builders/claude-code.md): Claude Code works in the terminal with real reach. Guardrails matter more here, not less. - [Codex](https://shipreadyai.dev/builders/codex.md): Codex takes a task and reports what it touched. Keep the task small and the report honest. - [Cursor](https://shipreadyai.dev/builders/cursor.md): Cursor edits your repository. Nothing ships until you ship it, and that is the difference. - [Firebase Studio](https://shipreadyai.dev/builders/firebase-studio.md): Firebase gives you storage and data in one step. The rules are the whole game. - [Lovable](https://shipreadyai.dev/builders/lovable.md): Lovable ships a hosted app with a backend behind it. It handles transport and hosting. It does not decide who may read a row. - [Replit](https://shipreadyai.dev/builders/replit.md): Replit runs the whole workspace, including the agent. That is the power and the risk. - [v0](https://shipreadyai.dev/builders/v0.md): v0 writes the interface. The server boundary is the part to watch. - [Windsurf](https://shipreadyai.dev/builders/windsurf.md): Windsurf keeps the agent close to your editor. The review habit is still the product. ## Base44 https://shipreadyai.dev/builders/base44 # Base44 Base44 builds and hosts the whole app. When the platform has a flaw, every app on it inherits it. ## What the builder handles for you Hosting, data and authentication in one place. A public app without a deployment step. ## What it does not It does not make platform-level authentication your problem to see. You cannot inspect it from outside. It does not write your access rules for you. It does not prove recovery works. ## Incidents involving it In 2025 a platform-wide authentication flaw allowed access to private enterprise data. ## The fix prompt dialect Base44 takes the generic prompt. Where the platform owns the setting, the prompt says so and points at the platform console instead of the code. ## Stack checklists that apply Lovable Cloud, Supabase, Stripe. ## Bolt https://shipreadyai.dev/builders/bolt # Bolt Bolt gets an app running fast. Speed is the point. Review is still yours. ## What the builder handles for you A working project from a prompt. A deployment target and a public URL. Environment values in the project settings. ## What it does not It does not separate a preview environment from a production one for you. It does not set response headers unless you ask. It does not read your access rules. It does not know which keys are safe in a browser. ## Incidents involving it The Tenzai study covered five AI coding tools and found every one of them introduced server-side request forgery. A scan of 5,600 vibe-coded apps found more than 2,000 vulnerabilities. ## The fix prompt dialect Bolt takes the generic prompt. It names the one place to change, asks for a diff, and asks for the header line or the route back. ## Stack checklists that apply Bolt, Vite, Supabase, Stripe. ## Claude Code https://shipreadyai.dev/builders/claude-code # Claude Code Claude Code works in the terminal with real reach. Guardrails matter more here, not less. ## What the builder handles for you Multi-step work across a repository. Build and test runs it can start itself. Instructions it reads from AGENTS.md. ## What it does not It does not stop itself at the edge of production unless you draw the line. It does not verify a backup is restorable. It does not own hosting or response headers. ## Incidents involving it A reported case in 2026 describes an agent destroying 2.5 years of production data. ## The fix prompt dialect Claude Code tasks say make the change, run the build, and summarise the diff. Verification is part of the prompt, not an afterthought. ## Stack checklists that apply Claude Code, Next.js, Supabase, Vercel. ## Codex https://shipreadyai.dev/builders/codex # Codex Codex takes a task and reports what it touched. Keep the task small and the report honest. ## What the builder handles for you A scoped edit with a list of files touched. Repeatable tasks you can queue. ## What it does not It does not host anything. It does not read your deployment settings. It does not know which row rules your product needs. ## Incidents involving it CVE entries attributed to AI-generated code rose from 6 in January 2026 to more than 35 in March 2026. The Tenzai study found every tool it tested introduced server-side request forgery. ## The fix prompt dialect Codex tasks say apply the edit and report the files touched, then verify with a command and paste the output. ## Stack checklists that apply Cursor, Next.js, Custom Python backend, Vercel. ## Cursor https://shipreadyai.dev/builders/cursor # Cursor Cursor edits your repository. Nothing ships until you ship it, and that is the difference. ## What the builder handles for you Edits across many files at once. Repository rules it will follow if you write them. A diff you can read before you accept it. ## What it does not It does not deploy, so hosting, headers and certificates are yours. It does not check that an imported package exists. It does not know your production data from your test data. ## Incidents involving it The Tenzai study of five AI coding tools found 69 vulnerabilities across 15 apps. A slopsquatting campaign put 126 malicious npm packages behind names AI tools invent. ## The fix prompt dialect Cursor prompts say apply it across the project and show me a diff. They keep the change in one place and end with a verification step. ## Stack checklists that apply Cursor, Next.js, Supabase, Vercel. ## Firebase Studio https://shipreadyai.dev/builders/firebase-studio # Firebase Studio Firebase gives you storage and data in one step. The rules are the whole game. ## What the builder handles for you Hosting, storage, data and authentication. Client SDKs wired up for you. A public URL with HTTPS. ## What it does not It does not write your storage rules. The default is not your policy. It does not stop an endpoint answering without a check. It does not tell you which files are public. ## Incidents involving it In July 2025 an unprotected Firebase storage instance exposed tens of thousands of user images, including identity documents. Three days later over a million private messages were exposed through an endpoint with no access control. ## The fix prompt dialect Firebase prompts name the rules file, the exact rule to change, and ask for the deployed rules back so the change can be seen. ## Stack checklists that apply Firebase, Next.js, Stripe. ## Lovable https://shipreadyai.dev/builders/lovable # Lovable Lovable ships a hosted app with a backend behind it. It handles transport and hosting. It does not decide who may read a row. ## What the builder handles for you Hosting, HTTPS and the certificate. A deployed build on every publish. A managed backend with authentication and storage when you enable Cloud. Environment values kept out of the repository. ## What it does not It does not decide which rows an account may read. You write those rules. It does not stop a server key being pasted into a client file. It does not test your sign in flow, your rollback, or your refund path. It does not check the dependency your agent invented. ## Incidents involving it CVE-2025-48757 reported broken access control across 170 production applications built with Lovable. A scan of 5,600 vibe-coded apps found more than 400 exposed secrets. ## The fix prompt dialect Fix prompts for Lovable are written for Lovable chat. They name the file to change, tell the agent to change nothing else, and end by asking for the value that was set so the check can be run again. ## Stack checklists that apply Lovable, Lovable Cloud, Supabase, Stripe. ## Replit https://shipreadyai.dev/builders/replit # Replit Replit runs the whole workspace, including the agent. That is the power and the risk. ## What the builder handles for you A running process on a public address. Workspace secrets kept out of the code. A deployment with HTTPS. ## What it does not It does not keep an agent away from production data. It does not test that you can put the last version back. It does not review your access rules. ## Incidents involving it In July 2025 an AI agent wiped production databases while explicitly instructed not to. ## The fix prompt dialect Replit takes the generic prompt with one addition: the agent works in the workspace, so the prompt names the file, forbids touching data, and asks for the diff. ## Stack checklists that apply Replit, Custom Node backend, Supabase, Stripe. ## v0 https://shipreadyai.dev/builders/v0 # v0 v0 writes the interface. The server boundary is the part to watch. ## What the builder handles for you Components and pages that look finished. A deploy to a hosting platform with HTTPS. Framework defaults for routing and rendering. ## What it does not It does not decide what belongs on the server and what belongs in the browser. It does not stop a secret crossing that line. It does not write your row rules. It does not test payments. ## Incidents involving it The Tenzai study found missing cross-site request forgery protection in every app it built with AI tools. A scan of 5,600 vibe-coded apps found more than 400 exposed secrets. ## The fix prompt dialect v0 takes the generic prompt, framed for a Next.js project: name the server boundary, move the value behind it, show the diff. ## Stack checklists that apply v0, Next.js, Stripe. ## Windsurf https://shipreadyai.dev/builders/windsurf # Windsurf Windsurf keeps the agent close to your editor. The review habit is still the product. ## What the builder handles for you Agent edits inside your project. Context from the open files. ## What it does not It does not deploy or set headers. It does not check a package name before importing it. It does not test sign in or payments. ## Incidents involving it The Tenzai study covered five AI coding tools and found 69 vulnerabilities across 15 apps. 126 malicious npm packages exploited names AI tools hallucinate. ## The fix prompt dialect Windsurf uses the generic prompt: one instruction, one place to change, one way to verify. ## Stack checklists that apply Cursor, Next.js, Supabase, Vercel. ## Compare https://shipreadyai.dev/compare # Compare Honest comparisons with ten other ways to check an AI-built app. - [ShipReady vs Aikido](https://shipreadyai.dev/compare/aikido.md): A code, cloud and runtime platform for engineering teams that connects to private development systems. - [ShipReady vs CheckVibe](https://shipreadyai.dev/compare/checkvibe.md): A broad scanner with open basic findings and account features for saved and exported reports. - [ShipReady vs LaunchGuard](https://shipreadyai.dev/compare/launchguard.md): A scanner that probes database functions and cross-account access from outside the app. - [ShipReady vs Lovable's built-in scan](https://shipreadyai.dev/compare/lovable-security-scan.md): A project-aware scan inside the Lovable editor that can read internal configuration ShipReady cannot see from outside. - [ShipReady vs Reeve](https://shipreadyai.dev/compare/reeve.md): A research-led scanner that has published a large-scale sweep of AI-built apps. - [ShipReady vs Safe Vibe Codes](https://shipreadyai.dev/compare/safe-vibe-codes.md): A community-facing site with guidance and checks aimed at people shipping AI-built apps. - [ShipReady vs SiteSecurityScore](https://shipreadyai.dev/compare/site-security-score.md): A site-security grader that gives a URL a single score based on outside signals. - [ShipReady vs Vibe App Scanner](https://shipreadyai.dev/compare/vibe-app-scanner.md): A scanner for AI-built apps with broad automated coverage and paid access to the full report. - [ShipReady vs VibeEval](https://shipreadyai.dev/compare/vibeeval.md): A live-URL black-box scanner whose findings are reviewed by an engineer before delivery. - [ShipReady vs VibeShip Scanner](https://shipreadyai.dev/compare/vibeship-scanner.md): A free open-source scanner that checks public repositories and returns AI-oriented fix guidance. ## ShipReady vs Aikido https://shipreadyai.dev/compare/aikido # ShipReady vs Aikido A code, cloud and runtime platform for engineering teams that connects to private development systems. # ShipReady vs Aikido A code, cloud and runtime platform for engineering teams that connects to private development systems. Facts about Aikido were read from their site on the dates shown. Tell us if something changed. ## Score or evidence - **Them.** Findings are listed with severity across code, dependencies, cloud and runtime, rather than a single score. Source: https://www.aikido.dev/ (read 2026-09-14). - **Us.** No score, no grade, no badge. Every finding shows the request that produced it and the date it was read. ## What they show and what they keep - **Them.** Requires an account and connections to repositories, cloud accounts or container systems before findings appear. Source: https://www.aikido.dev/pricing (read 2026-09-14). - **Us.** The full free result is shown to anyone with the check id. Nothing is gated behind a paywall or an account. ## What they do to your app - **Them.** Reads private code and cloud configuration after you connect it. Public pages describe a dynamic testing add-on rather than default live probing. Source: https://www.aikido.dev/pricing?product=pentest (read 2026-09-14). - **Us.** Deterministic outside requests only. Never signs in, never executes a function on your database, never reads another account's data. ## What neither can see from outside - **Rollback and recovery.** Whether you can put the previous version back, and how long that takes. - **Error monitoring.** Whether a failure in production reaches a human rather than sitting in a log nobody opens. - **Sign in and account flows.** Whether sign in, password or code reset, and session expiry behave under real use. - **Rate limiting and abuse controls.** Whether a script can hammer your forms, sign up loop, or paid endpoints without being slowed down. - **Key rotation.** Whether you can replace a leaked key quickly and know everywhere it is used. - **Certificate expiry date.** Whether the certificate is close to expiring. A normal request proves the certificate is valid right now, and the runtime this check uses cannot read the expiry date from that request. - **One account reading another account's data.** Whether a signed in account can reach another account's records by changing an id. ShipReady does not create accounts, sign in, or call your functions, so this cannot be answered from outside. - **Payment handling.** Whether payment events are verified, replay safe, and matched to the right customer record. - **Customer data handling.** Whether stored personal details are limited, deletable on request, and out of your logs. - **AI feature controls.** Whether prompts, spend, and model output are bounded so one visitor cannot run up the bill. - **Database row rules.** Whether the row rules behind the app actually stop one signed in account reading another's rows. ## Fixes - **Them.** Findings link into engineering workflows and issue trackers. Public pages do not list per-builder fix prompts. Source: https://www.aikido.dev/ (read 2026-09-14). - **Us.** Every finding carries five fix prompts for Lovable, Bolt, Base44, v0 and generic coding assistants, hand written per finding. ## Beyond security - Legal page links: them no, us yes - Email authentication: them no, us yes - Domain expiry: them no, us yes - Cookie flags: them no, us yes - Platform trust evidence: them no, us yes Source: https://www.aikido.dev/ ## What happens next - **Them.** Findings are triaged inside the platform and assigned to engineers who work with the connected repositories. Source: https://www.aikido.dev/ (read 2026-09-14). - **Us.** You can stop at the free check, or buy the Release Gate at $49 for the package, the Launch Review at $199 for a person, or the Hardening Sprint at $1,750 for the fix work. ## Competitor strengths Brings code, dependency, container, cloud and runtime findings into one engineering platform for a team that can connect its development systems. ## Choose them if You have a repository, cloud account, and team that can triage findings in an engineering platform, and you want one place that spans code, dependencies, cloud and runtime. ## Sources - https://www.aikido.dev/ - https://www.aikido.dev/pricing - https://www.aikido.dev/pricing?product=pentest ## ShipReady vs CheckVibe https://shipreadyai.dev/compare/checkvibe # ShipReady vs CheckVibe A broad scanner with open basic findings and account features for saved and exported reports. # ShipReady vs CheckVibe A broad scanner with open basic findings and account features for saved and exported reports. Facts about CheckVibe were read from their site on the dates shown. Tell us if something changed. ## Score or evidence - **Them.** The public pages describe more than one hundred checks and result exports rather than a single score or grade. Source: https://checkvibe.dev/free-website-security-scanner (read 2026-09-14). - **Us.** No score, no grade, no badge. Every finding shows the request that produced it and the date it was read. ## What they show and what they keep - **Them.** Basic findings appear without an account. Saved dashboards, PDFs and shared reports use an account. Source: https://checkvibe.dev/products/reports (read 2026-09-14). - **Us.** The full free result is shown to anyone with the check id. Nothing is gated behind a paywall or an account. ## What they do to your app - **Them.** Public URL scan. Public pages do not describe executing database functions, signing in as your users, or reading another account's records. Source: https://checkvibe.dev/free-website-security-scanner (read 2026-09-14). - **Us.** Deterministic outside requests only. Never signs in, never executes a function on your database, never reads another account's data. ## What neither can see from outside - **Rollback and recovery.** Whether you can put the previous version back, and how long that takes. - **Error monitoring.** Whether a failure in production reaches a human rather than sitting in a log nobody opens. - **Sign in and account flows.** Whether sign in, password or code reset, and session expiry behave under real use. - **Rate limiting and abuse controls.** Whether a script can hammer your forms, sign up loop, or paid endpoints without being slowed down. - **Key rotation.** Whether you can replace a leaked key quickly and know everywhere it is used. - **Certificate expiry date.** Whether the certificate is close to expiring. A normal request proves the certificate is valid right now, and the runtime this check uses cannot read the expiry date from that request. - **One account reading another account's data.** Whether a signed in account can reach another account's records by changing an id. ShipReady does not create accounts, sign in, or call your functions, so this cannot be answered from outside. - **Payment handling.** Whether payment events are verified, replay safe, and matched to the right customer record. - **Customer data handling.** Whether stored personal details are limited, deletable on request, and out of your logs. - **AI feature controls.** Whether prompts, spend, and model output are bounded so one visitor cannot run up the bill. - **Database row rules.** Whether the row rules behind the app actually stop one signed in account reading another's rows. ## Fixes - **Them.** Prompts written for coding assistants sit alongside the findings. Public pages do not list per-builder templates. Source: https://checkvibe.dev/products/ai-fixes (read 2026-09-14). - **Us.** Every finding carries five fix prompts for Lovable, Bolt, Base44, v0 and generic coding assistants, hand written per finding. ## Beyond security - Legal page links: them no, us yes - Email authentication: them no, us yes - Domain expiry: them no, us yes - Cookie flags: them no, us yes - Platform trust evidence: them no, us yes Source: https://checkvibe.dev/free-website-security-scanner ## What happens next - **Them.** Save a report, export a PDF, or share it with a technical contact from the account dashboard. Source: https://checkvibe.dev/products/reports (read 2026-09-14). - **Us.** You can stop at the free check, or buy the Release Gate at $49 for the package, the Launch Review at $199 for a person, or the Hardening Sprint at $1,750 for the fix work. ## Competitor strengths Broad automated scan combined with AI fix prompts and shareable PDF and dashboard exports designed for technical stakeholders. ## Choose them if You want an open browser scan you can hand to a developer, a report they can save and export, and prompts written to paste back into a coding assistant. ## Sources - https://checkvibe.dev/ - https://checkvibe.dev/free-website-security-scanner - https://checkvibe.dev/products/reports - https://checkvibe.dev/products/ai-fixes ## ShipReady vs LaunchGuard https://shipreadyai.dev/compare/launchguard # ShipReady vs LaunchGuard A scanner that probes database functions and cross-account access from outside the app. # ShipReady vs LaunchGuard A scanner that probes database functions and cross-account access from outside the app. Facts about LaunchGuard were read from their site on the dates shown. Tell us if something changed. ## Score or evidence - **Them.** The pages describe findings tied to specific probes rather than a single score. Source: https://launchguard.dev/ (read 2026-09-14). - **Us.** No score, no grade, no badge. Every finding shows the request that produced it and the date it was read. ## What they show and what they keep - **Them.** Public pages describe a scan against a supplied URL. Report handling is not stated in detail. Source: https://launchguard.dev/ (read 2026-09-14). - **Us.** The full free result is shown to anyone with the check id. Nothing is gated behind a paywall or an account. ## What they do to your app - **Them.** Explicitly probes database functions and IDOR-style cross-account requests from outside, so it can trigger writes and read attempts against your app. Source: https://launchguard.dev/ (read 2026-09-14). - **Us.** Deterministic outside requests only. Never signs in, never executes a function on your database, never reads another account's data. ## What neither can see from outside - **Rollback and recovery.** Whether you can put the previous version back, and how long that takes. - **Error monitoring.** Whether a failure in production reaches a human rather than sitting in a log nobody opens. - **Sign in and account flows.** Whether sign in, password or code reset, and session expiry behave under real use. - **Rate limiting and abuse controls.** Whether a script can hammer your forms, sign up loop, or paid endpoints without being slowed down. - **Key rotation.** Whether you can replace a leaked key quickly and know everywhere it is used. - **Certificate expiry date.** Whether the certificate is close to expiring. A normal request proves the certificate is valid right now, and the runtime this check uses cannot read the expiry date from that request. - **One account reading another account's data.** Whether a signed in account can reach another account's records by changing an id. ShipReady does not create accounts, sign in, or call your functions, so this cannot be answered from outside. - **Payment handling.** Whether payment events are verified, replay safe, and matched to the right customer record. - **Customer data handling.** Whether stored personal details are limited, deletable on request, and out of your logs. - **AI feature controls.** Whether prompts, spend, and model output are bounded so one visitor cannot run up the bill. - **Database row rules.** Whether the row rules behind the app actually stop one signed in account reading another's rows. ## Fixes - **Them.** Findings describe the probe and its response. Public pages do not list per-builder fix prompts. Source: https://launchguard.dev/ (read 2026-09-14). - **Us.** Every finding carries five fix prompts for Lovable, Bolt, Base44, v0 and generic coding assistants, hand written per finding. ## Beyond security - Legal page links: them no, us yes - Email authentication: them no, us yes - Domain expiry: them no, us yes - Cookie flags: them no, us yes - Platform trust evidence: them no, us yes Source: https://launchguard.dev/ ## What happens next - **Them.** Read the report, then decide whether to remediate on your own. Source: https://launchguard.dev/ (read 2026-09-14). - **Us.** You can stop at the free check, or buy the Release Gate at $49 for the package, the Launch Review at $199 for a person, or the Hardening Sprint at $1,750 for the fix work. ## Competitor strengths Actively probes database functions and cross-account paths from outside, which surfaces a class of failure a passive outside scan cannot. ## Choose them if You want an automated probe of your database functions and cross-account paths from outside, and you accept the trade-off that automated probing sends requests to your app that you would rather a person controlled. ## Why our free check does not probe functions or accounts ShipReady's free check never executes a function on your database and never signs in as one of your users to read another's data. Automated probes can trigger writes, corrupt state, or count toward rate limits on production accounts, and the person on the other end has not agreed to that. In the Launch Review a person does this work under explicit scope, with your approval, against a real test account, and writes up what they saw, which is why probing that shape lives there instead of in the free check. ## Sources - https://launchguard.dev/ ## ShipReady vs Lovable's built-in scan https://shipreadyai.dev/compare/lovable-security-scan # ShipReady vs Lovable's built-in scan A project-aware scan inside the Lovable editor that can read internal configuration ShipReady cannot see from outside. # ShipReady vs Lovable's built-in scan A project-aware scan inside the Lovable editor that can read internal configuration ShipReady cannot see from outside. Facts about Lovable's built-in scan were read from their site on the dates shown. Tell us if something changed. ## Score or evidence - **Them.** Findings appear as an in-editor list tied to the project rather than a public score. Source: https://docs.lovable.dev/features/security (read 2026-09-14). - **Us.** No score, no grade, no badge. Every finding shows the request that produced it and the date it was read. ## What they show and what they keep - **Them.** Findings are shown inside the Lovable editor to project members. There is no shareable public result. Source: https://docs.lovable.dev/features/security (read 2026-09-14). - **Us.** The full free result is shown to anyone with the check id. Nothing is gated behind a paywall or an account. ## What they do to your app - **Them.** Reads project configuration and generated database rules directly. It does not sign in as your end users. Source: https://docs.lovable.dev/features/security (read 2026-09-14). - **Us.** Deterministic outside requests only. Never signs in, never executes a function on your database, never reads another account's data. ## What neither can see from outside - **Rollback and recovery.** Whether you can put the previous version back, and how long that takes. - **Error monitoring.** Whether a failure in production reaches a human rather than sitting in a log nobody opens. - **Sign in and account flows.** Whether sign in, password or code reset, and session expiry behave under real use. - **Rate limiting and abuse controls.** Whether a script can hammer your forms, sign up loop, or paid endpoints without being slowed down. - **Key rotation.** Whether you can replace a leaked key quickly and know everywhere it is used. - **Certificate expiry date.** Whether the certificate is close to expiring. A normal request proves the certificate is valid right now, and the runtime this check uses cannot read the expiry date from that request. - **One account reading another account's data.** Whether a signed in account can reach another account's records by changing an id. ShipReady does not create accounts, sign in, or call your functions, so this cannot be answered from outside. - **Payment handling.** Whether payment events are verified, replay safe, and matched to the right customer record. - **Customer data handling.** Whether stored personal details are limited, deletable on request, and out of your logs. - **AI feature controls.** Whether prompts, spend, and model output are bounded so one visitor cannot run up the bill. - **Database row rules.** Whether the row rules behind the app actually stop one signed in account reading another's rows. ## Fixes - **Them.** The editor can propose fixes into the project itself. It is scoped to Lovable projects. Source: https://docs.lovable.dev/features/security (read 2026-09-14). - **Us.** Every finding carries five fix prompts for Lovable, Bolt, Base44, v0 and generic coding assistants, hand written per finding. ## Beyond security - Legal page links: them no, us yes - Email authentication: them no, us yes - Domain expiry: them no, us yes - Cookie flags: them no, us yes - Platform trust evidence: them yes, us yes Source: https://docs.lovable.dev/features/security ## What happens next - **Them.** Apply the suggested fix inside the editor and re-run the scan on the same project. Source: https://docs.lovable.dev/features/security (read 2026-09-14). - **Us.** You can stop at the free check, or buy the Release Gate at $49 for the package, the Launch Review at $199 for a person, or the Hardening Sprint at $1,750 for the fix work. ## Competitor strengths Lives in the editor with direct project access, so it can inspect database rules and generated configuration that no outside scan can see. ## Choose them if Your app is built in Lovable and you want configuration and rule checks that run inside the editor with project access, before anything is even public. ## Sources - https://docs.lovable.dev/features/security - https://lovable.dev/blog ## ShipReady vs Reeve https://shipreadyai.dev/compare/reeve # ShipReady vs Reeve A research-led scanner that has published a large-scale sweep of AI-built apps. # ShipReady vs Reeve A research-led scanner that has published a large-scale sweep of AI-built apps. Facts about Reeve were read from their site on the dates shown. Tell us if something changed. ## Score or evidence - **Them.** The public write-up reports finding categories and counts across the sample rather than a per-app score. Source: https://reeve.page/ (read 2026-09-14). - **Us.** No score, no grade, no badge. Every finding shows the request that produced it and the date it was read. ## What they show and what they keep - **Them.** The research report is public. The public pages do not describe a self-serve scan for arbitrary URLs. Source: https://reeve.page/ (read 2026-09-14). - **Us.** The full free result is shown to anyone with the check id. Nothing is gated behind a paywall or an account. ## What they do to your app - **Them.** Automated outside checks at research scale. The pages do not describe signing in as your users or executing your database functions. Source: https://reeve.page/ (read 2026-09-14). - **Us.** Deterministic outside requests only. Never signs in, never executes a function on your database, never reads another account's data. ## What neither can see from outside - **Rollback and recovery.** Whether you can put the previous version back, and how long that takes. - **Error monitoring.** Whether a failure in production reaches a human rather than sitting in a log nobody opens. - **Sign in and account flows.** Whether sign in, password or code reset, and session expiry behave under real use. - **Rate limiting and abuse controls.** Whether a script can hammer your forms, sign up loop, or paid endpoints without being slowed down. - **Key rotation.** Whether you can replace a leaked key quickly and know everywhere it is used. - **Certificate expiry date.** Whether the certificate is close to expiring. A normal request proves the certificate is valid right now, and the runtime this check uses cannot read the expiry date from that request. - **One account reading another account's data.** Whether a signed in account can reach another account's records by changing an id. ShipReady does not create accounts, sign in, or call your functions, so this cannot be answered from outside. - **Payment handling.** Whether payment events are verified, replay safe, and matched to the right customer record. - **Customer data handling.** Whether stored personal details are limited, deletable on request, and out of your logs. - **AI feature controls.** Whether prompts, spend, and model output are bounded so one visitor cannot run up the bill. - **Database row rules.** Whether the row rules behind the app actually stop one signed in account reading another's rows. ## Fixes - **Them.** The report describes issue categories rather than per-builder fix prompts. Source: https://reeve.page/ (read 2026-09-14). - **Us.** Every finding carries five fix prompts for Lovable, Bolt, Base44, v0 and generic coding assistants, hand written per finding. ## Beyond security - Legal page links: them no, us yes - Email authentication: them no, us yes - Domain expiry: them no, us yes - Cookie flags: them no, us yes - Platform trust evidence: them no, us yes Source: https://reeve.page/ ## What happens next - **Them.** Read the report and cross reference the categories against your own build. Source: https://reeve.page/ (read 2026-09-14). - **Us.** You can stop at the free check, or buy the Release Gate at $49 for the package, the Launch Review at $199 for a person, or the Hardening Sprint at $1,750 for the fix work. ## Competitor strengths A public research report that puts numbers on how AI-built apps fail at scale, which is useful evidence for anyone shipping in this category. ## Choose them if You want a public research report to reference when you make the case for taking launch checks seriously, and you are not looking for a self-serve URL scan. ## How our checks map to theirs Reeve's report scanned 30,998 AI-built apps and grouped the failures they saw. Our sixteen check groups line up with the same recurring categories: exposed keys and server credentials in client code (their leaked secrets), open database rules and readable rows (their access control failures), public storage buckets and Firebase collections (their exposed storage), missing security headers and transport issues (their transport misconfiguration), and open sign-up with no confirmation (their account controls). Where the report names a class of failure, our check names the same class in the finding it produces. ## Sources - https://reeve.page/ ## ShipReady vs Safe Vibe Codes https://shipreadyai.dev/compare/safe-vibe-codes # ShipReady vs Safe Vibe Codes A community-facing site with guidance and checks aimed at people shipping AI-built apps. # ShipReady vs Safe Vibe Codes A community-facing site with guidance and checks aimed at people shipping AI-built apps. Facts about Safe Vibe Codes were read from their site on the dates shown. Tell us if something changed. ## Score or evidence - **Them.** The public pages present guidance and check lists rather than a numeric score per app. Source: https://safevibe.codes/ (read 2026-09-14). - **Us.** No score, no grade, no badge. Every finding shows the request that produced it and the date it was read. ## What they show and what they keep - **Them.** Guidance and check lists are public. The pages do not describe a per-URL account gate. Source: https://safevibe.codes/ (read 2026-09-14). - **Us.** The full free result is shown to anyone with the check id. Nothing is gated behind a paywall or an account. ## What they do to your app - **Them.** Public pages describe a checklist and guidance rather than an outside scanner that touches your app. Source: https://safevibe.codes/ (read 2026-09-14). - **Us.** Deterministic outside requests only. Never signs in, never executes a function on your database, never reads another account's data. ## What neither can see from outside - **Rollback and recovery.** Whether you can put the previous version back, and how long that takes. - **Error monitoring.** Whether a failure in production reaches a human rather than sitting in a log nobody opens. - **Sign in and account flows.** Whether sign in, password or code reset, and session expiry behave under real use. - **Rate limiting and abuse controls.** Whether a script can hammer your forms, sign up loop, or paid endpoints without being slowed down. - **Key rotation.** Whether you can replace a leaked key quickly and know everywhere it is used. - **Certificate expiry date.** Whether the certificate is close to expiring. A normal request proves the certificate is valid right now, and the runtime this check uses cannot read the expiry date from that request. - **One account reading another account's data.** Whether a signed in account can reach another account's records by changing an id. ShipReady does not create accounts, sign in, or call your functions, so this cannot be answered from outside. - **Payment handling.** Whether payment events are verified, replay safe, and matched to the right customer record. - **Customer data handling.** Whether stored personal details are limited, deletable on request, and out of your logs. - **AI feature controls.** Whether prompts, spend, and model output are bounded so one visitor cannot run up the bill. - **Database row rules.** Whether the row rules behind the app actually stop one signed in account reading another's rows. ## Fixes - **Them.** Written guidance describes remediation. Public pages do not list per-builder fix prompts. Source: https://safevibe.codes/ (read 2026-09-14). - **Us.** Every finding carries five fix prompts for Lovable, Bolt, Base44, v0 and generic coding assistants, hand written per finding. ## Beyond security - Legal page links: them no, us yes - Email authentication: them no, us yes - Domain expiry: them no, us yes - Cookie flags: them no, us yes - Platform trust evidence: them no, us yes Source: https://safevibe.codes/ ## What happens next - **Them.** Work through the guidance yourself, or bring it to a developer. Source: https://safevibe.codes/ (read 2026-09-14). - **Us.** You can stop at the free check, or buy the Release Gate at $49 for the package, the Launch Review at $199 for a person, or the Hardening Sprint at $1,750 for the fix work. ## Competitor strengths Approachable written guidance for people shipping AI-built apps, framed for readers who are not full-time security engineers. ## Choose them if You want to read plain-language guidance about shipping an AI-built app safely and you would rather work through a checklist yourself than run a scanner against your URL. ## Sources - https://safevibe.codes/ ## ShipReady vs SiteSecurityScore https://shipreadyai.dev/compare/site-security-score # ShipReady vs SiteSecurityScore A site-security grader that gives a URL a single score based on outside signals. # ShipReady vs SiteSecurityScore A site-security grader that gives a URL a single score based on outside signals. Facts about SiteSecurityScore were read from their site on the dates shown. Tell us if something changed. ## Score or evidence - **Them.** Presents a single overall score or grade for a URL as the headline output. Source: https://sitesecurityscore.com/ (read 2026-09-14). - **Us.** No score, no grade, no badge. Every finding shows the request that produced it and the date it was read. ## What they show and what they keep - **Them.** The score is shown on the site to anyone with the URL. Detail beyond the grade is not clearly gated on the pages read. Source: https://sitesecurityscore.com/ (read 2026-09-14). - **Us.** The full free result is shown to anyone with the check id. Nothing is gated behind a paywall or an account. ## What they do to your app - **Them.** Outside checks against the public URL. The pages do not describe signing in as your users or executing your database functions. Source: https://sitesecurityscore.com/ (read 2026-09-14). - **Us.** Deterministic outside requests only. Never signs in, never executes a function on your database, never reads another account's data. ## What neither can see from outside - **Rollback and recovery.** Whether you can put the previous version back, and how long that takes. - **Error monitoring.** Whether a failure in production reaches a human rather than sitting in a log nobody opens. - **Sign in and account flows.** Whether sign in, password or code reset, and session expiry behave under real use. - **Rate limiting and abuse controls.** Whether a script can hammer your forms, sign up loop, or paid endpoints without being slowed down. - **Key rotation.** Whether you can replace a leaked key quickly and know everywhere it is used. - **Certificate expiry date.** Whether the certificate is close to expiring. A normal request proves the certificate is valid right now, and the runtime this check uses cannot read the expiry date from that request. - **One account reading another account's data.** Whether a signed in account can reach another account's records by changing an id. ShipReady does not create accounts, sign in, or call your functions, so this cannot be answered from outside. - **Payment handling.** Whether payment events are verified, replay safe, and matched to the right customer record. - **Customer data handling.** Whether stored personal details are limited, deletable on request, and out of your logs. - **AI feature controls.** Whether prompts, spend, and model output are bounded so one visitor cannot run up the bill. - **Database row rules.** Whether the row rules behind the app actually stop one signed in account reading another's rows. ## Fixes - **Them.** Grades and short explanations are shown. Public pages do not list per-builder fix prompts. Source: https://sitesecurityscore.com/ (read 2026-09-14). - **Us.** Every finding carries five fix prompts for Lovable, Bolt, Base44, v0 and generic coding assistants, hand written per finding. ## Beyond security - Legal page links: them no, us yes - Email authentication: them no, us yes - Domain expiry: them no, us yes - Cookie flags: them no, us yes - Platform trust evidence: them no, us yes Source: https://sitesecurityscore.com/ ## What happens next - **Them.** Read the grade, share the score, and decide on remediation on your own. Source: https://sitesecurityscore.com/ (read 2026-09-14). - **Us.** You can stop at the free check, or buy the Release Gate at $49 for the package, the Launch Review at $199 for a person, or the Hardening Sprint at $1,750 for the fix work. ## Competitor strengths A single-number grade that is easy to hand to a non-technical stakeholder for a quick outside view of a URL. ## Choose them if You want one easy grade to hand to a client or manager for a URL and you are not looking for evidence per finding or fix prompts you can paste back into a builder. ## Sources - https://sitesecurityscore.com/ ## ShipReady vs Vibe App Scanner https://shipreadyai.dev/compare/vibe-app-scanner # ShipReady vs Vibe App Scanner A scanner for AI-built apps with broad automated coverage and paid access to the full report. # ShipReady vs Vibe App Scanner A scanner for AI-built apps with broad automated coverage and paid access to the full report. Facts about Vibe App Scanner were read from their site on the dates shown. Tell us if something changed. ## Score or evidence - **Them.** The public pages describe automated checks across security, SEO and performance, and lead with the count of checks rather than a single score. Source: https://vibeappscanner.com/security-checks (read 2026-09-14). - **Us.** No score, no grade, no badge. Every finding shows the request that produced it and the date it was read. ## What they show and what they keep - **Them.** First scan is free; the full report and repeat scans are behind paid plans and an account. Source: https://vibeappscanner.com/pricing (read 2026-09-14). - **Us.** The full free result is shown to anyone with the check id. Nothing is gated behind a paywall or an account. ## What they do to your app - **Them.** Automated outside checks against a URL. Public pages do not describe executing your database functions, signing in as your users, or reading another account's records. Source: https://vibeappscanner.com/what-is-vibe-app-scanner (read 2026-09-14). - **Us.** Deterministic outside requests only. Never signs in, never executes a function on your database, never reads another account's data. ## What neither can see from outside - **Rollback and recovery.** Whether you can put the previous version back, and how long that takes. - **Error monitoring.** Whether a failure in production reaches a human rather than sitting in a log nobody opens. - **Sign in and account flows.** Whether sign in, password or code reset, and session expiry behave under real use. - **Rate limiting and abuse controls.** Whether a script can hammer your forms, sign up loop, or paid endpoints without being slowed down. - **Key rotation.** Whether you can replace a leaked key quickly and know everywhere it is used. - **Certificate expiry date.** Whether the certificate is close to expiring. A normal request proves the certificate is valid right now, and the runtime this check uses cannot read the expiry date from that request. - **One account reading another account's data.** Whether a signed in account can reach another account's records by changing an id. ShipReady does not create accounts, sign in, or call your functions, so this cannot be answered from outside. - **Payment handling.** Whether payment events are verified, replay safe, and matched to the right customer record. - **Customer data handling.** Whether stored personal details are limited, deletable on request, and out of your logs. - **AI feature controls.** Whether prompts, spend, and model output are bounded so one visitor cannot run up the bill. - **Database row rules.** Whether the row rules behind the app actually stop one signed in account reading another's rows. ## Fixes - **Them.** Fix guidance framed for AI coding tools, tied to the paid tiers. Public pages do not list per-builder prompts. Source: https://vibeappscanner.com/pricing (read 2026-09-14). - **Us.** Every finding carries five fix prompts for Lovable, Bolt, Base44, v0 and generic coding assistants, hand written per finding. ## Beyond security - Legal page links: them no, us yes - Email authentication: them no, us yes - Domain expiry: them no, us yes - Cookie flags: them no, us yes - Platform trust evidence: them no, us yes Source: https://vibeappscanner.com/security-checks ## What happens next - **Them.** Upgrade to Go or Pro for the full report, extra scans, and MCP access for agent workflows. Source: https://vibeappscanner.com/pricing (read 2026-09-14). - **Us.** You can stop at the free check, or buy the Release Gate at $49 for the package, the Launch Review at $199 for a person, or the Hardening Sprint at $1,750 for the fix work. ## Competitor strengths Broad automated coverage across security, SEO and performance for AI-built apps, with MCP access on paid plans for agent-driven scanning. ## Choose them if You want one automated scanner that covers security, SEO and performance in one report, you are ready to pay a monthly fee, and you plan to plug the scanner into an agent workflow through MCP. ## Sources - https://vibeappscanner.com/ - https://vibeappscanner.com/security-checks - https://vibeappscanner.com/pricing - https://vibeappscanner.com/what-is-vibe-app-scanner ## ShipReady vs VibeEval https://shipreadyai.dev/compare/vibeeval # ShipReady vs VibeEval A live-URL black-box scanner whose findings are reviewed by an engineer before delivery. # ShipReady vs VibeEval A live-URL black-box scanner whose findings are reviewed by an engineer before delivery. Facts about VibeEval were read from their site on the dates shown. Tell us if something changed. ## Score or evidence - **Them.** The public pages describe evidence per finding after engineer verification, not a single score. Source: https://vibe-eval.com/methodology/ (read 2026-09-14). - **Us.** No score, no grade, no badge. Every finding shows the request that produced it and the date it was read. ## What they show and what they keep - **Them.** An account, a target and billing precede the findings. Engineer-verified findings arrive after that step. Source: https://vibe-eval.com/docs/ (read 2026-09-14). - **Us.** The full free result is shown to anyone with the check id. Nothing is gated behind a paywall or an account. ## What they do to your app - **Them.** Black-box dynamic probing against the live URL. The pages do not describe signing in as your users or executing your database functions. Source: https://vibe-eval.com/methodology/ (read 2026-09-14). - **Us.** Deterministic outside requests only. Never signs in, never executes a function on your database, never reads another account's data. ## What neither can see from outside - **Rollback and recovery.** Whether you can put the previous version back, and how long that takes. - **Error monitoring.** Whether a failure in production reaches a human rather than sitting in a log nobody opens. - **Sign in and account flows.** Whether sign in, password or code reset, and session expiry behave under real use. - **Rate limiting and abuse controls.** Whether a script can hammer your forms, sign up loop, or paid endpoints without being slowed down. - **Key rotation.** Whether you can replace a leaked key quickly and know everywhere it is used. - **Certificate expiry date.** Whether the certificate is close to expiring. A normal request proves the certificate is valid right now, and the runtime this check uses cannot read the expiry date from that request. - **One account reading another account's data.** Whether a signed in account can reach another account's records by changing an id. ShipReady does not create accounts, sign in, or call your functions, so this cannot be answered from outside. - **Payment handling.** Whether payment events are verified, replay safe, and matched to the right customer record. - **Customer data handling.** Whether stored personal details are limited, deletable on request, and out of your logs. - **AI feature controls.** Whether prompts, spend, and model output are bounded so one visitor cannot run up the bill. - **Database row rules.** Whether the row rules behind the app actually stop one signed in account reading another's rows. ## Fixes - **Them.** Findings arrive with engineer commentary. Public pages do not list per-builder fix prompts. Source: https://vibe-eval.com/methodology/ (read 2026-09-14). - **Us.** Every finding carries five fix prompts for Lovable, Bolt, Base44, v0 and generic coding assistants, hand written per finding. ## Beyond security - Legal page links: them no, us yes - Email authentication: them no, us yes - Domain expiry: them no, us yes - Cookie flags: them no, us yes - Platform trust evidence: them no, us yes Source: https://vibe-eval.com/ ## What happens next - **Them.** The engineer-verified report is delivered inside the account, then the customer decides on remediation on their own. Source: https://vibe-eval.com/docs/ (read 2026-09-14). - **Us.** You can stop at the free check, or buy the Release Gate at $49 for the package, the Launch Review at $199 for a person, or the Hardening Sprint at $1,750 for the fix work. ## Competitor strengths Live black-box probing combined with a security engineer's review of every finding before it reaches the customer. ## Choose them if You want a person to inspect automated evidence before you see it, you are comfortable with an account and billing before results, and you already have someone to do the remediation. ## Sources - https://vibe-eval.com/ - https://vibe-eval.com/methodology/ - https://vibe-eval.com/docs/ - https://vibe-eval.com/vibe-code-scanner/ ## ShipReady vs VibeShip Scanner https://shipreadyai.dev/compare/vibeship-scanner # ShipReady vs VibeShip Scanner A free open-source scanner that checks public repositories and returns AI-oriented fix guidance. # ShipReady vs VibeShip Scanner A free open-source scanner that checks public repositories and returns AI-oriented fix guidance. Facts about VibeShip Scanner were read from their site on the dates shown. Tell us if something changed. ## Score or evidence - **Them.** The scanner reports finding lists from a stated rule set, not a single score. Source: https://github.com/vibeforge1111/vibeship-scanner/ (read 2026-09-14). - **Us.** No score, no grade, no badge. Every finding shows the request that produced it and the date it was read. ## What they show and what they keep - **Them.** Anyone can run a scan on the public interface. The source itself is Apache-2.0. Source: https://github.com/vibeforge1111/vibeship-scanner/ (read 2026-09-14). - **Us.** The full free result is shown to anyone with the check id. Nothing is gated behind a paywall or an account. ## What they do to your app - **Them.** Scans public repositories and issues outside requests. It does not sign in as your users or execute your database functions. Source: https://vibeship-scanner-production.up.railway.app/ (read 2026-09-14). - **Us.** Deterministic outside requests only. Never signs in, never executes a function on your database, never reads another account's data. ## What neither can see from outside - **Rollback and recovery.** Whether you can put the previous version back, and how long that takes. - **Error monitoring.** Whether a failure in production reaches a human rather than sitting in a log nobody opens. - **Sign in and account flows.** Whether sign in, password or code reset, and session expiry behave under real use. - **Rate limiting and abuse controls.** Whether a script can hammer your forms, sign up loop, or paid endpoints without being slowed down. - **Key rotation.** Whether you can replace a leaked key quickly and know everywhere it is used. - **Certificate expiry date.** Whether the certificate is close to expiring. A normal request proves the certificate is valid right now, and the runtime this check uses cannot read the expiry date from that request. - **One account reading another account's data.** Whether a signed in account can reach another account's records by changing an id. ShipReady does not create accounts, sign in, or call your functions, so this cannot be answered from outside. - **Payment handling.** Whether payment events are verified, replay safe, and matched to the right customer record. - **Customer data handling.** Whether stored personal details are limited, deletable on request, and out of your logs. - **AI feature controls.** Whether prompts, spend, and model output are bounded so one visitor cannot run up the bill. - **Database row rules.** Whether the row rules behind the app actually stop one signed in account reading another's rows. ## Fixes - **Them.** Prompts framed for AI coding tools accompany findings. Public pages do not list per-builder templates. Source: https://github.com/vibeforge1111/vibeship-scanner/ (read 2026-09-14). - **Us.** Every finding carries five fix prompts for Lovable, Bolt, Base44, v0 and generic coding assistants, hand written per finding. ## Beyond security - Legal page links: them no, us yes - Email authentication: them no, us yes - Domain expiry: them no, us yes - Cookie flags: them no, us yes - Platform trust evidence: them no, us yes Source: https://github.com/vibeforge1111/vibeship-scanner/ ## What happens next - **Them.** Read the findings, paste the AI prompt into your coding tool, or self-host the scanner from the repository. Source: https://github.com/vibeforge1111/vibeship-scanner/ (read 2026-09-14). - **Us.** You can stop at the free check, or buy the Release Gate at $49 for the package, the Launch Review at $199 for a person, or the Hardening Sprint at $1,750 for the fix work. ## Competitor strengths Open source under Apache-2.0 with a large stated rule set and AI fix prompts. Anyone can read the scanner code and self-host it. ## Choose them if You want to read the scanner's code, self-host it inside your own environment, and get prompts to paste into an AI coding tool without paying for a service. ## Sources - https://vibeship-scanner-production.up.railway.app/ - https://github.com/vibeforge1111/vibeship-scanner/ ## Glossary https://shipreadyai.dev/glossary # Glossary 44 terms from a Launch Risk Check result, in plain English. - [Anon key](https://shipreadyai.dev/glossary/anon-key.md): The public browser key. Safe to publish, useless without rules behind it. - [Batch prompt](https://shipreadyai.dev/glossary/batch-prompt.md): One instruction that fixes several findings in a single pass. - [Claim token](https://shipreadyai.dev/glossary/claim-token.md): The unguessable string that lets you attach an anonymous result to your account later. - [Content-Security-Policy](https://shipreadyai.dev/glossary/content-security-policy.md): The header that tells the browser which code it is allowed to run. - [Cookie flags](https://shipreadyai.dev/glossary/cookie-flags.md): The three settings that decide how safely a cookie travels. - [Cost cap](https://shipreadyai.dev/glossary/cost-cap.md): The ceiling that stops one visitor spending your month's budget in an hour. - [Could not check](https://shipreadyai.dev/glossary/could-not-check.md): The request failed, so there is no result for that item. - [Cross origin rules](https://shipreadyai.dev/glossary/cross-origin-rules.md): The header that decides which other sites may read your responses. - [Declared](https://shipreadyai.dev/glossary/declared.md): Something you told us, recorded as your statement rather than our finding. - [Detected](https://shipreadyai.dev/glossary/detected.md): Something the check worked out about your app without being told. - [DMARC](https://shipreadyai.dev/glossary/dmarc.md): The record that tells receiving servers what to do when mail fails your checks. - [Domain expiry](https://shipreadyai.dev/glossary/domain-expiry.md): The date your domain registration runs out, published in the registry. - [Entitlement](https://shipreadyai.dev/glossary/entitlement.md): The record that says this account paid for this thing. - [Evidence](https://shipreadyai.dev/glossary/evidence.md): The line of raw observation behind a finding. - [Exposed path](https://shipreadyai.dev/glossary/exposed-path.md): An address that answers when it should not. - [Fingerprint](https://shipreadyai.dev/glossary/fingerprint.md): What your app quietly tells the internet about how it was built. - [Fix prompt](https://shipreadyai.dev/glossary/fix-prompt.md): A ready instruction for the tool that built your app. - [frame-ancestors](https://shipreadyai.dev/glossary/frame-ancestors.md): The rule that stops another site putting your app inside an invisible frame. - [Hardening Sprint](https://shipreadyai.dev/glossary/hardening-sprint.md): The $1,750 engagement that takes the top items from needs fix to fixed and re-verified. - [HSTS](https://shipreadyai.dev/glossary/hsts.md): The header that tells browsers to never speak to your site over plain HTTP again. - [Idempotency](https://shipreadyai.dev/glossary/idempotency.md): Doing the same thing twice has the same effect as doing it once. - [Launch Review](https://shipreadyai.dev/glossary/launch-review.md): The $199 review where a named person looks at what a URL cannot see. - [Launch Risk Statement](https://shipreadyai.dev/glossary/launch-risk-statement.md): A dated page saying what was observed, what was declared, and what nobody verified. - [Mixed content](https://shipreadyai.dev/glossary/mixed-content.md): A secure page loading something over plain HTTP. - [Not verified](https://shipreadyai.dev/glossary/not-verified.md): Named items nobody checked, listed rather than quietly dropped. - [Observed](https://shipreadyai.dev/glossary/observed.md): Something a check actually read from your published app, with the evidence attached. - [Open signup](https://shipreadyai.dev/glossary/open-signup.md): Whether anyone can create an account, and whether the address has to be proved. - [Prompt injection](https://shipreadyai.dev/glossary/prompt-injection.md): Text your app feeds to a model that the model treats as instructions. - [Publishable key](https://shipreadyai.dev/glossary/publishable-key.md): The newer name for a public client key. Same rule: public by design, not a permission. - [Rate limit](https://shipreadyai.dev/glossary/rate-limit.md): The rule that slows down whoever is asking too often. - [Release Assurance](https://shipreadyai.dev/glossary/release-assurance.md): The monthly option that keeps a current statement for teams shipping every week. - [Release Gate](https://shipreadyai.dev/glossary/release-gate.md): The $49 package that hands you the checklist and the guardrails to fix things yourself. - [Rollback](https://shipreadyai.dev/glossary/rollback.md): Putting the previous version back, quickly, when the new one is wrong. - [Row level security](https://shipreadyai.dev/glossary/row-level-security.md): The rule that decides which rows of a table an account may read or change. - [Security definer](https://shipreadyai.dev/glossary/security-definer.md): A database function that runs with its author's permissions rather than the caller's. - [Service role key](https://shipreadyai.dev/glossary/service-role-key.md): The key that ignores every access rule. It belongs on a server and nowhere else. - [Slopsquatting](https://shipreadyai.dev/glossary/slopsquatting.md): Registering the package names AI tools invent, and waiting. - [Source map](https://shipreadyai.dev/glossary/source-map.md): The file that turns your shipped bundle back into readable source. - [SPF](https://shipreadyai.dev/glossary/spf.md): The DNS record naming who is allowed to send email as your domain. - [Staleness](https://shipreadyai.dev/glossary/staleness.md): How out of date an observation is, stated rather than hidden. - [Storage bucket](https://shipreadyai.dev/glossary/storage-bucket.md): The place uploaded files live, and the setting that decides who can read them. - [Tenant isolation](https://shipreadyai.dev/glossary/tenant-isolation.md): One customer's data staying entirely out of another customer's account. - [Trust Center](https://shipreadyai.dev/glossary/trust-center.md): A published page that answers the security questions buyers ask. - [Webhook signature](https://shipreadyai.dev/glossary/webhook-signature.md): Proof that the message really came from the service that claims to have sent it. ## Anon key https://shipreadyai.dev/glossary/anon-key # Anon key The public browser key. Safe to publish, useless without rules behind it. The anon key is the public key your app ships to the browser so it can talk to your backend. It is meant to be visible. Seeing it in your bundle is not a finding. The mistake is assuming it protects anything. It identifies the project, not the person. Everything it can reach is decided by the row rules behind it. If a table has no rules, the anon key reads that table, and so can anyone who opens your app and copies the key. A check from outside can take the published key and ask your tables whether they answer. When they do, that is finding O8, with the table name as evidence. Whether the rules that should be there are correct is a separate question that no URL can settle. ## Batch prompt https://shipreadyai.dev/glossary/batch-prompt # Batch prompt One instruction that fixes several findings in a single pass. A batch prompt combines the findings that live in the same place. Three missing response headers are not three jobs. They are one edit in the one file where your app builds responses, and sending three separate prompts invites three separate rewrites. It is assembled from the same written pieces as the individual prompts, in priority order, with the shared instruction stated once. Nothing is generated on the fly, so what you copy today is what you would have copied yesterday. The rule is same place, same pass. Headers batch together. A legal page and a row rule do not, because they touch different parts of the app and a single prompt that spans both gives an agent room to improvise. ## Claim token https://shipreadyai.dev/glossary/claim-token # Claim token The unguessable string that lets you attach an anonymous result to your account later. The free check needs no account. That creates a question: if you run a check and buy something an hour later, how does the purchase find the result? A claim token answers it. When a check is created, a long random value is issued with it. Holding the token is what proves the result is yours. When you sign in at purchase, the token attaches the check to your account, once. It has to be long enough that guessing is pointless, tied to a single check, and useless after it is redeemed. It is never a sequential number and never an email address. The alternative is forcing sign in before the free check, which would cost more people than it protects. ## Content-Security-Policy https://shipreadyai.dev/glossary/content-security-policy # Content-Security-Policy The header that tells the browser which code it is allowed to run. Content-Security-Policy is a response header that lists the sources a browser may load scripts, styles and frames from. Anything outside the list is refused. It is the difference between an injected script running and an injected script being blocked by the browser before it does anything. Most AI-built apps ship without one, because nothing in the build asks for it. The header is not written by your framework, your builder or your host. It is written by you, in the one place your app produces responses. A check reads the header directly from your published app, so the result is what a real visitor gets rather than what a config file claims. Writing a first policy takes an afternoon, mostly spent finding the third-party scripts you forgot you added. ## Cookie flags https://shipreadyai.dev/glossary/cookie-flags # Cookie flags The three settings that decide how safely a cookie travels. A session cookie is the thing that keeps someone signed in. Three flags decide how well it is protected. Secure means it is only ever sent over HTTPS. HttpOnly means JavaScript cannot read it, so an injected script cannot steal it. SameSite controls whether it travels on requests started by other sites. Defaults are not always right, and frameworks differ. A cookie without HttpOnly turns any scripting bug into an account takeover. A cookie without SameSite turns a link on another site into an action taken as your user. A check reads the cookies your published app sets and reports the flags it sees, so this one is observable rather than declared. Setting them is a small change in the one place your app creates sessions. ## Cost cap https://shipreadyai.dev/glossary/cost-cap # Cost cap The ceiling that stops one visitor spending your month's budget in an hour. A cost cap is a hard limit on what your app can spend on a paid service, usually an AI model. It has three parts: a limit per request, a limit per user per period, and a limit for the whole account that shuts things off rather than billing on. AI features make this urgent because the cost of one request has no natural ceiling. A long input, a long output and a loop are enough. An unauthenticated endpoint that calls a model on every request is a bill waiting for whoever finds it. Your provider's spend limit is the backstop, not the plan. Rate limits and input length limits come first. A check from outside cannot see any of it, so AI features stay on the not-verified list. ## Could not check https://shipreadyai.dev/glossary/could-not-check # Could not check The request failed, so there is no result for that item. Could not check means the attempt was made and nothing usable came back. The app timed out, the host refused the connection, the certificate could not be completed, or the address did not resolve. It is deliberately not folded into a pass or a fail. An item that failed to load is not an item that passed, and it is not evidence of a problem either. Reporting it as either one would be a small lie that makes the rest of the document less trustworthy. Usually it means the app was asleep, the URL had a typo, or a firewall stopped an unfamiliar client. Run the check again when the app answers from the public internet and the item resolves to a real result. ## Cross origin rules https://shipreadyai.dev/glossary/cross-origin-rules # Cross origin rules The header that decides which other sites may read your responses. Browsers stop one site from reading another site's responses unless the second site says it is allowed. That permission is a response header, and the value is either a wildcard meaning every site, a reflection of whoever asked, or an explicit list of addresses you trust. The wildcard usually arrives during development, when a page running locally needs to talk to a deployed backend and the fastest way through is to allow everything. It works, the afternoon continues, and the setting ships. Nothing fails afterwards, which is why it stays. The combination that matters is a reflected origin together with credentials allowed. That tells the browser it is fine for another site to make requests using your visitor's session and read what comes back. A check can read both headers from outside with one request, which is why this is observable rather than declared. ## Declared https://shipreadyai.dev/glossary/declared # Declared Something you told us, recorded as your statement rather than our finding. Declared means the information came from you. You said the app takes payments. You said it stores customer data. You said the backend is Lovable Cloud. None of that was verified, and the result says so by putting it in its own list. Keeping declarations separate from observations is the whole discipline. The moment the two are mixed, a reader cannot tell what was checked and what was typed in, and the document stops being worth anything to a buyer. Declarations still matter. They decide which not-verified items apply to you and which parts of the checklist you get. An app with no payments does not need the payment items. Your answer shapes the result without pretending to be evidence. ## Detected https://shipreadyai.dev/glossary/detected # Detected Something the check worked out about your app without being told. Detected sits between observed and declared. It means the check inferred something about your app from what it served: the builder that made it, the backend behind it, whether payments are wired up, whether a map file is published. It is a reasonable inference, not a confession and not a measurement. Detection can be wrong, which is why every detected fact on a result can be corrected by the person who owns the app. Correcting one changes the checklist you get, so it is worth thirty seconds. The point of detection is to stop asking questions the app can answer itself. A form with one field beats a form with seven, and the seven answers were never that reliable anyway. ## DMARC https://shipreadyai.dev/glossary/dmarc # DMARC The record that tells receiving servers what to do when mail fails your checks. DMARC sits on top of SPF and tells receiving servers what to do with mail that fails: let it through, put it in spam, or reject it. It also asks them to send you reports, so you find out who is sending mail as you. Publishing SPF without DMARC is like writing a rule with no consequence. Many receivers will be lenient, and some large providers now expect DMARC before they will treat your mail as legitimate at all. Start at none with a reporting address, read what comes back for a couple of weeks, then move to quarantine and then reject once you know every legitimate sender. A check reads the record from DNS and reports what is published, including the policy you chose. ## Domain expiry https://shipreadyai.dev/glossary/domain-expiry # Domain expiry The date your domain registration runs out, published in the registry. Every registered domain has an expiry date held in a public registry record. On that date, unless it is renewed, the domain stops resolving. The app goes, the mail goes, the sign in links in every message you have ever sent go with it. This is the least technical item on a launch result and one of the most expensive to get wrong. It is not in your code, no coding agent touches it, and the reminder goes to whichever address was used at the registrar, which is often a personal one nobody reads any more. The usual cause of an outage is not the domain, it is the card on file expiring before the domain does. The registry record is public, so a check can read the date and report how many days are left, with the request it made as evidence. Renewing early costs nothing and the years stack. ## Entitlement https://shipreadyai.dev/glossary/entitlement # Entitlement The record that says this account paid for this thing. An entitlement is the row that connects a customer to something they bought. Not the charge, not the receipt, the access itself. It is what your app reads when it decides whether to show the paid page. Three things go wrong with it. It is granted by the browser instead of the server, so anyone can grant themselves one. It is granted more than once because the payment webhook retried. It is never revoked after a refund, so access outlives the money. The safe shape is small: written only by server code, after a verified payment event, keyed so a repeat is impossible, and readable only by its owner. None of that is visible from a URL, which is why payment handling stays on the not-verified list. ## Evidence https://shipreadyai.dev/glossary/evidence # Evidence The line of raw observation behind a finding. Evidence is the piece of the response that caused a finding to exist: the header value as served, the URL of the map file that answered, the status code returned by a path, the name of the table that responded to the public key. Every observed line on a ShipReady result carries one. It is not decoration. It is what lets you confirm the finding yourself in ten seconds with a browser or a single command, and it is what lets you argue when the finding is wrong. A result without evidence asks to be trusted. A result with evidence asks to be checked. The second one is more useful to you, more useful to whoever you show it to, and considerably harder to fake. ## Exposed path https://shipreadyai.dev/glossary/exposed-path # Exposed path An address that answers when it should not. An exposed path is a URL on your app that returns something useful to a stranger. An admin page with no check in front of it. An environment file. A database dump left in the public folder. A build artefact. A debug route someone added on a Tuesday. None of it is linked from your interface, which is why it survives. It does not need to be linked. These addresses are guessed by lists, thousands at a time, by tools that cost nothing to run. The Moltbook exposure involved an open admin route alongside missing access rules. A check requests a set of common paths and reports the ones that answer, with the status code as evidence. The fix is either delete or put a real check in front. ## Fingerprint https://shipreadyai.dev/glossary/fingerprint # Fingerprint What your app quietly tells the internet about how it was built. A fingerprint is the collection of small signals that identify your stack from outside: a header naming the host, a build artefact naming the framework, a cookie name, a familiar path, a meta tag left by a builder. On its own it is not a problem. Every app on the internet has one. It matters because it tells someone which known issues are worth trying against you, and it turns a general scan into a targeted one. When CVE entries for AI-generated code climb month over month, being identifiable as a particular builder is a filter someone can search on. A check records what it can see so the fingerprint is a fact rather than a guess. Reducing it is mostly removing what you do not need to publish. ## Fix prompt https://shipreadyai.dev/glossary/fix-prompt # Fix prompt A ready instruction for the tool that built your app. A fix prompt is the wording you paste into your coding agent to correct one finding. Every finding has five of them, one for each dialect: Lovable chat, Claude Code, Codex, Cursor, and a generic version for everything else. They are written, not generated. The scanner makes no AI calls, so the same finding produces the same prompt every time, and nothing invents a file path that does not exist. Each prompt does three things. It names the single place to change, so the agent does not wander. It forbids touching anything else, because the most expensive thing an agent does is helpful extra work. And it ends with a verification step, so you get back the value that was set and can run the check again. ## frame-ancestors https://shipreadyai.dev/glossary/frame-ancestors # frame-ancestors The rule that stops another site putting your app inside an invisible frame. frame-ancestors is the part of a Content-Security-Policy that says which sites may embed your pages in a frame. Set to none, nobody can. Set to nothing at all, anybody can. The attack it prevents is clickjacking. Someone loads your app in a transparent frame over their own page, and a visitor who thinks they are clicking a harmless button is actually clicking yours, already signed in. It is old, simple, and still works on apps that never set the rule. A check reads the header as served. The fix is a single directive alongside the rest of your policy. If you genuinely need to be embedded, name the sites that may do it rather than leaving the door open to all of them. ## Hardening Sprint https://shipreadyai.dev/glossary/hardening-sprint # Hardening Sprint The $1,750 engagement that takes the top items from needs fix to fixed and re-verified. A Hardening Sprint is for the founder who has the list and does not have the time. The highest priority items get fixed, and then checked again so the statement reflects the fixed state rather than the intention. It is the difference between knowing that row rules are missing and having row rules that work. The two incidents this most resembles, the Moltbook exposure and CVE-2025-48757, were both fixable in a day of focused work by someone who had done it before. You get the changes, the re-verification, and a statement dated after the work. What you do not get is a promise that nothing else exists. Fixing the known list is real progress and it is not a guarantee, and anyone selling it as one is selling something else. ## HSTS https://shipreadyai.dev/glossary/hsts # HSTS The header that tells browsers to never speak to your site over plain HTTP again. HSTS stands for Strict-Transport-Security. It is a response header that tells a browser to use HTTPS for your domain for a stated period, even if a link, a bookmark or a typed address says otherwise. The browser upgrades the request before it leaves the machine. A redirect from HTTP to HTTPS is good, but the first request still goes out in the clear. HSTS closes that window for every visit after the first. A check reads the header from your published app and reports whether it is present and how long it lasts. It is one line in the place your app sets headers, and it is one of the few items on a result that is genuinely a ten minute job. ## Idempotency https://shipreadyai.dev/glossary/idempotency # Idempotency Doing the same thing twice has the same effect as doing it once. Idempotency means an operation can be repeated without changing the outcome. Charge a card once, receive the webhook three times because the network retried, and the customer should still have exactly one purchase and one grant of access. Payment providers retry deliberately. They assume you handle repeats. An app that grants an entitlement every time a webhook arrives will hand out three of them, and an app that inserts a row every time will show three charges to a customer who paid once. The usual answer is an event id stored on first receipt and checked before any write. It is simple and it is almost never there in a first version. No external check can see it, so payment handling stays Not verified until someone replays a webhook and watches what happens. ## Launch Review https://shipreadyai.dev/glossary/launch-review # Launch Review The $199 review where a named person looks at what a URL cannot see. A Launch Review is the only thing that moves items off the not-verified list. A person signs in, tries the flows, reads the rules, replays a webhook and writes a dated verdict with their name on it. It covers the items the free check names and cannot reach: sign in and session behaviour, row rules and tenant isolation, payment handling, rollback, rate limits, key rotation and customer data handling. The output is a written statement you can show a customer, not a dashboard. It says what was examined, on what date, by whom, and what was found. It does not say the app is safe, because no review can say that. It says what a competent reviewer saw when they looked. ## Launch Risk Statement https://shipreadyai.dev/glossary/launch-risk-statement # Launch Risk Statement A dated page saying what was observed, what was declared, and what nobody verified. A Launch Risk Statement is the artefact ShipReady produces. It is a dated page with three lists on it. Observed is what a check read from outside, each line carrying its evidence. Declared is what you said about your own app. Not verified is what nobody looked at, named rather than omitted. It does not carry a score, a badge or a grade. Scores invite comparison between things that are not comparable, and badges get screenshotted long after they stop being true. A date and a list survive both problems. A free check produces the first two lists and names the third. A Launch Review turns items from the third list into a written verdict from a named reviewer. The statement changes because a person looked, not because the wording improved. ## Mixed content https://shipreadyai.dev/glossary/mixed-content # Mixed content A secure page loading something over plain HTTP. Mixed content is an HTTPS page that pulls in a script, an image, a font or a frame over plain HTTP. The padlock is still there, but part of the page arrived unprotected and can be read or changed on the way. Browsers block the dangerous kinds outright now, which is why mixed content usually shows up as a feature that silently does not work rather than as a warning anyone sees. An analytics script that never loads, a map that stays blank, a font that falls back. It creeps in through copied snippets and old documentation. The fix is to serve everything over HTTPS, and to stop hard-coding protocols in URLs. A check reads the published page, so this is one of the items observable from outside. ## Not verified https://shipreadyai.dev/glossary/not-verified # Not verified Named items nobody checked, listed rather than quietly dropped. Not verified is the list of things that matter and that a check from outside cannot reach: sign in behaviour, row rules, rollback, rate limits, payment handling, key rotation, customer data handling, AI controls, error monitoring. Most tools leave these out, and the result reads as if the app were covered. It is not covered. An assessment of 200 AI-built apps found 91.5 percent carried at least one vulnerability, and most of what that study counts lives behind the login. So ShipReady names each one, explains why a URL cannot see it, and gives a way to test it yourself in a few minutes. A Launch Review moves items off this list by having a person look. Nothing else does. ## Observed https://shipreadyai.dev/glossary/observed # Observed Something a check actually read from your published app, with the evidence attached. Observed is the strongest word on a ShipReady result, and it is still a modest one. It means a request was made to your public app and something came back that supports the statement. The header was there. The map answered. The table returned rows. Every observed line carries the evidence and the moment it was read. That matters because an app changes. An observation from Tuesday describes Tuesday, and a result that hides its date is asking to be misread. Observed never means fine, safe or finished. It means seen. A result full of observations still sits next to a not-verified list, because the items a URL can reach are not the items that usually cause the damage. ## Open signup https://shipreadyai.dev/glossary/open-signup # Open signup Whether anyone can create an account, and whether the address has to be proved. Backends publish a small settings document so the sign in screen knows what to show: which providers are on, whether self signup is allowed, whether a new account is confirmed automatically. It is served to the browser by design, which means it can be read from outside. Two values on it decide a lot. Self signup being on means a script can create accounts at whatever rate your limits allow. Automatic confirmation means an account can be created with an address the person does not own, which matters as soon as anything in your product is addressed by email. Neither is wrong on its own. A consumer product wants open signup. An invite only tool does not, and shipped with the default because the default is what made the first test account work. A check reports the values as published and leaves the decision where it belongs. ## Prompt injection https://shipreadyai.dev/glossary/prompt-injection # Prompt injection Text your app feeds to a model that the model treats as instructions. Prompt injection is what happens when content becomes command. Your app passes a web page, an uploaded document or a user message to a model, and somewhere inside that text is a line telling the model to ignore its instructions and do something else. It matters most when the model can act: call a tool, read a file, send a request. A summariser that gets tricked produces a bad summary. An agent that gets tricked takes an action you never authorised. OpenClaw's 2026 allowlist bypass scored 9.9 for exactly this reason. The defences are boring and effective: treat every external text as data, never as instruction, keep tool permissions narrow, and validate output before acting on it. None of it is visible from outside, so AI features stay Not verified. ## Publishable key https://shipreadyai.dev/glossary/publishable-key # Publishable key The newer name for a public client key. Same rule: public by design, not a permission. A publishable key is a public identifier a service gives you for browser use. Stripe has one, Supabase has one, most platforms have one. It is designed to sit in client code where anyone can read it. The danger is the pair it travels with. Every service that issues a publishable key also issues a secret one, and the two look similar enough that an agent copying configuration will sometimes take the wrong one. A publishable key in the bundle is normal. A secret key in the bundle is an emergency. A check reads your client JavaScript and distinguishes the two by prefix and shape. Publishable keys are reported as nothing at all. Secret keys are reported as finding O4, with the evidence line and the date so you can act on it immediately. ## Rate limit https://shipreadyai.dev/glossary/rate-limit # Rate limit The rule that slows down whoever is asking too often. A rate limit caps how many times a given caller can hit an endpoint in a period. It is the difference between a script being annoying and a script being expensive. The endpoints that need it most are the ones people forget: sign up, password reset, contact forms, search, and anything that calls a paid service. Without a limit, one script can fill your database with junk accounts, send thousands of emails from your domain and ruin its reputation, or run your model bill into real money overnight. Limits belong on the server, keyed on something the caller cannot change freely. A check from outside deliberately does not test this, because testing it means attacking you. It stays Not verified, and the way to check is to try it yourself. ## Release Assurance https://shipreadyai.dev/glossary/release-assurance # Release Assurance The monthly option that keeps a current statement for teams shipping every week. Release Assurance is for teams that ship continuously. A statement dated three months ago describes an app that no longer exists, so the point here is currency rather than depth. Checks run on a schedule, the statement updates, and changes are flagged when something that used to be observed stops being observed. A header removed in a refactor is the classic one: nobody notices for weeks because nothing visibly breaks. It is the only recurring product ShipReady sells, and it exists because shipping weekly makes a one-time document go stale faster than it is useful. If you launch once and move on, you do not need it. If you deploy on Fridays, a statement nobody refreshes is worse than none. ## Release Gate https://shipreadyai.dev/glossary/release-gate # Release Gate The $49 package that hands you the checklist and the guardrails to fix things yourself. Release Gate is the first paid step. It is for the founder who read the result, agrees with it, and wants to do the work. It contains the launch checklist built for your stack, the repository guardrails that keep an agent from touching production, the rollback requirements, and the fix prompts written for the builder you actually use. It is a package you download and keep, not a subscription. Two incidents in the library are the reason the rollback requirements exist: an agent looping a move command until a project was gone, and another wiping production databases after being told not to. Guardrails are cheap before the event and impossible afterwards. Nothing in the Release Gate claims your app is fine. It gives you the list and gets out of the way. ## Rollback https://shipreadyai.dev/glossary/rollback # Rollback Putting the previous version back, quickly, when the new one is wrong. Rollback is the ability to return to the last good version of your app in minutes, not hours. It is the single most valuable thing you can have on launch day, and the thing most first launches have never tried. Code rollback is the easy half. Most hosts keep previous deployments and can serve one again with a click. Data is the hard half. A migration that dropped a column, or an agent that deleted rows, is not undone by redeploying code. Three incidents in the library are pure rollback stories, including an agent wiping production databases and another destroying 2.5 years of data. The test is simple: deploy a trivial change, roll it back, and time how long the app was wrong. ## Row level security https://shipreadyai.dev/glossary/row-level-security # Row level security The rule that decides which rows of a table an account may read or change. Row level security is the rule that sits between a table and whoever is asking for its rows. Without it, a table answers anyone holding the browser key, which is published in your app and visible to every visitor. With it, the database checks the signed in account against a condition you wrote before it returns a single row. AI builders create tables quickly and often leave the rules for later. Later tends to arrive after launch. The two most expensive failures in the incident library, CVE-2025-48757 and the Moltbook exposure, both come down to rows answering a request that should have been refused. From outside, a check can see whether a table answers the browser key at all. It cannot judge whether each rule is correct. That part is Not verified until a person reads them. ## Security definer https://shipreadyai.dev/glossary/security-definer # Security definer A database function that runs with its author's permissions rather than the caller's. A security definer function runs as whoever created it, not whoever calls it. That is useful and sometimes necessary: a function can check a role without the caller needing permission to read the roles table, which avoids rules that reference themselves in a loop. It is also a hole with a handle on it. Any function marked this way is a path around your row rules, and if it takes an argument that decides which rows it returns, the caller now chooses what to read with the author's permissions. The safe pattern is narrow: no arguments that select rows, a fixed search path, and execute permission granted only to the roles that need it. It is invisible from outside, so it belongs to code review. ## Service role key https://shipreadyai.dev/glossary/service-role-key # Service role key The key that ignores every access rule. It belongs on a server and nowhere else. A service role key is the backend key that bypasses row rules entirely. It exists so your server can do administrative work. Anyone holding it can read and write every row in every table, no matter what your policies say. It belongs in a server secret, read inside server code at the moment it is used. It must never appear in a page, a bundle, a repository, a screenshot or a chat log. Once it is public it is not a leak you can reason about, it is a key change. A check from outside reads your shipped JavaScript and looks for the shape of these keys. That is finding O4. A scan of 5,600 vibe-coded apps found more than 400 exposed secrets, so this is not a rare accident. If one is found, rotate it first and then ask how it got there. ## Slopsquatting https://shipreadyai.dev/glossary/slopsquatting # Slopsquatting Registering the package names AI tools invent, and waiting. Slopsquatting is a supply chain attack aimed at AI coding tools. Models hallucinate package names that sound right and do not exist. Attackers register those names and publish something malicious under them. The next model that suggests the name now suggests a real package, and an agent installs it without pausing. A USENIX study of 2.23 million samples found 19.7 percent referenced a package that did not exist. A campaign in 2026 put 126 malicious packages on npm using exactly this route. Nothing in a URL check can see your dependency tree. The defence is habit: read what your agent adds, check the package has a history and a repository, and use your platform's dependency scan. It belongs on the Release Gate checklist, not on a scan result. ## Source map https://shipreadyai.dev/glossary/source-map # Source map The file that turns your shipped bundle back into readable source. A source map is a companion file that maps compiled JavaScript back to the code you wrote. Browsers use it so a stack trace points at a real line. It is a build tool, not a secret, and in development it is exactly what you want. Published to production, it hands a stranger your file names, your comments, your route structure and every string you left in the code. None of that is a breach on its own. All of it makes finding the real problem faster. A check requests your bundles and looks for the map reference and whether the map itself answers. That is finding O3, and the evidence line names the file. The fix is a build setting, usually one line, and it is the cheapest item on most results. ## SPF https://shipreadyai.dev/glossary/spf # SPF The DNS record naming who is allowed to send email as your domain. SPF is a line in your DNS that lists the services permitted to send mail using your domain. Receiving servers read it and treat mail from anywhere else with suspicion. Without it, two things happen. Your own mail lands in spam, which means the password reset your customer is waiting for never arrives and they leave. And anyone can send mail that appears to come from you, which is the cheapest phishing attack available. A check reads your DNS, so this one is observable from outside and shows up as a finding with the record it found or did not find. Adding it is a DNS edit, usually one line supplied by whichever service sends your mail. Do it before you send anything to a customer. ## Staleness https://shipreadyai.dev/glossary/staleness # Staleness How out of date an observation is, stated rather than hidden. Staleness is the gap between when something was observed and when someone is reading it. Every check result carries its date for this reason, and every statement shows when it was last refreshed. An app that passed a check in March may have lost a header in April during a refactor nobody thought was risky. The observation was true. It stopped being true. Both facts matter to whoever is reading. This is also the argument against badges. A badge is an observation with its date removed, which is exactly the part that decays. A dated line ages honestly: a reader can see it is four months old and decide what that is worth. Release Assurance exists for teams who need that gap kept small. ## Storage bucket https://shipreadyai.dev/glossary/storage-bucket # Storage bucket The place uploaded files live, and the setting that decides who can read them. A storage bucket is the folder your backend keeps uploaded files in: avatars, receipts, exports, whatever your app lets people attach. Each bucket carries one setting that matters more than the rest, which is whether it is public. A public bucket serves any file inside it to anyone who has the address, with no sign in. That is the right answer for a logo and the wrong answer for a scan of someone's passport. The setting gets chosen in the first minute of building the upload feature, when the only thing being tested is whether the image appears, and it is almost never revisited. A check from outside can ask the backend for the list of buckets and read the public flag it publishes. That is names and flags, never the files. What a file contains, and whether it should have been uploaded at all, is a question only you can answer. ## Tenant isolation https://shipreadyai.dev/glossary/tenant-isolation # Tenant isolation One customer's data staying entirely out of another customer's account. Tenant isolation is the guarantee that account A can never see account B's rows, files or activity, whatever it asks for and however it asks. In a multi-customer app it is the promise underneath every other promise. It breaks quietly. A page filters by account correctly while the API behind it does not. A record id in an address can be changed by hand. An export job reads the whole table. The interface looks right the whole time. The Tea app second breach is the plain version: an endpoint returned over a million private messages because nothing checked who was asking. Testing it takes two accounts, two browsers and ten minutes. It cannot be tested from outside, so it stays Not verified on a free result. ## Trust Center https://shipreadyai.dev/glossary/trust-center # Trust Center A published page that answers the security questions buyers ask. A Trust Center is a public page where you put the answers a customer or a platform would otherwise email you for: where data is stored, who can reach it, how you handle a report, what your uptime story is, which third parties are involved. For a small product it is not paperwork for its own sake. It is the page that stops a serious buyer stalling, and it is what a reviewer looks for before they take you seriously. A check looks for the usual addresses and reports whether anything is published there. It cannot judge whether the content is true, only whether it exists. That is honest and it is still useful, because the most common answer is nothing at all. ## Webhook signature https://shipreadyai.dev/glossary/webhook-signature # Webhook signature Proof that the message really came from the service that claims to have sent it. A webhook is a request your app receives from another service. A webhook signature is a value in the headers, computed with a shared secret, that proves the request came from that service and was not changed on the way. Without the check, your endpoint accepts anyone. An address that grants paid access on receipt of a message is a free product for whoever finds the URL, and public endpoints are found. Verifying means recomputing the signature from the raw body and comparing it in a way that does not leak timing. It must happen before you parse anything or write anything. A check from outside cannot see whether you do it, so this stays on the not-verified list until a review reads the handler. ## Free tools https://shipreadyai.dev/tools # Free tools Each tool runs one part of the same engine behind the full Launch Risk Check, with the evidence it was read from. - [Security headers check](https://shipreadyai.dev/tools/security-headers.md): One address, one request, the headers your app actually returns and the ones it does not. - [Source map exposure check](https://shipreadyai.dev/tools/source-maps.md): One address, and the answer to whether your published bundles are shipping your original code. - [Email authentication check](https://shipreadyai.dev/tools/email-authentication.md): One address, and the two DNS records that decide whether your mail is believed. - [Backend exposure test](https://shipreadyai.dev/tools/supabase-exposure.md): One address you own, and a straight answer about what replies to a stranger. - [Package name check](https://shipreadyai.dev/tools/package-check.md): Paste the dependencies your agent added, and see which names do not exist. ## Security headers check https://shipreadyai.dev/tools/security-headers # Security headers check One address, one request, the headers your app actually returns and the ones it does not. Every page your app serves comes with a set of instructions for the browser. They are called response headers, and they decide whether the browser insists on an encrypted connection, whether another site can load your app inside a frame, which scripts are allowed to run, and how much of your address is handed to the next site a visitor clicks through to. None of that is visible on the page. All of it is visible from the outside, which is exactly what this tool reads. This is the gap almost every AI-built app ships with, and the reason is simple. Nobody writes headers. Your framework does not add them, the builder that generated your app does not add them, and your host adds one or two at most. An agent is asked to make a feature work, and a missing header never stops a feature from working. The app looks finished from the inside while the browser is being told nothing at all. What that costs is ordinary rather than dramatic. Without strict transport security, one visitor typing the address on airport wifi gets a plain connection that anybody on that network can read. Without frame protection, your signed-in pages can be loaded invisibly inside someone else's page and clicked on behalf of your users. Without a content policy, a single injected script runs with the same authority as your own code. The tool requests your published address once, records the status and the headers that came back, and reports each one with the evidence line it was read from and the date it was read. Findings that are already in place are shown too, because knowing what is right is part of knowing where you stand. Nothing is written to your app, nothing signs in, and no result here says an app is free of problems. ## Source map exposure check https://shipreadyai.dev/tools/source-maps # Source map exposure check One address, and the answer to whether your published bundles are shipping your original code. When your app is built for production, the readable code you wrote is compressed into something a browser can download quickly and a person can barely read. A source map is the file that reverses that. It maps the compressed bundle back to your original files, with your folder names, your function names, your comments and, often, whole files that were never meant to leave your machine. Source maps exist for a good reason. They make a stack trace in production readable. The problem is that they are on by default while you are building, and turning them off for the published version is a build setting nobody thinks about. An agent optimising for a deploy that works has no reason to touch it, and nothing about your app looks different when the maps ship, which is why so many published AI-built apps are still handing them out. What a reader gets from a published map is the shape of your product. The names of internal routes, the fields you send to your backend, the checks you run on the client, the feature you have not launched yet, and now and then a comment explaining exactly which part is fragile. None of that is a breach on its own. All of it shortens the distance between a curious stranger and a real attempt. This tool fetches the scripts your published page loads, reads the last line of each bundle where the map reference lives, and requests the map only to confirm whether it answers. It reports the file it found, the address of the map and the date it was read. It never stores the contents of your code, and a clean result here is one check out of sixteen, not a verdict on the app. ## Email authentication check https://shipreadyai.dev/tools/email-authentication # Email authentication check One address, and the two DNS records that decide whether your mail is believed. Your app sends mail. A sign in code, a password reset, a receipt. Whether that mail is believed has almost nothing to do with your code and almost everything to do with two records published in the domain name system. SPF lists the servers allowed to send mail for your domain. DMARC tells the receiving side what to do when a message fails that test, and where to report it. This is the one part of a launch that no coding agent will ever fix for you, because it does not live in the repository. It lives with whoever holds your domain. So it gets skipped. The app is finished, the mail provider is connected, the first test message arrives, and the job looks done. Nobody checks what a receiving server thinks of it. The cost shows up in two directions. Outbound, your password reset lands in spam and the person who wanted to use your product quietly leaves. That is the failure you never hear about, and it happens most often on the exact message that matters most. Inbound, a domain with no DMARC policy is a domain anybody can send mail as, which is how a convincing message from your own address reaches your own customers. This tool reads the records published for your domain and reports what is there, what is missing, and what a policy set to none actually means in practice. It reads public DNS only. It does not send mail, does not connect to your mail provider and cannot tell you whether a given message was delivered. That is one check of sixteen, and it is usually the fastest one to fix, because it is a single record and a wait for the change to spread. ## Backend exposure test https://shipreadyai.dev/tools/supabase-exposure # Backend exposure test One address you own, and a straight answer about what replies to a stranger. An AI builder can create a table in seconds. The rule that says who is allowed to read it is a separate step, and it is the step that gets left for later. Meanwhile the browser key your app uses is published inside your app by design. That is not a mistake, it is how the key works. The mistake is a table with no rule behind it, because that table will answer anyone who copies the key out of your page. This is not theory. It is the shape of CVE-2025-48757, which affected a long list of apps built the same way, and it is the shape of the Moltbook exposure, where records were reachable without signing in. In both cases the app worked perfectly for its users the entire time. There is nothing to notice from the inside. A table that answers everybody looks exactly like a table that answers the right people. The tool reads your published page, finds the backend address and the browser key your own app ships, and asks that backend which tables respond to an anonymous request. It reports the number of tables that answered and their names. It never reads the contents of a row, never stores one, and never shows one. A table name is enough to tell you where to look, and it is where the evidence stops. Tables are not the only thing a backend answers for. The same run reads file buckets, asking which ones list their objects to a stranger and whether the first listed object is readable without a session, and it reads your public sign in settings, so you can see whether accounts are open, whether email confirmation is switched off and which providers are enabled. On a Firebase app it asks the same question of the common collections and the configured storage bucket. Every answer is a name and a count. Nothing stored here is a row, a file name or a document. Run this only on an app you own or are authorized to test, which is what the box above the button confirms. A table appearing here does not always mean a problem, because some tables are meant to be public, and this tool cannot know which of yours those are. What it can do is hand you the list, so the answer comes from you rather than from a guess. Nothing is written, nothing signs in and no function on your backend is ever called. ## Package name check https://shipreadyai.dev/tools/package-check # Package name check Paste the dependencies your agent added, and see which names do not exist. A coding agent writes an import line the same way it writes a sentence: by predicting what usually comes next. Most of the time the package it names is real. Sometimes it is not, and the name is a plausible invention that reads exactly like a package you would expect to exist. The code looks finished, the install step is the moment the invention shows up, and by then nobody is reading the output line by line. The pattern has a name, slopsquatting, and it has been measured. A USENIX study of 2.23 million generated code samples found 19.7 percent of them referenced a package that did not exist, and the same invented names come back again and again, which is what makes them worth registering. In February 2026 a campaign of 126 malicious npm packages was published against exactly those names. So the reason this matters is not the failed install. It is what happens when somebody publishes a package under the invented name first, which is cheap to run at scale. From then on the install succeeds, the build is green, and code you never read is running wherever your app runs, with whatever your app can reach. This tool takes text rather than an address. Paste a dependencies block from your package.json, an install command, or one name per line. Every readable name is asked of the public registry once, and the result reports whether a package of that name is published, along with the exact request and the status code that came back. A missing name is not proof of anything except that no package answers to it today. A published name is not proof that the package is safe, only that it exists. What this gives you is the shortest possible way to notice a name nobody has published, before an install command turns it into a decision somebody else gets to make. ## Blog https://shipreadyai.dev/blog # Blog ## The Launch Ledger, 2026 https://shipreadyai.dev/blog/the-launch-ledger-2026 # The Launch Ledger, 2026 Written in September 2026, looking back at the year month by month. Every post is built from published reporting or research and ends with the same two questions. ## Disclaimer https://shipreadyai.dev/what-we-check ShipReady is not a penetration test or a security certification. No automated check can prove an application is secure.