Skip to content
BuildThenTestedSee packages
CriticalLogin and permissions

Default admin credentials left in place

Anyone who reads the code or guesses a common placeholder can sign in as the administrator. How the app knows who you are and what you are allowed to do. Check it yourself with the steps below; our test adds what a script and a second account can find.

What it looks like

// prisma/seed.ts
await db.users.create({
  data: {
    email: 'admin@example.com',
    password: await hash('admin123'),
    role: 'admin',
  },
});
// also ran against the production database
A seed script (code that fills a fresh database with starter data) that creates an admin account with a placeholder password, and that also ran against the live database. The same login sits in the repository and, often, in the chat that built it.

What happens

Anyone who reads the code or guesses a common placeholder can sign in as the administrator.

Where it shows up

Descriptive, not a verdict: builders and stacks whose defaults make this reachable, or that a public incident names. Each hub states the tool's own security features.

Check it yourself

Uses your builder's dashboard and your browser. No tools to install.

  1. In the builder's code view, search the whole project for admin@, password, seed and demo.
  2. Try signing in to the live app with any email and password pair you find, and with common placeholders such as admin and password.
  3. In Supabase, open Authentication, then Users; in Firebase, open Authentication. Look for accounts you did not create yourself.
  4. Ask whoever built or deployed the app whether the seed script has ever run against production.

A bad result is a successful sign-in with a password that appears in the code, or an admin account nobody recognises.

What we check

We test the sign-in and every admin endpoint with credentials found in the repository, seed files and example environment files, plus a short list of common defaults. We also check whether admin accounts have multi-factor authentication, and the report lists each account that accepted a known value.

Fix direction

Remove seeded admin accounts from production, give real administrators individual accounts with strong passwords and multi-factor authentication, and keep seed scripts pointed at development only. OWASP lists default accounts with unchanged passwords under Security Misconfiguration.

Mechanism documented in: A05:2021 Security Misconfiguration (verified 2026-09-21); Authentication Cheat Sheet (verified 2026-09-21).

Covered by

Pre-launch check ($490, 48 hours) and Security sweep ($290, 24 hours)

Both include a re-check after your fixes.

Compare packages

Related patterns

  • Admin routes without any login checkLogin and permissions

    A stranger who types /admin or /api/admin into the address bar can see or change everything the owner can.

    Critical
  • Secrets committed to the code repositorySecrets and keys

    Everyone who can see the repository, now or later, holds working keys to the database, payment account and model provider, and the keys stay in history after the file is deleted.

    Critical
  • Role chosen by the client at signupLogin and permissions

    A visitor who edits the signup request, or updates their own profile, can make themselves an admin.

    Critical
  • Every change goes straight to productionDeploy and config

    A broken build, a bad migration or an agent's misjudged edit reaches real users and real data first, with no place where it could have been caught.

    Medium

Questions

how do i find default passwords in my ai generated app

Search the project for admin@, password, seed and demo in the builder's code view, and read any file named seed. Then open your auth provider's user list and look for accounts you did not create. Try each pair you find against the live sign-in; a success means the account is live and the password is public.

is a seeded admin account a security problem

In development, no. In production, yes: the email and password are written in the code, and OWASP's Top Ten list names default accounts with unchanged passwords as a security misconfiguration. Delete the account from production or change its password and add multi-factor authentication, then make sure the seed script runs only against development.

what to do with the admin account the ai created

Check whether it exists in the production user list, then either delete it or reset its password to something unique and turn on multi-factor authentication. OWASP's authentication guidance also warns against letting accounts meant for internal use sign in through the public interface. Give each real administrator their own account so access can be removed per person.

Back to the catalogue, or run the self-check for your stack.