Base44 builds the whole app for you: pages, data, logins and hosting, all on Base44's own back end. That means fewer moving parts than many AI builders, and fewer places for keys to leak. But the most important security decisions are still yours.

Base44's security overview says it directly: "You are responsible for your app's security settings." This checklist, written for founders rather than security experts, covers what to check.

1. Data permissions (the most important part)

Base44 stores your app's data as entities, a bit like tables, and each one has permissions for who can create, read, update and delete records. Base44 says it "automatically sets up data permissions as you build your app", and warns: "If permissions are not set up correctly, the wrong people could view or change data in your app."

• Open the security settings for every entity that holds user data. Look for "All Users" on read, update or delete. Base44 explains that it means anyone can do it, "even without signing in."
• Make sure each person sees only their own records, such as their own orders or messages, unless sharing is intended.
• Check sensitive fields too. Base44 supports field-level rules, so a record can be visible while a private field in it isn't.
• Do the two-account test. Sign up as user A and create something. Log in as user B in another browser and try to see or change A's data.

2. Who can open your app

A Base44 app can be Public (anyone on the internet, no sign-in), Private (only invited people) or limited to your workspace. Base44's access docs note that apps that look like public sites, such as landing pages, are set to Public automatically, and that making an app private needs a Starter plan or higher.

Check the setting matches what the app is for. An internal tool or a client portal shouldn't be open to everyone.

3. Logins and roles

• Base44 apps have two built-in roles: Admin and User. Check who has Admin, and that admin-only pages and data are restricted by permissions, not just hidden.
• Pick sign-in options that fit your users, and require multi-factor authentication for admins if your plan allows it (Base44 says requiring MFA needs a Builder plan or higher).

4. Secrets and backend functions

• Store API keys in Base44's secrets, which Base44 says are "only accessible from your app's backend and are never exposed to the people using your app." Never paste a key into page code or a prompt that puts it in the front end.
• Backend functions should check who is calling before doing anything user-specific.
• Be careful with the service role. Base44's developer docs say code using asServiceRole "bypasses both RLS and FLS entirely", so every function that uses it must do its own checks.
• Rate limits or credit limits on anything that costs you money, like AI calls.

5. Payments

• If you take payments with Stripe, webhooks must verify the signature (Stripe's docs).
• Paid features are unlocked by data the user can't change, checked by permissions or a backend function.

6. Run Base44's security scan

Base44 has a built-in security scan on every plan, including free. It looks at permissions, private fields, exposed secrets, backend functions, dependencies and security headers. Run it before you publish and after big changes.

Two things to know. First, "the scan doesn't apply fixes automatically, so check what each fix changes first." Second, it can't know your business rules: whether a manager should see another team's records, or whether a field is private. That's what the two-account test and a human review are for.

7. Platform issues happen too

In July 2025, security firm Wiz reported a flaw that let anyone register for private Base44 apps using only the app's id. It was fixed in less than 24 hours, and Base44 said that, so far, it had found no evidence that any customer was affected. It's a reminder that security depends on both the platform and your own settings. Wiz suggested app owners review their app's analytics for unusual visits and sign-ups.

8. Where to start

If you only have an hour: run Base44's security scan, check every entity for "All Users" permissions on private data, and do the two-account test.

Want a second pair of eyes?

Axieo Guard is our security audit for AI-built apps, including apps built with Base44. A free mini scan checks five high-impact items. A full audit covers 25 checks, adapted to Base44's back end, with a plain-English report and a recommended fix for every finding. We're a Canadian company, and we only test with your written permission, read-only. Get a free mini scan.

v0 by Vercel builds Next.js apps and deploys them to Vercel in a few clicks. Next.js is a mature framework with good security tools. But generated code still has to use those tools correctly, and some of the most important checks are easy to leave out.

This checklist is written for founders, not security experts. Each item explains what to look for in a v0 app and why it matters.

1. How a v0 app is put together

A v0 app is a Next.js app. Some of its code runs in your visitors' browsers and some runs on Vercel's servers: pages rendered on the server, route handlers (your API) and Server Actions (functions the browser can call). Data usually lives in a connected database such as Supabase or Neon, which v0 integrates with.

The key question for every piece of code is: does it run on the server or in the browser? Anything in the browser can be read and changed by anyone.

2. Secret keys and NEXT_PUBLIC_

Next.js's docs explain the rule: "By default, environment variables are only available on the server. To expose an environment variable to the browser, it must be prefixed with NEXT_PUBLIC_."

• List every NEXT_PUBLIC_ variable. Each one is public. A Stripe secret key, an AI provider key or a database admin key must never have that prefix. v0's security docs say the same: "Never expose sensitive tokens with NEXT_PUBLIC_ prefix".
• Store secrets in Vercel's environment variables, and use the Secret type for the most sensitive ones: Vercel says Secret values "are write-only after saving".
• If the project syncs to GitHub, check that no .env file or key was ever committed. If a secret was ever exposed, rotate it.

3. Server Actions and API routes check the user

This is the most common gap in Next.js apps. Next.js's authentication guide says: "Treat Server Actions with the same security considerations as public-facing API endpoints, and verify if the user is allowed to perform a mutation." The same applies to route handlers.

• Every Server Action and route handler checks the session itself. Next.js's data security guide warns that "a page-level authentication check does not extend to the Server Actions defined within it."
• Don't rely only on proxy (formerly called middleware) for protection. Next.js says it "should not be your only line of defense in protecting your data."
• Check authorization, not just login: is this user allowed to read or change this specific record?
• Admin features check the role on the server, not just in the page layout.

Why the warning about middleware? In 2025, a vulnerability (CVE-2025-29927) let attackers skip Next.js middleware on self-hosted apps. Vercel's postmortem says apps hosted on Vercel weren't vulnerable, and fixed versions were released (Next.js 14.2.25 and 15.2.3). Its advice still holds for everyone: "We do not recommend Middleware to be the sole method of protecting routes in your application." Keep Next.js up to date.

4. Database rules

• If your app uses Supabase from the browser, Row Level Security must be on for every table, with rules that limit each user to their own rows. Supabase's docs: "Enable RLS on every table in an exposed schema."
• If your app reaches the database only from server code, each query must filter by the logged-in user.
• Do the two-account test. Sign in as user A and create something. Sign in as user B in another browser and try to see or change it.

5. Deployments and headers

• Know what's public. Vercel's Standard Deployment Protection "protects all deployments except production domains". Your production site is public, which is what you want, so anything unfinished must be protected by your own login.
• Add security headers (HSTS, a Content-Security-Policy or frame-ancestors, X-Content-Type-Options: nosniff) with headers() in your Next.js config. Next.js's headers docs have examples.
• Run npm audit for known-vulnerable packages.

6. Payments and abuse

• Stripe webhooks verify the signature (Stripe's docs), and prices and paid features are checked on the server.
• Rate limits on sign-up, login and AI calls, so one script can't run up your bill.

7. What v0 does for you

v0's security docs say it "analyzes NEXT_PUBLIC_ usage and warns users about potential security risks". Take those warnings seriously. When v0 is connected to GitHub, it opens a pull request for its changes instead of pushing straight to your base branch, which gives you a natural moment to review what changed, especially in auth and data code.

What no tool can know is your business rules: who should see which records, and which actions need which role. That's what the server-side checks and the two-account test are for.

8. Where to start

If you only have an hour: list your NEXT_PUBLIC_ variables, open every Server Action and route handler and confirm each one checks the user, and do the two-account test.

Want a second pair of eyes?

Axieo Guard is our security audit for AI-built apps, including apps built with v0. A free mini scan checks five high-impact items, including exposed keys and open database tables. A full audit covers 25 checks, with a plain-English report and a recommended fix for every finding. We're a Canadian company, and we only test with your written permission, read-only. Get a free mini scan.

Replit Agent can build and publish a full-stack app, with a server, a database and logins, from a conversation. Replit is also unusually clear about who is responsible for what happens next.

Its shared responsibility page says: "You own the code Agent generates and you're responsible for it." Replit secures the platform. Your app's code, settings and data rules are yours, and the page lists security testing of the app you build as your job.

This checklist is written for founders, not security experts. Here's what to check before real users arrive.

1. How a Replit app is different

Many AI builders put the database directly behind the browser and protect it with database rules. A typical Replit Agent app is different: it has its own server, written in a language like JavaScript or Python, and the server talks to a PostgreSQL database.

That changes where security lives. There's usually no database rule to fall back on. Every page and API route on your server has to check who is asking and what they're allowed to see.

2. Check the login on the server, every time

Replit's own guidance for Replit Auth is: "Always validate user authentication server-side before performing sensitive operations."

• Every API route that reads or changes user data checks the logged-in user first, not just the pages that show the data.
• Queries filter by the logged-in user's id, so user A can't load user B's records by changing a number in the URL.
• Admin routes check the role on the server. Hiding the admin button isn't protection.
• Do the two-account test. Sign in as user A and create something. Sign in as user B in another browser and try to open A's record by its address or id.

3. Secrets stay on the server

Replit's security checklist says to "use Replit Secrets to store sensitive information like API keys" and that "API credentials should always remain server-side".

• No keys written directly in the code, especially if the project is ever shared or public.
• No secret reaches the browser. Search your front-end code and the page source of the live app for sk_live, sk- and whsec_.
• If a key was ever exposed, rotate it.

4. The production database

Replit gives every app two databases. Its docs explain: "Your published app gets its own production database, separate from the development database you use while building." That's good: you can test without touching real users' data.

• Never copy real customer data into the development database to test something.
• Check how backups work for production, and that you know how to restore one.
• Build queries with parameters, never by pasting user input into SQL text.

5. Who can open your app

Apps in a personal Replit workspace default to Public: "Anyone on the internet with the URL can use your app." That's what you want for a launch. It's not what you want for an internal tool or an unfinished admin dashboard, so check the setting.

6. Payments and abuse

• Stripe webhooks verify the signature (Stripe's docs), and paid features are checked on the server.
• Rate limits on sign-up, login and anything that costs you money, like AI calls. Without them, one script can run up your bill overnight.
• Basic security headers, and npm audit (or your language's equivalent) for known-vulnerable packages.

7. Use Replit's own security scans

Replit scans your dependencies against public vulnerability records, reviews the files Agent changes "for common insecure patterns and hardcoded secrets", and runs a security scan before publishing. Use all of it.

Replit also describes these automatic checks as ones that "complement, rather than replace, a full Agent security scan". And no scanner can know your business rules: that a customer shouldn't see another customer's invoices, or that only managers may change prices. That's what the server-side checks and the two-account test are for.

8. Where to start

If you only have an hour: run Replit's security scan, list every API route and confirm each one checks the logged-in user, and do the two-account test.

Want a second pair of eyes?

Axieo Guard is our security audit for AI-built apps, including apps built with Replit. A free mini scan checks five high-impact items, including exposed keys. A full audit covers 25 checks, translated to your server and database, with a plain-English report and a recommended fix for every finding. We're a Canadian company, and we only test with your written permission, read-only. Get a free mini scan.

Bolt.new can turn a prompt into a working app with a database, logins and hosting in an afternoon. That speed is the point. But an app that works in the demo isn't automatically safe with real users, and the gaps are usually in the parts you never asked for.

This checklist is written for founders, not security experts. It covers what Bolt checks for you, what it doesn't, and what to test yourself before you share the link.

1. How a Bolt app is put together

Most Bolt apps have a front end that runs in your visitors' browsers and a database behind it. Bolt's docs say "every Bolt project can have a built-in database", and on Pro or Teams plans you can choose Supabase instead when you create the project.

Either way, the database is protected by Row Level Security (RLS): rules that decide who can read and change each row. Bolt's database security page puts it plainly: "A table without RLS can be read and changed by anyone."

2. Database rules (the most important part)

Bolt "turns on RLS for the tables it creates". That's a good start, but turned on isn't the same as correct. Bolt's docs also say that for apps without sign-in, it "might write policies that allow any visitor to view, add, change, and delete the data in your database."

• Open the Security tab and look for the RLS Policy Always True warning. Bolt says this tab "uses the same database checks as the Security Advisor in Supabase". An always-true rule on user data means anyone can read or change it.
• Check tables you or your team added later, outside Bolt. Every table needs RLS.
• Do the two-account test. Sign up as user A and create something. Log in as user B in another browser and try to see or change A's data. If you can, the rules need to compare the logged-in user with the row's owner.
• Keep private files in private storage. ID scans, invoices and contracts shouldn't be in a public bucket.

3. Secret keys

Bolt apps are usually built with Vite, and Vite's docs are clear: "VITE_* variables should not contain sensitive information such as API keys." Every VITE_ value ends up in the browser, where anyone can read it.

• Only public values in VITE_ variables: your database URL and the publishable (anon) key. Never a Stripe secret key, an AI provider key or a database admin key.
• Keep real secrets in Bolt's Secrets settings and use them only in server-side code.
• If your project syncs to GitHub, check that no .env file or key was ever committed. Deleting it later doesn't remove it from git history. If a secret was ever exposed, rotate it.

4. Logins and admin pages

• Admin pages must be protected by the database and the server, not just hidden in the menu. Anyone can open the browser's developer tools.
• Roles such as "admin" must not live in a field users can edit on their own profile.
• Email confirmation on, sensible password rules, and redirect URLs limited to your own domains.

5. Payments

• Stripe webhooks must verify the signature, or anyone can send a fake "payment succeeded". See Stripe's webhook docs.
• Prices and paid features are checked on the server. If the browser decides what's unlocked, people can unlock it themselves.

6. Hosting

Bolt can publish your app to an address ending in bolt.host, or you can deploy elsewhere. If you use Netlify, note that Bolt's Netlify page says it "can't host a database or a traditional backend", so make sure every server-side check still runs somewhere secure.

• HTTPS only, plus basic security headers (a Content-Security-Policy and clickjacking protection).
• Run npm audit for known-vulnerable packages.
• Separate test data from real users' data, and know how you'd restore a backup.

7. Use Bolt's own security tools first

Bolt has a database check on all plans and a fuller project security audit on paid plans. Bolt's security docs suggest running the audit "at least once before you publish". It checks, among other things, that "private keys and passwords aren't stored in your project's code or sent to visitors' browsers."

Run it, and review every change it proposes before you accept it. A tool can only check what it was designed to check. It can't know that a table was meant to be private, or that a manager shouldn't see another team's data. That's what the two-account test and a human review are for.

8. Where to start

If you only have an hour: run Bolt's database check and fix every RLS Policy Always True warning on user data, search your code for secret keys, and do the two-account test. Our free 10-point security self-check walks through these for Supabase-style databases, with where to click.

Want a second pair of eyes?

Axieo Guard is our security audit for AI-built apps, including apps built with Bolt.new. A free mini scan checks five high-impact items, including exposed keys and open database tables. A full audit covers 25 checks, with a plain-English report and a recommended fix for every finding. We're a Canadian company, and we only test with your written permission, read-only. Get a free mini scan.