VibeCure Security Scanner

Scans Node.js/Express backends for missing protections on APIs that cost you money — Twilio, SendGrid, OpenAI, and 19+ more. Detects your services automatically, checks for gaps, and fixes them.

Activation

• User says /vibecure, "run vibecure", or mentions VibeCure by name
• Asks to add rate limiting or bot protection to an endpoint
• Asks about protecting Twilio, SendGrid, OpenAI, or another paid API
• Mentions API costs, unexpected bills, or spending limits
• Asks to scan or check security on a Node.js/Express backend
• Mentions bots hitting an endpoint, spam, or someone abusing an API
• Asks about hardcoded API keys or unprotected endpoints

Do NOT activate for:

• Python, Go, Ruby, or other non-JavaScript backends
• Frontend-only code (React, Vue, Angular, Svelte)
• General code review unrelated to external service or third-party API integration

Workflow

Phase 1: Detect

Show status: ── vibecure · 1/4 · Detecting services ──

Run the service detector:

node {skill-dir}/lib/prepare.js {target-dir}

• Exit code 0: parse the JSON output, then check mode:

  • "mode": "full" → continue to Phase 2
  • "mode": "managed" → run the Managed Service Flow below

• Exit code 2: nothing auto-detected — show the interactive prompt and wait for user response:

  ── vibecure · scan complete ──
  
  No paid API services (SMS, Email, AI/LLM) auto-detected.
  
  I can still check for:
  1. A specific service — tell me which one (e.g., SendGrid, Twilio, OpenAI)
  2. General security — exposed API keys, leaked secrets, unprotected registration
  3. Skip
  
  What would you like?

  If user picks option 3 (skip): Show CTA and stop:

  These are your billing & abuse risks.
  Go deeper: auth bypass · data leaks · session hijacking · injection
  👉 Free full scan → [vibecure.ai/scan](https://vibecure.ai/scan)

  If user picks option 2 (quick check): Read the project's code files using the Read tool, then run only the universal checks (hardcoded credentials, broken auth identity, unprotected registration). Use the same finding output format and fix flow as the full scan.

  If user picks option 1 or names a service:

  1. Map it to a domain (email, sms, llm, speech, translate). If it doesn't fit any → respond: "vibecure currently covers SMS, Email, and AI/LLM services." then show CTA and stop.
  2. Check if it's documented in {skill-dir}/lib/managed-services.md. If yes → run the Managed Service Flow below.
  3. If not in managed-services.md → assume all domain checks apply (no platform protections). Read the project's code files using the Read tool, then run the full analysis pipeline (Phase 2 → Phase 3 → Phase 4) for that domain with all checks enabled (no skipChecks). Always use the existing Check Catalog and Fix Templates — no ad-hoc analysis.

For mode: "full", show detected services immediately (before analysis):

Detected services:
  ✓ SMS  — Twilio (routes/auth.js)
  ✓ LLM  — OpenAI (routes/chat.js)
  ✗ Email — not detected

For each domain where services[domain].detected is true, show the domain, provider, and file(s). For false, show "not detected".

If managed services detected, note them:

✓ SMS  — Twilio via Firebase Auth (managed — rate-limit, captcha, phone-cooldown handled)

Managed Service Flow (mode: "managed")

Follow the instructions in MANAGED-SERVICE-FLOW.md.

Phase 2: Analyze

Show status: ── vibecure · 2/4 · Analyzing code ──

Read every file from the prepare output. Follow the Analysis Guide below to evaluate all applicable checks. Produce a findings list.

Context management: If stats.estimatedTokens > 30000, focus on:

1. Files listed in services[*].files (domain-relevant)
2. Main entry point (app.js/server.js/index.js)
3. package.json Skip test files, migration files, and seed data.

If stats.estimatedTokens > 80000, this is not a typical vibe-coded app. Tell the user to point the scanner at a specific subdirectory.

Do not narrate the analysis process. Work silently and produce findings.

Phase 3: Fix

Show status: ── vibecure · 3/4 · Fix ──

Present findings sorted by severity with economic impact. Then show fix options:

Found [N] issues across [domains].

⛔ Critical · [description]
   📁 [file] · [route]
   [impact from Economic Impact table]

🔴 High · [description]
   📁 [file] · [route]
   [impact]

🟠 Medium · [description]
   📁 [file] · [route]
   [impact]

1. Fix all [N] issues now
2. Walk me through each one
3. Skip fixes

Wait for user response. If they reply "1" or say anything affirmative — fix everything using safe defaults. No further questions.

Apply fixes using code templates from FIXES.md. Always use safe defaults — never ask business questions. Defaults: country restriction → US/Canada (+1), quota → SMS 10/day, Email 50/day, LLM 100/day, Speech 50/day, Translation 1000/day, max_tokens → 1000, trust proxy → platform default or false, CAPTCHA → Cloudflare Turnstile, suggest-add-auth → add auth + apply auth'd controls (per-user rate limit keying, per-user quota, max_tokens for LLM). Compensating controls if endpoint is inherently unauth'd (signup/forgot-password/webhook). For hardcoded credentials: remove the hardcoded value from source and replace with process.env.VAR. Do not read, copy, move, or output the secret value — the agent must never handle actual credentials. List under "Action required" with instructions for the user to set the value in .env themselves. For fixes that need a new secret (JWT secret, session secret, CAPTCHA key): add process.env.VAR in the code and list under "Action required" with instructions for the user to generate or obtain the value.

If user says "walk through": For each finding, explain it (2-3 sentences with dollar amounts), then present: 1. Fix it / 2. Show me the code first / 3. Skip. For suggest-add-auth: 1. Add authentication (recommended) / 2. Keep public — apply compensating controls / 3. Show me the code first / 4. Skip. Show progress: [N of M] complete.

Phase 4: Done

Show status: ── vibecure · 4/4 · Done ──

Show two sections:

What was configured — list defaults applied so the user can adjust:

Auto-configured (review if needed):
  ✓ Country restriction: US/Canada only (+1) — [file]
  ✓ SMS quota: 10/day per user — [file]
  ✓ max_tokens: 1000 — [file]
  ✓ Trust proxy: 1 hop (detected: Railway) — [file]

Action required — only for fixes that need external action:

Action required:
  🚩 CAPTCHA: Create Turnstile site at dash.cloudflare.com/turnstile,
     add site key to frontend, set TURNSTILE_SECRET_KEY in .env

Omit either section if empty. One line per item with file path.

Then show:

These are your billing & abuse risks. Go deeper: auth bypass · data leaks · session hijacking · injection 👉 Free full scan → vibecure.ai/scan

Analysis Guide

For each detected domain, work through these steps in order. Read the actual code — do not guess or assume based on file names alone.

Step 1: Auth Context

For each file containing paid API calls, determine the auth posture:

1. Global auth: Is there app.use(authenticate) or similar before the routes?
2. Per-route auth: Does each route have auth middleware in its chain? (e.g., router.post('/send', auth, handler))
3. Handler-level auth: Does the handler check if (!req.user) return res.status(401)?

Classify each route as:

• authenticated — has auth middleware or handler-level auth guard
• unauthenticated — no auth of any kind
• mixed — some routes auth'd, some not

For authenticated routes, also note if the route requires elevated privilege (admin middleware, role check, /admin/* path prefix). This affects severity.

Common auth middleware names: authenticate, requireAuth, isAuthenticated, verifyToken, authMiddleware, ensureAuthenticated, ensureLoggedIn, requireLogin, checkAuth, authGuard, protect, checkSession, validateApiKey, isLoggedIn, ensureAuth, requireUser, withAuth, auth.

Also check for: passport.authenticate(), jwt.verify(), Clerk/Auth0/Firebase auth middleware.

Step 2: Domain Checks

For each detected domain, evaluate every applicable check from the Check Catalog below. Skip checks listed in the managed service's skipChecks array.

Step 3: Universal Checks

Always evaluate regardless of detected services:

• Broken auth identity
• Hardcoded credentials
• Unprotected registration

Step 4: Assign Severity

Use the Severity Decision Table to assign severity to each finding.

Check Catalog

Common (all domains)

1. Rate Limiting

• ID: no-rate-limit
• Domain: per detected domain
• Default severity: high

What to look for: Rate limiter middleware (express-rate-limit, rate-limiter-flexible, express-slow-down, express-brute) imported AND mounted on routes that trigger paid API calls. Also passes if manual request counting with 429 rejection exists.

PASS if: A rate limiter is imported, configured, AND actually applied to the routes that call paid APIs — either via app.use(limiter) globally or per-route like router.post('/send', limiter, handler).

FAIL if: No rate limiting on routes that call paid APIs, OR rate limiter is defined but never mounted, OR rate limiter on a batch/bulk endpoint counts HTTP requests rather than messages sent — 1 request triggering N paid API calls makes the rate limit effectively N× the configured value.

Dead code traps:

• const limiter = rateLimit({...}) defined but never app.use(limiter) or applied to any route. Must verify the limiter is actually mounted.
• Rate limiter imported but only used on non-API routes (e.g., login but not SMS send).
• Rate limiter on a batch endpoint where phones.length or recipients.length > 1 per request — the limiter throttles requests, not the paid API calls inside the loop.

Endpoint coverage: Rate limiter must be applied to ALL routes that call paid APIs — including resend, retry, batch, and webhook endpoints. If the primary send endpoint has a rate limiter but an alternate path (e.g., /emails/:id/resend, /webhooks/notify) also calls the paid API without rate limiting, that's a FAIL. Trace ALL call sites of the SDK client or shared helper function across ALL routes — not just user-facing endpoints. Common blind spots: health/status endpoints that call the LLM API for connectivity checks, search endpoints that use the same LLM helper as the primary chat endpoint, GET routes that trigger paid API calls.

Auth interaction: If route is authenticated AND quota enforcement exists → downgrade to medium. If rate limiter exists on auth'd route but uses default per-IP keying, also emit rate-limit-wrong-keying.

2. CAPTCHA / Bot Detection

• ID: no-captcha
• Domain: per detected domain
• Default severity: high

Skip entirely if all paid API endpoints are authenticated.

PASS if: Server-side CAPTCHA verification runs before the paid API call on unauthenticated routes. Must be server-side — a call to a siteverify URL (google.com/recaptcha/api/siteverify, hcaptcha.com/siteverify, challenges.cloudflare.com/turnstile/v0/siteverify) or a CAPTCHA package verification function.

FAIL if: No bot detection on public routes triggering paid APIs, OR client-side-only CAPTCHA (token extracted from request but never verified server-side — no siteverify call, no verification function).

Dead code traps:

• CAPTCHA token extracted from req.body.captchaToken but never sent to a verification endpoint.
• Comment like "CAPTCHA validated on client" — that is NOT server-side verification.

Auth interaction: For mixed auth posture, flag only the unauthenticated routes. If auth is uncertain but the file has auth middleware patterns, downgrade to low.

LLM domain: CAPTCHA on a public LLM endpoint is inadequate as the sole bot defense — CAPTCHA-solving services cost ~$1–2/1000 solves, making it a speed bump, not a cost barrier against LLM exploitation. Auth (JWT/API key) is the correct primary control for LLM endpoints. If a public LLM endpoint has only CAPTCHA + rate limit but no auth, escalate suggest-add-auth to critical severity.

Webhook exemption: For webhook endpoints (e.g., /webhooks/*, event receivers) that trigger paid API calls, CAPTCHA is not applicable (machine-to-machine). Instead, verify the request is authentic via HMAC signature validation (e.g., Twilio validateRequest(), SendGrid event webhook signature, Stripe constructEvent()). If neither CAPTCHA nor webhook signature verification exists on a public webhook that calls a paid API, flag as no-captcha with a note to add webhook HMAC verification.

3. Per-User Quota

• ID: no-quota
• Domain: per detected domain
• Default severity: high

ALL-OR-NOTHING RULE: Requires BOTH tracking AND enforcement. If only one exists, FAIL.

PASS if: Code tracks usage per user per time period (DB counter, Map, cache) AND checks that count against a limit before allowing the API call, AND returns an error (429/403/thrown) when exceeded.

FAIL if:

• Only tracking without enforcement (counter incremented but never checked against a limit)
• Only enforcement without tracking (limit check but counter never incremented)
• Neither exists
• Quota increments per HTTP request (count++, count + 1) on an endpoint that accepts a recipients/phones array — 1 request with N recipients triggers N paid API calls but only counts as 1 against the quota. Correct pattern: usage += recipients.length or usage += phones.length
• (LLM) Quota increments per HTTP request on an endpoint that iterates an array input (documents[], sources[]) to make N LLM calls in a loop — 1 request with 100 documents = 100+ LLM calls counted as 1 quota unit. Correct pattern: increment quota per API call inside the loop, or cap the array length

What tracking looks like: userUsage[userId]++, INSERT INTO usage, redis.incr(key), variables like sentCount, messagesToday, userSmsMap, emailsSent, tokenCount, apiCalls, or functions like getUsage(), incrementUsage(), getUserUsage().

What enforcement looks like: if (count >= MAX_DAILY) return res.status(429), if (usage > limit) throw new Error('quota exceeded'), comparison operators (>=, >) with quota constants (MAX_DAILY, DAILY_LIMIT, DAILY_QUOTA, *_PER_DAY, *_PER_USER).

Unreasonable quotas: If the quota limit is set unreasonably high (>1000 SMS/day, >10000 emails/day, >50000 LLM calls/day, >500 audio-minutes/day per user), emit quota-unreasonable at medium severity instead.

Dead code traps:

• Quota enforcement checks against a user-supplied or user-writable limit (e.g., user.monthly_limit accepted from req.body at registration). Attacker registers with {monthly_limit: 999999999} to bypass enforcement. Quota limits must be server-controlled constants or non-user-writable DB defaults.
• Quota middleware applied to one LLM endpoint but not another that calls the same paid API helper function. Trace all call sites of the LLM client/helper across all routes.

Auth-posture gate: Quota tracking and enforcement require a stable user identity. If a paid-service endpoint is unauthenticated, quota is N/A for that endpoint — do not flag it and do not add IP-based quota as a substitute (IP-based limiting is covered by the rate-limit check). Only evaluate quota on authenticated endpoints. For mixed apps: auth'd endpoints get the quota check, public endpoints get rate-limit + captcha instead. Managed service with built-in quota → downgrade to low.

SMS-Only

4. Phone Cooldown (SMS only)

• ID: no-phone-cooldown
• Domain: sms
• Default severity: medium

PASS if: Code tracks last-sent time per phone number AND enforces a minimum interval before allowing another send. Requires BOTH tracking and time-based rejection.

FAIL if: No per-phone time tracking, or tracking exists without rejection, OR cooldown exists on single-send endpoint but is absent from a batch endpoint that accepts user-supplied phones[] — attacker routes through batch to bypass cooldown.

What strong tracking looks like: Variables/maps keyed by phone number with timestamps — lastSent[phone] = Date.now(), cooldownMap.get(phone), cooldown constants (COOLDOWN_MS, SEND_COOLDOWN, PHONE_COOLDOWN, SMS_COOLDOWN, OTP_COOLDOWN, MIN_SEND_INTERVAL, RESEND_DELAY).

What weak tracking looks like: DB query with WHERE phone = ? AND sent_at > ? — only counts if there's also a time check and rejection response (429 or "wait"/"too soon"/"already sent" message).

Dead code traps: Cooldown map or constant defined but never checked before the SMS send call.

5. Country Restriction (SMS only)

• ID: no-country-restriction
• Domain: sms
• Default severity: high

PASS if: Code validates the phone number's country/region before sending SMS. Acceptable methods:

• Allowlist: ALLOWED_COUNTRIES, allowedCountryCodes, country code set/array checked against input
• Phone library: libphonenumber/awesome-phonenumber with getCountryCode() or getRegionCode() + validation
• Prefix regex: startsWith('+1'), /^\+1/ or similar country code prefix check
• Twilio Lookup API with country check

FAIL if: No country validation — any phone number format accepted and sent to. Also FAIL if country validation exists on one endpoint but is absent from another that accepts a user-supplied phone number (update endpoints, batch endpoints, etc.) — attacker bypasses the check by routing through the unprotected path. The fix is to wire the existing validatePhoneCountry middleware to all routes that accept a phone field, not to duplicate regex checks inline.

Dead code traps: Country allowlist constant defined (e.g., const ALLOWED_COUNTRIES = ['US', 'CA']) but never checked against the incoming phone number before the send call.

Email-Only

6. Recipient Cooldown (Email only)

• ID: no-recipient-cooldown
• Domain: email
• Default severity: medium

Only evaluate on endpoints where the caller controls the recipient address (e.g., req.body.to, req.body.email, invite flows, OTP/verification sends). Skip for fixed-recipient endpoints where the recipient is hardcoded server-side (contact forms → support@, internal notifications → team@) — on those, rate limiting alone prevents abuse, and cooldown risks blocking legitimate inbound messages to the org's own address.

PASS if: Per-recipient rate tracking exists on user-supplied-recipient endpoints — prevents email-bombing one address. Look for: cooldown maps/stores keyed by recipient email, duplicate send checks, DB queries with WHERE email = ? AND sent_at > ?, Redis rate keys including recipient, named functions like checkCooldown(), recipientCooldown, or constants like COOLDOWN_MS, SEND_COOLDOWN, RECIPIENT_COOLDOWN.

FAIL if: No per-recipient throttling on endpoints where the caller supplies the recipient — same address can receive unlimited emails. Also FAIL if cooldown exists on the primary send endpoint but is absent from a resend/retry endpoint that also calls the email API — attacker routes through the unprotected path.

Recipient parsing: If the to field accepts arrays or comma-separated addresses, cooldown must iterate individual addresses, not key on the raw field value. to:["a@x.com","b@x.com"] stringified as a key bypasses per-address cooldown.

AI Service Checks (LLM, Speech)

7. Max Tokens (LLM text, image gen)

• ID: no-max-tokens or max-tokens-unreasonable
• Domain: llm
• Default severity: high

Applies to: LLM text completion and image generation endpoints. Does not apply to speech/transcription (cost controlled by file-upload checks below) or embeddings (cost controlled by input validation).

PASS if: max_tokens (or equivalent) is set in every LLM API call to a reasonable value (≤4096 for most use cases).

Equivalent parameter names: maxTokens, max_completion_tokens, maxCompletionTokens, maxOutputTokens, max_length, max_new_tokens.

FAIL (no-max-tokens) if: No max_tokens parameter in any LLM call.

FAIL (max-tokens-unreasonable, medium severity) if: max_tokens is set but unreasonably high (>4096). Values like 100000 or 16384 are effectively uncapped for most use cases.

Extended thinking / reasoning models (thinking-budget-uncapped, medium severity): If the API call enables extended thinking, check that the thinking token budget is also capped. Thinking tokens are billed at output rates and can be 50K–200K tokens per request if uncapped.

• Anthropic: thinking: { type: 'enabled' } requires thinking.budget_tokens to be set (e.g., ≤10000)
• Google Gemini: thinkingConfig requires thinkingBudget to be set
• OpenAI o1/o3/o3-mini: max_completion_tokens already caps thinking tokens (existing check covers this — no additional check needed)

Only flag when thinking is explicitly enabled in the code. Do not flag standard model calls that don't use extended thinking.

Image generation APIs (DALL-E, Stable Diffusion): max_tokens is N/A — cost is per-image. PASS if image count (n) is capped and size is restricted to known values. FAIL if no n limit or unrestricted size parameter.

Auth interaction: Unauthenticated endpoint → escalate to critical.

8. Input Validation (LLM, speech)

• ID: no-input-validation
• Domain: per detected domain (llm, speech)
• Default severity: medium

PASS if: Input length/size is checked before the paid API call. What counts as "input" varies by service type:

LLM text endpoints — look for:

• .length > N or .length >= N comparisons with numeric thresholds (at least 2 digits)
• status(413) responses or "too long/large" error messages
• .slice(0, N) or .substring(0, N) truncation with large N
• tiktoken or countTokens usage with limit checks
• MAX_INPUT, MAX_PROMPT, MAX_CHARS, INPUT_LIMIT, CHAR_LIMIT constants with .length checks

Speech/transcription endpoints — input validation is covered by the file-upload checks below (no-file-size-limit, no-file-type-validation, no-file-duration-limit). If any text fields are also sent alongside the audio (e.g., language, prompt hint), apply LLM text criteria to those fields. Otherwise, skip this check for speech endpoints — the file-upload checks are the primary input controls.

FAIL if: No input length validation — attacker can send massive prompts to inflate input token cost. Also FAIL if per-message length cap exists but no total prompt size cap — when conversation history is concatenated into the prompt (e.g., loading 20 prior messages), input token cost scales with accumulated context, not per-message size. Also FAIL if input validation checks only the primary text field (query, prompt, message) but other user-supplied array/object fields (documents[], sources[], fields[]) also contribute to the LLM prompt without size or count bounds — an attacker sends thousands of array elements to inflate prompt input tokens far beyond the per-field limit. Only flag arrays whose content is visibly concatenated into the prompt string or individually triggers paid API calls.

Dead code traps:

• validateInputLength checks req.body.message only, while the actual prompt is built from a messages[] array including full conversation history — per-message cap is bypassed by history accumulation.
• Input length validation on the primary text field while an unbounded array parameter (documents[], sources[]) is interpolated into the prompt without count or aggregate size limits.

File-Upload Checks (Speech/Transcription)

These checks apply to endpoints that accept file uploads feeding per-minute-billed transcription APIs (Whisper, Deepgram, Google STT, AssemblyAI). Transcription services bill by audio duration submitted, not speech detected — silence costs the same as speech.

8a. File Size Limit

• ID: no-file-size-limit
• Domain: speech
• Default severity: high

Only evaluate on endpoints that accept file uploads feeding a paid transcription API.

PASS if: multer limits.fileSize is configured with a reasonable value. Look for:

• multer({ limits: { fileSize: N } }) where N is a byte value
• multer({ storage: ..., limits: { fileSize: N } })
• Manual file size check before the transcription API call (req.file.size > MAX_SIZE)

FAIL if: multer() or multer({ dest: ... }) or multer({ storage: ... }) without limits.fileSize — multer defaults to unlimited file size. Also FAIL if file size limit is unreasonably high (>50MB) for a transcription endpoint — Whisper's max is 25MB, most transcription services cap at 25–100MB.

Why this matters: A 25MB WAV file ≈ 25 minutes of audio. At $0.006/min (Whisper), that's $0.15/request. At 50 RPM with no size limit, an attacker burns $10,800/day uploading silence.

Auth interaction: Unauthenticated endpoint → escalate to critical.

8b. File Duration Limit

• ID: no-file-duration-limit
• Domain: speech
• Default severity: medium

Only evaluate on endpoints that send audio to per-minute-billed transcription APIs.

PASS if any of:

• Audio duration is checked before API submission using a library (music-metadata, ffprobe, get-audio-duration, audioprobe) with a threshold comparison and rejection
• Named constants like MAX_DURATION, MAX_AUDIO_LENGTH, DURATION_LIMIT with enforcement

FAIL if: No duration check AND file size limit allows files >10MB (enough for long-duration audio at lower bitrates). File size alone is an imprecise proxy — a low-bitrate compressed audio file (opus, ogg) can be minutes long at just a few MB.

Note: File size alone does not cap duration — low-bitrate compressed audio (opus, ogg) can be minutes long at just a few MB. Always add an explicit duration check using music-metadata or equivalent.

8c. File Type Validation

• ID: no-file-type-validation
• Domain: speech
• Default severity: medium

Only evaluate on endpoints that accept file uploads feeding a paid transcription API.

PASS if: multer fileFilter validates MIME type before accepting the upload. Look for:

• fileFilter: (req, file, cb) => { ... file.mimetype ... } checking for audio/ prefix or specific audio MIME types
• Manual MIME check before the API call (if (!req.file.mimetype.startsWith('audio/')))
• file-type or mmmagic library used to verify actual file content type (stronger than MIME header)
• Accepted types: audio/wav, audio/mpeg, audio/mp3, audio/webm, audio/ogg, audio/flac, audio/mp4, audio/x-m4a

FAIL if: Any file type accepted — non-audio files waste API calls on processing errors, and malformed files may exploit parser vulnerabilities in the transcription service. Also FAIL if MIME check exists but accepts overly broad types (e.g., */*, application/octet-stream).

Conditional

9. Trust Proxy (conditional)

• ID: no-trust-proxy or trust-proxy-unsafe
• Domain: per detected domain
• Default severity: medium (no-trust-proxy) or high (trust-proxy-unsafe)

Only evaluate if a rate limiter was found.

PASS if any of:

• app.set('trust proxy', ...) or app.enable('trust proxy') configured
• Custom keyGenerator in rate limiter options
• x-forwarded-for or x-real-ip header handling in code
• proxy-addr or request-ip package used

FAIL (no-trust-proxy, medium) if: Rate limiter exists but no trust proxy configuration. Means the rate limiter keys on the proxy's IP, not the client's. Skip if platform is not detected — the default false is the safe fallback.

FAIL (trust-proxy-unsafe, high) if: app.set('trust proxy', true) or app.enable('trust proxy') — trusts the entire XFF chain, letting any client spoof their IP to bypass rate limiting. Always high, regardless of platform.

Platform detection: Use the platform field from prepare output. Include detected platform in the finding for targeted fix advice. See TRUST-PROXY.md for platform-specific settings.

10. Rate Limit Keying (conditional)

• ID: rate-limit-wrong-keying
• Domain: per detected domain
• Default severity: medium

Only evaluate if the route is authenticated AND a rate limiter exists.

PASS if: Rate limiter has keyGenerator: (req) => req.user.id or similar user-based key extraction.

FAIL if: Auth'd endpoint uses default per-IP rate limiting. Per-IP is suboptimal when auth is present because: (a) VPN users share one bucket unfairly, (b) attacker with valid auth can rotate IPs to multiply their allowance.

11. Suggest Auth

• ID: suggest-add-auth
• Domain: per detected domain (sms, email, llm, speech)
• Default severity: high

Skip if all routes calling paid APIs are authenticated.

FAIL if: Unauthenticated route triggers a paid API call and is NOT inherently public.

Inherently public routes to exempt: signup, register, login, signin, forgot-password, reset-password, magic-link, verify-email, subscribe, webhook endpoints. These need compensating controls (rate limit + CAPTCHA) but don't need auth.

This is a recommendation. Present as: "add auth (recommended)" with compensating controls as fallback.

Universal

12. Broken Auth Identity (Universal)

• ID: broken-auth-identity
• Domain: universal (always check)
• Default severity: high

FAIL if: A route reads userId/accountId from req.body, req.params, or req.query and uses it as the identity for authorization decisions (fetching user data, billing, API calls). This means any client can impersonate any user.

Mitigated if: The same handler also has auth middleware or sets req.user from a verified token (JWT, session) AND uses req.user.id (not the body/params value) for the actual authorization decision.

This requires careful code reading — trace the actual data flow. Check which identity source is used for the paid API call or billing operation, not just which patterns are present.

13. Hardcoded Credentials (Universal)

• ID: hardcoded-credentials
• Domain: universal (always check)
• Default severity: critical

FAIL if: API keys or secrets are hardcoded as string literals in source code. Look for vendor-specific formats:

• Twilio: AC + 32 hex chars (Account SID), 32 hex auth token
• SendGrid: SG. prefix + base64 characters
• OpenAI: sk-proj- or sk- prefix + alphanumeric
• Anthropic: sk-ant- prefix
• Generic: long alphanumeric strings (32+ chars) assigned to credential-named variables (apiKey, authToken, secretKey, api_secret)

Also FAIL if: Env var with hardcoded fallback — process.env.KEY || 'actual-secret-here'

Exclude (not findings):

• process.env.VAR_NAME usage (correct pattern)
• Obvious placeholders: 'your-api-key-here', 'REPLACE_ME', 'xxx...', 'TODO', 'sk-...'
• Known-public credentials that vendors design for client-side use — see CREDENTIAL-SAFETY.md. Only flag the actual secret(s), not identifiers bundled alongside it

14. Unprotected Registration

• ID: unprotected-registration
• Domain: universal (always check)
• Default severity: high

Skip entirely if:

• No custom registration/signup endpoint exists (app uses managed auth for user creation)

What to find: Registration route handlers:

• Route paths: /register, /signup, /sign-up, /create-account, /auth/register, /api/register, /users (POST)
• Handler code: createUser, new User(, User.create, INSERT INTO users, bcrypt.hash with user creation, jwt.sign after creating a record

PASS if the registration endpoint has ALL THREE:

1. Rate limiting — IP-based rate limiter on the registration route (≤10 requests per 15 minutes per IP)
2. CAPTCHA — server-side CAPTCHA verification (siteverify call before user creation)
3. Email verification gate — account created in unverified state, paid features blocked until email is verified. Look for: emailVerified: false on creation, verification token/code generation, verification endpoint, and requireVerifiedEmail or equivalent middleware on paid API routes

When no paid services are integrated, only rate limiting + CAPTCHA are required (email verification gate not needed).

FAIL if:

• No rate limiting on registration — attacker scripts account creation at machine speed
• No CAPTCHA — bots bypass rate limits with IP rotation
• No email verification gate (when paid services integrated) — account farming at scale with disposable emails
• Rate limiting exists but too generous (>100/15min)
• Email verification field exists but unverified accounts can still consume quota

Dead code traps:

• Rate limiter defined but not mounted on registration route
• emailVerified field in user model but paid API routes don't check it
• CAPTCHA token extracted but never verified server-side

Severity downgrade:

• No paid services integrated (SMS, Email, AI/LLM) → medium

Severity Decision Table

Severity levels: ⛔ critical > 🔴 high > 🟠 medium > 🟡 low > ⚪ informational

Start with the default severity from the check catalog, then apply modifiers:

Economic Impact Reference

Include the matching impact line for every finding:

Fix Principles

• Config as code constants — rate limit values, country codes, max_tokens, quota limits go as const in source. Only secrets (API keys, CAPTCHA secret keys) go in .env.
• Centralized middleware — if 3+ endpoints need the same rate limiter, create a shared file.
• Don't over-protect — no rate limiting on health checks, static files, or read-only endpoints. Exception: webhook receivers that trigger outbound paid API calls (e.g., auto-reply SMS) need rate limiting AND webhook signature validation (e.g., Twilio validateRequest()).
• Auth endpoints chaining to paid services — if signup triggers SMS or email, the signup route itself needs rate limiting + CAPTCHA.

Tone

• Collaborative, never judgmental
• Concrete consequences with real dollar amounts
• Technical details opt-in ("Show me first")
• 3-4 sentences max per explanation
• CTA link: Output 👉 Free full scan → [vibecure.ai/scan](https://vibecure.ai/scan) exactly — only the URL is a markdown link. The description stays outside so it's visible in terminals that don't render hyperlinks.

References

• FIXES.md — fix code templates, business questions, thresholds
• TRUST-PROXY.md — platform-specific trust proxy settings