Test and seed data has been removed

Seed data in a production database creates concrete security vulnerabilities: test accounts with known credentials like test@example.com / password123 become valid login targets. CWE-798 (Use of Hard-coded Credentials) covers this class: any attacker who reads your seed script can authenticate to your production application as any seeded user. Beyond security, contaminated production data produces misleading analytics, corrupted user counts, and phantom records that break business logic assumptions — all problems that compound over time as real user data accumulates alongside test records.

Add a hard production guard to all seed scripts and audit the production database for test entries before launch.

// prisma/seed.ts
if (process.env.NODE_ENV === 'production') {
  console.error('Seed script must not run in production')
  process.exit(1)
}

Remove any package.json scripts that run seed on deploy (e.g., postinstall or vercel-build hooks that call prisma db seed). Query your production database directly for test entries: SELECT email FROM users WHERE email ILIKE '%test%' OR email ILIKE '%example%'. Revoke or delete any seeded API keys or OAuth tokens that exist in the production database.

• ID: pre-launch.final-verification.test-data-removed

• Severity: high

• What to look for: Count all test/seed data references in the codebase. Enumerate any test users, sample data, or seed scripts that could execute in production. Check for database seed files that might have been run and left data: prisma/seed.ts, prisma/seed.js, db/seed.*, scripts/seed.*. Check for test user creation scripts or fixtures. Look for hardcoded test credentials in source code (test@example.com, admin@test.com, password: "test123", etc.). Check for test API calls in component files. Look for TODO comments referencing placeholder or test data left in place.

• Pass criteria: No active seed scripts or test data fixtures that would contaminate a production database. Any seed files present are clearly for development-only use and gated behind environment checks. No more than 0 test data files or seed scripts should be accessible in the production build.

• Fail criteria: Seed scripts that create test users or data without environment guards, hardcoded test credentials in source code, or TODO comments indicating test data was left intentionally for cleanup later.

• Skip (N/A) when: Skip if no database dependency is detected. Signal: no database-related dependencies in package.json.

• Do NOT pass when: Test data exists in the codebase but is "guarded" by an environment check that could fail open (e.g., if (process.env.SEED_DATA) where the variable might accidentally be set).

• Cross-reference: For staging URLs, see staging-urls-removed. For debug mode, see debug-mode-disabled.

• Detail on fail: "Seed scripts or test data found without development-only guards — test accounts and dummy data may be present in the production database"

• Remediation: Seed data in production creates security vulnerabilities (test accounts with known passwords) and data integrity issues:

  // scripts/seed.ts — ensure seed scripts are NOT included in production build
  // Add to .gitignore or use build exclusion in next.config.js
  

  1. Add environment guards to all seed scripts:

     // prisma/seed.ts
     if (process.env.NODE_ENV === 'production') {
       console.error('Seed script should not run in production')
       process.exit(1)
     }
     

  2. Remove or update package.json scripts that auto-run seed on deploy.
  3. Check your production database directly for test entries: email addresses like test@, example.com, or numeric placeholders.
  4. Revoke any test credentials or API keys that might exist in the production database.