Quick answer

Before you launch a vibe-coded app, run six AI security checks: API rate limits, input validation, hardcoded API keys, dependency vulnerabilities, error handling leaks, and file upload security. This prompt pack tells an AI exactly what to hunt for, how to rank findings, and how to fix them.

Innovorus is an all-in-one digital business platform. Students learn from expert courses, freelancers and teams deliver real client work, teachers publish programs, agencies grow services, influencers collaborate, and affiliates earn by sharing what works, under one trusted brand.

Explore courses and creator tools at https://www.innovorus.com/courses or create a free account at https://www.innovorus.com.

6 Security Checks Before You Launch prompt pack cover

How to use this prompt pack

Open your project in an AI tool that can read your code (Claude Code, Cursor, Codex, Copilot Chat). If you only have a chat window, paste the relevant files with the prompt.
Copy a check prompt below and paste it in. Fill in the bracketed [STACK] line first (for example: Next.js, Supabase, Stripe, Vercel).
Let the AI report first. Read the findings before you approve any code changes.
Fix, then run the same prompt again. Repeat until it reports nothing above Low severity.

Checklist overview

1. API rate limits
2. Input validation
3. Hardcoded API keys
4. Dependency vulnerabilities
5. Error handling and information leakage
6. File upload security

1. API rate limits

Without limits, one script can brute-force logins, scrape your data, or run up your AI bill overnight. Different endpoints need different limits, so this prompt maps them all first.

rate-limits.prompt

You are a senior application security engineer. Audit the API rate limiting of this project.

MY STACK: [STACK]

STEP 1: INVENTORY
Find every endpoint that accepts requests: REST routes, GraphQL operations, server actions, API routes, webhooks, serverless and edge functions, websockets. For each one record: method, path, purpose, whether auth is required, and which category it belongs to:
- Public read
- Authenticated read
- Write / mutation
- Login, signup, password reset, OTP, email verification
- Expensive (calls an AI model, sends email or SMS, uses a paid third-party API, generates files)
- Admin or internal

STEP 2: CURRENT STATE
For each endpoint, tell me whether any rate limit exists today, what it is, and whether it can be bypassed. Check specifically for:
- Limits keyed only on IP where the app sits behind a proxy (spoofable X-Forwarded-For)
- Limits that reset on every deploy or cold start (in-memory counters in serverless)
- Limits per IP only, so an attacker can rotate IPs or create many accounts
- No request body size limit, no pagination cap, no GraphQL depth or complexity limit
- No lockout or slowdown on repeated failed logins

STEP 3: RECOMMENDED LIMITS
Give me a table: endpoint category, recommended limit (requests per window), the key to count on (IP, user ID, API key, or a combination), the algorithm (fixed window, sliding window, or token bucket), and your reasoning. Be stricter for authentication and expensive endpoints. Mention the cost or abuse scenario each limit prevents.

STEP 4: IMPLEMENTATION PLAN
Propose the smallest clean way to add this: one shared middleware or helper, a storage backend that works for my hosting, standard 429 responses with a Retry-After header, and logging of blocked requests. List every file you would touch. Make sure legitimate users are not broken (for example, do not rate limit health checks or static assets).
OUTPUT FORMAT
1. Start with a short summary: how many findings per severity (Critical / High / Medium / Low).
2. Then a findings table. For each finding give: ID, severity, file and line, what is wrong, how an attacker would exploit it in practice, and the exact fix.
3. Do NOT change any code yet. Wait for me to reply with the finding IDs to fix.
4. If you are not sure about something, say so and tell me how to verify it. Do not guess or invent details.

Tip: Serverless hosting (Vercel, Netlify, Cloudflare)? Say so in the stack line. In-memory counters do not work there, and the AI should use a shared store like Redis or Upstash.

2. Input validation

Most injection and data-exposure bugs start with one field nobody validated. Every input must be checked on the server for length, characters, and expected type.

input-validation.prompt

You are a senior application security engineer. Audit input validation across this entire project.

MY STACK: [STACK]

STEP 1: FIND EVERY ENTRY POINT
List every place data enters the system: request bodies, query strings, path parameters, headers, cookies, form fields, webhook payloads, file names and metadata, URL parameters that get fetched or redirected to, and responses from third-party APIs that the app trusts.

STEP 2: VALIDATION MATRIX
For each input, tell me whether the SERVER validates all of these, and what is missing:
- Expected type (string, number, boolean, array, enum)
- Minimum and maximum length or size
- Allowed characters or format (use allowlists, not blocklists)
- Numeric range (negative numbers, zero, huge values, overflow)
- Required vs optional, and rejection of unknown extra fields (mass assignment)
- Normalisation (trimming, unicode normalisation, case)

STEP 3: ATTACK CLASS CHECKLIST
Check the code specifically for each of the following and point to the exact lines:
- SQL injection (string-built queries instead of parameterised ones) and NoSQL injection (operators like $ne or $gt passed through from user JSON)
- Cross-site scripting (unescaped output, dangerouslySetInnerHTML, innerHTML, unsafe markdown rendering)
- Command injection and unsafe use of eval, exec, or shell calls
- Path traversal (user input inside file paths)
- Server-side request forgery (the server fetching a URL the user supplied, including internal IPs and cloud metadata addresses)
- Open redirects
- Insecure direct object references (a user changing an ID in the request to read or edit someone else's data)
- Prototype pollution and regular expressions vulnerable to catastrophic backtracking

STEP 4: FIX PLAN
Recommend one schema-validation approach that fits my stack (for example Zod, Joi, Pydantic, or class-validator) and show how a validation layer would sit in front of every route. Give me a sample schema for the two riskiest endpoints you found.
OUTPUT FORMAT
1. Start with a short summary: how many findings per severity (Critical / High / Medium / Low).
2. Then a findings table. For each finding give: ID, severity, file and line, what is wrong, how an attacker would exploit it in practice, and the exact fix.
3. Do NOT change any code yet. Wait for me to reply with the finding IDs to fix.
4. If you are not sure about something, say so and tell me how to verify it. Do not guess or invent details.

Tip: Client-side validation is for user experience only. This prompt checks that the server enforces everything, because attackers skip your frontend completely.

3. Hardcoded API keys

AI agents often paste a real key into the code while testing, then forget it. One leaked key can mean stolen data or a huge bill within hours.

hardcoded-keys.prompt

You are a senior application security engineer specialising in secrets management. Scan this entire project for exposed credentials.

MY STACK: [STACK]

STEP 1: WHERE TO LOOK
Search everything, not just source files: application code, config files, .env and .env.* files (and whether they are committed), Dockerfiles and docker-compose, CI/CD workflows, test files, seed scripts, README and docs, code comments, notebooks, mobile app bundles, and any built or bundled frontend output.

STEP 2: WHAT TO LOOK FOR
- Known key formats: sk-..., sk_live_..., AKIA..., ghp_..., AIza..., xoxb-..., service_role keys, private key blocks (BEGIN PRIVATE KEY), JWTs, bearer tokens
- Database connection strings that include a password
- Webhook signing secrets, OAuth client secrets, SMTP passwords
- Any secret placed in a variable that gets shipped to the browser (NEXT_PUBLIC_, VITE_, REACT_APP_ prefixes, or values used in client components)
- Admin or service-level keys used where a limited public key would do
- Secrets written to logs, error messages, or analytics

STEP 3: GIT HISTORY
Check git history as well, not only the current files. Tell me the commands to run (for example gitleaks or trufflehog, or git log -p searches) and how to read the result.

STEP 4: REPORT
For each finding give: file and line, secret type, whether it looks live or a placeholder, and the blast radius if abused. IMPORTANT: mask every secret in your report (show only the first 4 characters). Never print a full key.

STEP 5: REMEDIATION PLAN
Give me the correct order of operations: (1) rotate or revoke the exposed key immediately and assume it is compromised, (2) move it to environment variables or a secrets manager, (3) remove it from git history, (4) make sure .env is in .gitignore and provide a .env.example with placeholder values only, (5) reduce each key to least privilege, (6) add a pre-commit hook and a CI job that blocks new secrets from being committed.
OUTPUT FORMAT
1. Start with a short summary: how many findings per severity (Critical / High / Medium / Low).
2. Then a findings table. For each finding give: ID, severity, file and line, what is wrong, how an attacker would exploit it in practice, and the exact fix.
3. Do NOT change any code yet. Wait for me to reply with the finding IDs to fix.
4. If you are not sure about something, say so and tell me how to verify it. Do not guess or invent details.

Tip: If this check finds a live key, rotate it first. Removing it from the code is not enough, because it stays in your git history and may already have been copied.

4. Dependency vulnerabilities

Your app is mostly other people's code. An outdated or malicious package is one of the easiest ways in, and AI tools sometimes suggest packages that do not exist or are fake copies of real ones.

dependencies.prompt

You are a senior application security engineer. Audit the third-party dependencies of this project.

MY STACK: [STACK]

STEP 1: INVENTORY
Find every dependency manifest and lockfile (package.json, package-lock.json, yarn.lock, pnpm-lock.yaml, requirements.txt, poetry.lock, Pipfile, go.mod, Gemfile, composer.json, pom.xml, Cargo.toml and so on). List direct and transitive dependencies, and note the runtime version (Node, Python, etc.) and base Docker images.

STEP 2: SCAN
Tell me the exact commands to run for my ecosystem (for example npm audit, pip-audit, osv-scanner, trivy) and run them if you can. Then interpret the results for THIS app: is the vulnerable code path actually reachable, or is it a dev-only dependency? Rank by real risk, not just by score.

STEP 3: SUPPLY CHAIN RED FLAGS
Check for and flag:
- Packages that look like typo-squats or lookalikes of popular libraries
- Packages that may not exist or were suggested by an AI and never verified (hallucinated package names)
- Abandoned, deprecated, or archived packages with no recent maintenance
- Packages with install scripts that run code during installation
- Loose version ranges (^, *, latest) with no lockfile committed
- Unused dependencies that should simply be removed
- Outdated third-party SDKs and API versions, and CDN scripts loaded without integrity (SRI) hashes

STEP 4: UPGRADE PLAN
For each issue give the safest fixed version, warn about breaking changes, and order the upgrades so I can test between steps. Do not invent CVE numbers or version numbers. If you cannot verify one, say 'verify this' and tell me where to check.

STEP 5: AUTOMATION
Propose a setup that keeps this clean: Dependabot or Renovate configuration, a scheduled daily vulnerability scan in CI, and a rule that fails the build on High or Critical findings.
OUTPUT FORMAT
1. Start with a short summary: how many findings per severity (Critical / High / Medium / Low).
2. Then a findings table. For each finding give: ID, severity, file and line, what is wrong, how an attacker would exploit it in practice, and the exact fix.
3. Do NOT change any code yet. Wait for me to reply with the finding IDs to fix.
4. If you are not sure about something, say so and tell me how to verify it. Do not guess or invent details.

Tip: For ongoing protection, ask the AI to also set up Dependabot or Renovate and a daily CI scan, as the last step of this prompt describes.

5. Error handling and information leakage

A helpful error message for you is a map of your system for an attacker: file paths, database names, library versions, and whether an email is registered.

error-handling.prompt

You are a senior application security engineer. Audit how this project handles errors, logging, and debug output, and what it reveals to outsiders.

MY STACK: [STACK]

STEP 1: WHAT THE OUTSIDE WORLD CAN SEE
Review every error path and tell me whether any of these can reach a user or an API response in production:
- Stack traces, file paths, or line numbers
- Raw database errors (table names, column names, SQL text)
- Framework or server version banners and headers such as X-Powered-By
- Debug mode or verbose mode left on in production
- Source maps published with the production build
- Internal hostnames, IP addresses, or environment details
- Public debug, health, admin, docs, or GraphQL introspection endpoints that expose more than intended

STEP 2: ACCOUNT AND RESOURCE ENUMERATION
Check whether responses or timing differ in ways that let an attacker learn who has an account or what exists:
- 'Email not found' vs 'wrong password'
- Password reset and signup responses that confirm whether an email is registered
- 403 vs 404 for resources the user should not know about
- Noticeably different response times for valid vs invalid users

STEP 3: LOGGING
Check that logs never contain passwords, tokens, API keys, session IDs, full card numbers, or unnecessary personal data. Check for console.log leftovers in production code. Check that logs are not publicly accessible.

STEP 4: FAIL-SAFE BEHAVIOUR
Check that errors fail closed: if an authentication or permission check throws an error, access must be denied, not granted. Look for empty catch blocks, swallowed exceptions, and unhandled promise rejections.

STEP 5: FIX PLAN
Propose one global error handler that returns a generic message plus a correlation ID to the user, logs full details privately with sensitive fields redacted, and adds custom 404 and 500 pages. Include recommended security headers.
OUTPUT FORMAT
1. Start with a short summary: how many findings per severity (Critical / High / Medium / Low).
2. Then a findings table. For each finding give: ID, severity, file and line, what is wrong, how an attacker would exploit it in practice, and the exact fix.
3. Do NOT change any code yet. Wait for me to reply with the finding IDs to fix.
4. If you are not sure about something, say so and tell me how to verify it. Do not guess or invent details.

Tip: The rule to remember: the user sees a short generic message and a reference ID, and the full detail goes only to your private logs.

6. File upload security

The most overlooked and most dangerous one. If uploads are not locked down, an attacker can upload a malicious file, get it executed, and take over your server and database.

file-upload.prompt

You are a senior application security engineer specialising in file upload attacks. Audit every way this project accepts, stores, processes, and serves user-provided files.

MY STACK: [STACK]

STEP 1: FIND ALL UPLOAD PATHS
List every feature that takes a file or file-like content: avatars, attachments, document or CSV import, image processing, zip extraction, and features where the server downloads a file from a user-supplied URL.

STEP 2: CHECK EACH PATH AGAINST THIS LIST
Validation
- Extension allowlist (not a blocklist), AND real content check using magic bytes, not just the Content-Type header or file extension the client sent
- Maximum file size, maximum number of files, and request size limits at the server and proxy level
- Double extensions (shell.php.jpg), null bytes, and unusual unicode in file names

Storage
- The original file name is never used to build the storage path (path traversal, for example ../../)
- Files are renamed to random IDs on save
- Files are stored outside the web root or in private object storage, with no execute permission
- Uploaded files can never be run as code by the server

Serving
- Files are served with X-Content-Type-Options: nosniff and a correct Content-Type
- Risky types (SVG, HTML, PDF) are either blocked or served as downloads from a separate domain, to prevent stored XSS
- Access to private files requires authentication and an ownership check, using short-lived signed URLs

Processing
- Images are re-encoded to strip hidden payloads and EXIF data
- Zip files are protected against zip slip and decompression bombs (limits on size, file count, and nesting)
- Uploads are scanned for malware where appropriate (for example ClamAV or a cloud scanning service)
- Image and video libraries (ImageMagick, ffmpeg, Sharp and so on) are current and run with limited privileges
- CSV import is protected against formula injection (cells starting with =, +, -, @)

Abuse
- Upload endpoints require authentication and are rate limited, with per-user storage quotas

STEP 3: FIX PLAN
For each problem, show the safe pattern for my stack, with a short code example for the two most dangerous issues you found.
OUTPUT FORMAT
1. Start with a short summary: how many findings per severity (Critical / High / Medium / Low).
2. Then a findings table. For each finding give: ID, severity, file and line, what is wrong, how an attacker would exploit it in practice, and the exact fix.
3. Do NOT change any code yet. Wait for me to reply with the finding IDs to fix.
4. If you are not sure about something, say so and tell me how to verify it. Do not guess or invent details.

Tip: If your app has no upload feature, also check for indirect ones: importing a CSV, fetching an image from a URL, or accepting a profile photo. All of them count.

Run everything: launch readiness report

Use this at the very end, or when you want one report covering all six checks.

launch-readiness.prompt

You are a senior application security engineer performing a pre-launch security review of this project. Run these six checks in order, and for each one search the actual code before answering:

1. API rate limits: inventory every endpoint, then tell me which ones have no limit or a bypassable limit, and what limit each category should have.
2. Input validation: find every entry point where user data arrives and check server-side validation of type, length, characters, and range, plus injection, XSS, SSRF, and insecure direct object reference risks.
3. Hardcoded API keys: scan all files, config, CI files, client bundles, and git history for exposed secrets. Mask any secret you find.
4. Dependency vulnerabilities: audit every dependency and lockfile, check for known vulnerabilities, abandoned packages, and lookalike or non-existent package names.
5. Error handling and information leakage: check what errors, headers, logs, and debug endpoints reveal, and whether failures deny access safely.
6. File upload security: check validation, storage, serving, and processing of every file a user can upload.

MY STACK: [STACK]

FINAL REPORT
- A launch readiness verdict: GO, GO WITH FIXES, or NO-GO, with a one-paragraph reason.
- A single prioritised list of every finding across all six checks, sorted by severity, with file and line, exploit scenario, and fix.
- The top 5 fixes I should do first today.
- A list of what you could NOT check from the code alone (for example server configuration, cloud permissions, DNS) so I can verify it manually.

Do not change any code until I approve specific findings. Do not invent vulnerabilities or version numbers. If you are unsure, say so.

Tip: Works best in a tool that can read your whole codebase. In a chat-only tool, run the six checks one at a time instead.

Important reminder before you ship

AI-assisted review catches a lot, but it is not a replacement for a professional penetration test if your app handles payments, health data, or other sensitive personal information. Always review AI-generated fixes before merging them, and never paste real secrets into a chat.

If you are launching teacher sales pages, webinars, or course checkouts on Innovorus, run these checks against payment confirm routes, public pages, and upload endpoints before you spend on ads.

Innovorus FAQ

What is this security prompt pack?

It is a set of six copy-paste AI prompts that audit rate limits, input validation, hardcoded keys, dependencies, error leakage, and file uploads before you launch a vibe-coded app.

Which AI tools can I use with these prompts?

Use any coding AI that can read your repo, such as Cursor, Claude Code, Codex, or Copilot Chat. Fill in the [STACK] line first.

Do I need to change code immediately?

No. Each prompt asks the AI to report findings first and wait for you to approve which finding IDs to fix.

What should I put in the STACK line?

List your real stack, for example Next.js, Supabase, Stripe, and Vercel, so the AI recommends limits and fixes that match your hosting.

Is this a replacement for a penetration test?

No. AI-assisted review catches many issues, but apps that handle payments or sensitive personal data still need a professional penetration test.

What if a prompt finds a live API key?

Rotate or revoke the key first, then remove it from code and git history. Deleting the line alone is not enough.

Can I run all six checks at once?

Yes. Use the launch readiness master prompt at the end for one prioritised report across all six checks.

How does this help Innovorus teachers and builders?

Builders shipping courses, sales pages, or apps on https://www.innovorus.com can run these checks before Meta ads or public launch to reduce payment and data risks.

Where can I learn and ship products on Innovorus?

Browse courses at https://www.innovorus.com/courses, publish teacher sales pages, and register free at https://www.innovorus.com.

What is Innovorus?

Is Innovorus free to join?

Registration on Innovorus is free before you purchase a course, gig, or digital product.

How much do instructors earn on Innovorus?

Instructors earn 70% on standard course sales and 80% when the buyer uses that instructor's own referral code.

What payment method does Innovorus use for courses?

Innovorus uses Safepay for course checkout in PKR while USD prices are commonly shown on listings.

How do I contact Innovorus support?

Email support@innovorus.com or contact@innovorus.com for marketplace and checkout questions.

Where is the Innovorus blog?

Read more guides at https://www.innovorus.com/blog including launch and creator workflow articles.

Insights & Guides

Apple-Style Scroll Animation: The Complete 4-Step Guide (With Every Prompt)

Insights & Guides

Apple-Style Scroll Animation: The Complete 4-Step Guide (With Every Prompt)