Skip to content
PromptsScoreGet PDFGet the free PDF
Vibe Coding Security Checklist / Rate Limits & Abuse Protection

A. Security & Data Safety · Prompt 7

Rate Limits & Abuse Protection

Get the free PDF

Why it matters

Without limits, one client can guess passwords, spam users, or run up an API bill before anyone notices.

Modeled on

OWASP API Security risks for unrestricted resource use and abuse of business flows.

How to run this prompt

  1. Switch to a mode that does not edit files. In Cursor that is Ask or Plan. In Claude Code that is Plan mode.
  2. Paste the audit prompt. Wait for the report. It must stop and ask which IDs to fix.
  3. Read the report. Keep the IDs you agree with.
  4. Switch to a mode that can edit. Paste the fix prompt and the IDs you chose.
  5. Switch back to the read-only mode and paste the same audit prompt again. Confirm those IDs are gone.
  • Cursor: audit in Ask mode or Plan mode. Fix in Agent mode.
  • Claude Code: audit in Plan mode (Shift+Tab cycles to it). Fix in Normal mode, which can edit.
  • Any other tool: audit in Chat, Discuss, or Plan mode, whichever answers without editing files. If the tool has no such mode, the prompt itself forbids edits. Fix in the mode that is allowed to edit files.

The audit prompt

MODE: AUDIT ONLY. Do not create, edit, or delete any file. Do not run commands
that change anything: no installs, migrations, git commits, deploys, or "--fix" flags.
If your tool has an Ask, Plan, Chat, or Discuss mode, use it for this prompt.

Before you start:
- Tell me the stack you detect (framework, language, database, auth, hosting,
  payment provider) and which folders you will review.
- If a check below does not apply to this stack, write "Not applicable" and why.
- If you can run read-only commands, run the ones listed. If you cannot, list them
  so I can run them and paste the output.

Rate Limits & Abuse Protection: what to check
Review rate limits and abuse controls. Do not send a flood of requests at a live host.
1. List handlers and classify them: authentication (login, signup, reset, OTP or SMS or email), expensive work (search, export, AI calls, uploads), and anything that spends money or sends a message.
2. For auth and message-sending handlers, say whether there is a small limit per IP and per account, with lockout or delay. Cite the file. If there is no limit, say so.
3. Say whether other API handlers return 429 with a Retry-After header, or fail with a generic 500, or have no limit at all.
4. Say where the limit is enforced (app process, shared store, or edge). If the limit trusts X-Forwarded-For from the client, mark it bypassable unless the platform overwrites that header and the app reads only the platform's value.
5. Check business abuse in the code: signup with no cap, promo or referral codes reused without a redemption record, free trials restarted by signing up again, coupon stacking, and list endpoints with no page size.
6. Say whether CAPTCHA or a similar challenge exists on signup or reset, and whether it is required only where abuse is plausible.
7. Say whether body size and request timeouts are set, so one slow or huge request cannot hold a worker.
8. Say whether limiter state is in a shared store (Redis, database, or the platform) or only in memory. In-memory state does not survive a second server process.
9. Do not recommend a specific third-party product. Describe the limit as numbers I can change: which route, which key (IP and account), and which store.

Evidence rules:
- Every finding cites a file path and line number, or the exact command output used.
- Mark each finding Confirmed (seen in the code) or Needs manual check (depends on
  something outside the repo, such as a dashboard setting or production data).
- Never print a full secret. Show the first 4 characters and the location only.
- If you are not sure, say so. Do not invent files, settings, or results.

Severity: Critical = exploitable now, or leaks real data or money. High = serious
with little effort. Medium = weakens defenses or needs a second bug. Low = hygiene.

Report:
- Summary: count of findings by severity.
- Table: ID | Severity | Confirmed? | Finding | Evidence | Why it matters | Suggested fix | Effort
  (IDs for this prompt use the prefix P07, for example P07-1, P07-2.)
- Checked and fine: what you verified is already OK.
- Could not check: what I need to look at myself, and where.

Then stop. Do not fix anything. Ask me which IDs I want fixed.

Example finding

A password-reset handler that sends an email on every request, with no limit.

Get the free PDF

Related prompts

  • 6. File Upload Safety Test
  • 8. Personal Data Flow & Storage Audit

Share this prompt

WhatsAppLinkedInX
Papa Tech Solutions

We Build Software. Intelligently.

Contact

Papa Tech Solutions

D2 - 2004 Divyansh Onyx
Jaipuria Sunrise Greens
Ghaziabad 201002
India

papatechsolution@gmail.com

880 118 6178

Links

Privacy policyTerms and conditionsContact
© 2026 Papa Tech Solutions. All rights reserved.
Get the free PDF