Hardening a vibe-coded prototype before its first real user

Your AI-coded prototype works on your laptop. Before a real user gets a URL, walk through this list. Most items take a minute or two; a few take an afternoon. Every one of them is a bug that ships if you skip it.

Tip: tick items as you complete them — your progress is saved to this browser, so you can come back tomorrow and pick up where you left off.

1. Transport

HTTPS is on, and HTTP redirects to HTTPS.
Free certs from Let's Encrypt or your host. Configure at the web-server / reverse-proxy layer, not the PHP layer. Visit the site over plain HTTP and confirm it 301s to HTTPS.
HSTS header is set.
Strict-Transport-Security: max-age=31536000; includeSubDomains. Start with a shorter max-age (e.g. 86400) for the first week so you have an escape hatch if something breaks.
Mixed content is gone.
Open DevTools → Console on a deployed page. No Mixed Content warnings. Every <script>, <img>, <link>, and fetch() uses https:// or a protocol-relative URL.

2. Sessions & cookies

Session cookie has Secure, HttpOnly, and SameSite set.
session_set_cookie_params(["secure" => true, "httponly" => true, "samesite" => "Lax"]) before session_start(). Verify in DevTools → Application → Cookies — all three flags should be set.
Session ID rotates on login.
session_regenerate_id(true) immediately after a successful login. Otherwise an attacker who set the session ID beforehand keeps it after the user authenticates.
Logout actually logs out.
session_destroy() + clear the session cookie by setting it to an empty value with a past expiry. Hit logout, then back-button — you should not be logged in.
"Remember me" cookies are real CSPRNG tokens, database-backed.
No md5(user_id . secret). Use bin2hex(random_bytes(32)), store the hash server-side, invalidate on logout and password change.

3. Authentication

Passwords are hashed with password_hash(), not encrypted.
password_hash($pw, PASSWORD_DEFAULT) on the way in, password_verify($input, $stored) on the way out. No MD5, no SHA1, no two-way encryption — passwords are one-way.
Login is rate-limited by both IP and email.
Track failed attempts in both dimensions. Throttle after ~5 fails in 15 minutes per identifier. An attacker rotating IPs against one account, or rotating accounts from one IP, should hit a cap.
Password reset doesn't leak whether an account exists.
The response for "we sent a reset email" should be the same regardless of whether the address is in your database. Same response, same timing.
Reset tokens are random, single-use, and time-limited.
bin2hex(random_bytes(32)). Store hashed in the DB. Invalidate after use. Expire in 30–60 minutes.
Every state-changing endpoint checks a CSRF token.
Every POST/PUT/DELETE has a token in the form + hash_equals() on the handler. See the CSRF page if you need the exact pattern.

4. Database

The PHP database user has only the privileges the app needs.
No GRANT ALL. Typically: SELECT, INSERT, UPDATE, DELETE on your app schema only. No DROP, no FILE, no SUPER, no access to mysql.*.
Test data is gone.
Drop the admin/password test accounts. Delete the seed rows from users, permissions, anywhere your AI assistant scaffolded with placeholder data.
You've actually restored from a backup.
A backup you have never restored from is not a backup. Take a backup of your staging DB, drop the DB, restore it, confirm the app still works. Then automate the backup.
Migrations have been run on production exactly once, in order.
No "I edited the schema in phpMyAdmin and it works in staging." Schema changes go through a migration tool or a numbered SQL file checked into git.

5. Headers & output

Security headers are set.
At minimum: X-Content-Type-Options: nosniff, X-Frame-Options: SAMEORIGIN, Referrer-Policy: strict-origin-when-cross-origin. Configure at web-server level so they apply to every response.
Content-Security-Policy is set, even if loose.
Start with something like default-src 'self'; script-src 'self' 'unsafe-inline'; img-src *. Tighten script-src over time. Any CSP is better than none.
Server and X-Powered-By headers are suppressed.
expose_php = Off in php.ini. ServerTokens Prod in Apache, or server_tokens off in nginx. Don't advertise your version to scanners.
Every user-supplied value rendered to a page is escaped.
htmlspecialchars($var, ENT_QUOTES, "UTF-8") for HTML text. safeJsonEncodeForJs($var) (or json_encode with the HEX flags) inside <script> tags. Different contexts need different escapers.

6. Production hygiene

display_errors is off in production.
ini_set("display_errors", "0"), error_reporting(0) in your production bootstrap. Errors go to error_log only, never to the response. A stack trace on a 500 leaks file paths, line numbers, and database schemas.
No secrets are in source.
Run gitleaks detect --source . against the working tree and gitleaks detect --no-git against checked-out history. Any hits → rotate the key, don't just scrub the file.
Composer dependencies have no known CVEs.
composer audit (PHP 8.1+) or trivy fs ./composer.lock. Read each finding before updating blindly — sometimes the CVE doesn't affect your use case, but you should know which findings you're accepting.
File uploads are restricted by type and size.
Don't trust the client's Content-Type. Server-side: check the actual MIME via finfo_file(), cap the size in upload_max_filesize, store outside the webroot, serve via a PHP handler that re-checks auth.
Verbose logging is on for security-relevant actions.
Login attempts (success and fail), password changes, admin actions, permission grants, account deletions. Include user ID, IP, timestamp. Future-you will need this when something goes wrong.

7. Pre-launch verification

A scanner has been run against staging.
At minimum, ZAP's "quick" profile against a deployed copy. The Security Scanner runs ZAP plus six other tools in Docker. Either path, the goal is "we have read the report and triaged or accepted every finding."
A second pair of eyes has reviewed the diff.
Either a human (a teammate, a contractor, a friend you trust) or a fresh AI session prompted to look for security issues with a checklist. Different priors, different things noticed.
You have a rollback plan.
Tagged release on the previous version, snapshot of the DB taken right before deploy, documented "how do we revert" steps. The plan doesn't have to be elegant — it has to exist.
You know who is on call for the first 24 hours.
Could be just you. But explicitly. "If alerts fire at 2am, the person fixing it is X." Better still — a way for early users to reach you when something's wrong (an email address that resolves, a status page).

That's the list. Going from zero to all of these checked is what separates a prototype from a real product. None of these items are individually hard. The trick is doing all of them before the launch, not after the first incident.

Want us to do the pass for you?

If you'd rather have us work through the list against your specific stack and send back a list of what we changed (or what you still need to do), send the staging URL or repo below.