Five Minutes Could Save You From a Breach
You are about to launch your app. You built it with Cursor, Bolt, Lovable, Replit or another AI coding tool. It works. It looks good. Your beta users love it. You are ready to go live.
Stop. Spend five minutes running these 10 checks first. Each one tests for a specific vulnerability that we find in the majority of vibe-coded applications we audit at Sherlock Forensics. Some of these checks will take seconds. Some might ruin your afternoon. Better your afternoon than your users' data.
Check 1: Try .env in Your Browser
What to do: Open your browser and go to yoursite.com/.env.
What bad looks like: A file downloads, or you see text containing database URLs, API keys, JWT secrets or Stripe keys displayed in the browser.
Severity: Critical. Your .env file is the keys to your entire application. If it is accessible, an attacker has your database credentials, payment processing keys, authentication secrets and every other sensitive configuration value. Bots scan for exposed .env files automatically across the entire internet. If yours is accessible, it has likely already been downloaded.
Also try yoursite.com/.env.local, yoursite.com/.env.production and yoursite.com/.env.backup.
Check 2: Check Database File Access
What to do: Try these URLs in your browser: yoursite.com/data/users.txt, yoursite.com/data/users.json, yoursite.com/db/database.sqlite, yoursite.com/database.db.
What bad looks like: A file downloads or you see user data displayed. Any response other than 404 on these paths is a problem.
Severity: Critical. If your user database is downloadable, every credential and piece of personal data in your app is compromised. Read our deep dive on what happens when passwords are stored in text files.
Check 3: Is Your Admin Panel Protected?
What to do: Log out of your app. Then visit yoursite.com/admin, yoursite.com/dashboard and yoursite.com/api/admin/users. Try any admin API endpoints you know about.
What bad looks like: You can see the admin interface or get data back from admin API endpoints without being logged in. Even worse: you can perform admin actions like deleting users or changing settings.
Severity: Critical. AI tools often protect the frontend admin route with a login check but leave the backend API endpoints completely unprotected. The frontend check is cosmetic. The real authorization must happen on the server, on every request, for every endpoint.
Check 4: Is HTTPS Working?
What to do: Visit your site using http:// (not https://). Check if it redirects to HTTPS. Look for a padlock icon in the browser address bar on every page.
What bad looks like: The site loads over HTTP without redirecting. Or the site loads over HTTPS but some resources (images, scripts, API calls) load over HTTP, creating mixed content.
Severity: High. Without HTTPS, login credentials, session tokens and all user data travel across the internet in plaintext. Anyone on the same network can intercept it.
Check 5: Are Passwords Stored in Plaintext?
What to do: Search your codebase for files with names like users, accounts, passwords or credentials. Open them. Look at how passwords are stored. Also check your database directly.
What bad looks like: You can read actual passwords. Whether in a text file, JSON file or database column, if the stored value looks like the password the user typed, it is stored in plaintext.
Severity: Critical. Plaintext passwords mean a single database breach exposes every user's credentials in a format that requires zero effort to exploit. Passwords must be hashed with bcrypt, scrypt or Argon2.
Check 6: Is There Rate Limiting?
What to do: Go to your login page. Enter a wrong password 20 times in a row as fast as you can.
What bad looks like: Nothing stops you. No lockout. No CAPTCHA. No delay. No error saying "too many attempts." You can keep going forever.
Severity: High. Without rate limiting, an attacker can run a brute force attack trying thousands of passwords per second. If any of your users have common passwords (and they do), the attacker will get in. This check takes 30 seconds and tells you immediately whether your login is protected against the most basic attack.
Check 7: Do Errors Show Stack Traces?
What to do: Trigger an error in your app. Try visiting a page that does not exist. Try submitting a form with unexpected data. Try adding a single quote to a URL parameter.
What bad looks like: You see a detailed error message showing file paths, line numbers, database queries, framework versions or code snippets. Messages like "Error in /app/src/controllers/userController.js line 47" or "SequelizeDatabaseError: relation users does not exist."
Severity: Medium. Stack traces give attackers a roadmap of your application. They reveal the framework, database, file structure and sometimes even code logic. Production applications should show a generic error page that reveals nothing about the internal architecture.
Check 8: Test for IDOR (Insecure Direct Object References)
What to do: Log in to your app. Navigate to a page that shows your data, like your profile or a document you own. Look at the URL. If it contains an ID (like /users/42 or /documents/187), change the number and press Enter.
What bad looks like: You see another user's data. You can access their profile, their documents, their settings. You just became them.
Severity: Critical. IDOR is one of the most common and most dangerous vulnerabilities in vibe-coded apps. The AI generated code that fetches data by ID but never checks whether the logged-in user is authorized to access that specific record. This is the number one finding in our AI code audits.
Check 9: Are Password Reset Links Predictable?
What to do: Request two password reset emails. Compare the reset tokens in the URLs. Check whether the tokens are sequential, timestamp-based or otherwise predictable.
What bad looks like: Tokens are short (under 20 characters), sequential (token=1001, token=1002), based on timestamps or based on the user's email/ID. Any pattern an attacker could predict is a failure.
Severity: High. Predictable reset tokens let an attacker generate valid password reset links for any account. They can reset any user's password and take over their account without knowing the original password.
Check 10: Is Your Git Repository Exposed?
What to do: Visit yoursite.com/.git/config in your browser.
What bad looks like: You see git configuration text showing repository URLs, branch names and author information. This means the entire .git directory is accessible.
Severity: Critical. An exposed .git directory lets an attacker reconstruct your complete source code, including every file, every commit and every secret that was ever committed to the repository. Tools like git-dumper automate this process. Within minutes, the attacker has your entire codebase and its full history.
Scoring Your Results
0 failures: Good start. But this checklist covers only the most obvious issues. A professional pentest tests for hundreds more.
1-2 failures: Fix them before you launch. These are specific issues with known solutions. Your AI tool can probably fix them if you describe the problem clearly.
3 or more failures: You need a professional security audit before you launch. These failures indicate systemic security issues throughout your application. Fixing the ones you found will not fix the ones you did not test for. Sherlock Forensics runs penetration tests specifically for vibe-coded apps starting at $1,500.
This checklist is a starting point, not a finish line. It covers what you can test in 5 minutes. A real attacker spends hours. A professional penetration tester spends days. The gap between what you checked and what an attacker checks is where breaches happen.
Not sure if your project warrants a full pentest? Read our guide: Do I Need a Pentest for My Side Project?
Frequently Asked Questions
Is my website ready to launch?
Run all 10 checks in this guide. If you pass all of them, your site meets a baseline security standard. For a complete assessment, get a professional penetration test. This checklist covers the most common issues but a real audit tests for hundreds of additional vulnerabilities.
How do I know if my app is hackable?
If your app was built with AI coding tools and has not been professionally audited, it almost certainly has exploitable vulnerabilities. The 10 checks in this guide test for the most obvious problems. If you fail any of them, your app is hackable. If you pass all of them, there are still likely vulnerabilities that require professional tools and expertise to find.
What security checks should I do before going live?
At minimum: verify .env files are not accessible via browser, confirm HTTPS is configured with redirects, ensure passwords are hashed with bcrypt, test that admin routes require authentication on both frontend and backend, confirm rate limiting on login, check for IDOR by changing IDs in URLs and verify no git repository is exposed. For a thorough audit, contact Sherlock Forensics for a quick audit starting at $1,500.