Vibe Coding prompt of the day

Pre-launch security sweep for a non-engineer: keys, open endpoints, unprotected pages

You built it with AI help and you're about to put it in front of real people. Run the leaked-key, open-endpoint and unprotected-page checks an engineer would run first — as steps you can actually perform, where nothing counts as found or fixed until you've reproduced it.

You are a security reviewer walking a non-engineer through a pre-launch sweep of an app they built with AI assistance. I will tell you what the app is, what it is built on, and where it is hosted. Assume I cannot read code fluently: every check has to be something I can actually perform and see the result of.

Produce:

A) WHAT THIS APP CAN LOSE — before any checks, in plain language: what data it holds, who would want it, and the worst realistic outcome (someone reads another user's records, someone runs up a bill on my API key, someone defaces the site). This orders everything below. A sweep with no threat model checks whatever is easiest.

B) THE SECRET SWEEP — step by step, how to find credentials that have escaped: keys committed to the repository INCLUDING ITS HISTORY, not just the current files; keys shipped to the browser in client-side code or in environment variables exposed to the front end; keys sitting in logs, screenshots or a public deployment. For each: exactly where to look and what a hit looks like. State plainly that a key which was ever committed must be ROTATED, not deleted — removing it from today's file leaves it in the history and in every clone.

C) THE ENDPOINT SWEEP — how to list what my app actually exposes (routes, API endpoints, serverless functions, storage buckets, database access rules) and, for each, the test that shows whether it can be reached without logging in. Give me the literal steps: what to open, what to send, and which response means "open". Include the two that non-engineers miss most — an endpoint that checks who I am in the interface but not on the server, and a record ID in a URL that I can change to see someone else's data.

D) THE UNPROTECTED PAGE SWEEP — how to confirm that pages behind a login actually are: log out or open a private window, visit each URL directly, and see what renders. Cover admin routes, draft/preview URLs, and anything reachable by guessing a predictable path.

E) FINDINGS TABLE — for each finding: what I OBSERVED (the literal response, not your interpretation of it), how bad it is given (A), and the fix. Sorted by severity.

F) VERIFY EACH FINDING — the rule that governs the whole sweep. Nothing counts as FOUND until I have reproduced it myself and shown you the actual output, and nothing counts as FIXED until I have re-run that same check and shown you the new result. Do not mark anything resolved on my say-so or on your own reading of the code. Give the exact re-test for every fix. If a check cannot be completed, the finding is UNKNOWN — never "clear".

G) WHAT THIS SWEEP DOES NOT COVER — the classes of problem these checks cannot catch and what would be needed instead, so that a clean result is not read as a secure application.

Inputs: [WHAT THE APP DOES AND WHAT DATA IT HOLDS] · [STACK AND HOSTING] · [HOW LOGIN AND PERMISSIONS WORK, AS FAR AS I KNOW] · [WHAT IS PUBLIC VERSUS BEHIND A LOGIN] · [WHERE THE CODE LIVES AND WHETHER THAT REPOSITORY IS PUBLIC]

Rules: Do not invent vulnerabilities, CVE numbers, filenames or configuration options you have not been shown — a fabricated finding sends me to fix something that does not exist while a real one ships. Do not tell me the app is secure; tell me which check passed, and what that does and does not prove. Only test systems I own. Do not paste real secrets, customer records, confidential material or personal identifiers into this chat — describe them, redact them, or use a masked sample. If a step needs a tool I do not have, say so and give me an alternative I can actually run.

Why it works — The three checks here are the ones that account for most of what goes wrong on a first launch, and all three are observable from outside the code — which is what makes them runnable by someone who cannot audit a codebase. The load-bearing part is the verification rule: an assistant asked to review security will confidently declare an endpoint protected because the code looks like it should be, and that same confidence then declares it fixed. Requiring a reproduced observation before FOUND and a re-run of the identical check before FIXED, with UNKNOWN as a permitted third answer, is what stops a security review from becoming a reassurance generator. The threat model comes first so the sweep is ordered by what this specific app can actually lose, and the closing scope section exists so a clean sheet is not mistaken for a secure application.