checkmyvibe 1.2.0 → 1.3.0

package/adapters/AGENTS-SNIPPET.md

@@ -0,0 +1,32 @@
+# checkmyvibe — AGENTS.md snippet
+
+Paste the section below into your project's `AGENTS.md` (or the global one, e.g.
+`~/.codex/AGENTS.md`, `~/.gemini/GEMINI.md`). This makes any agent that reads
+AGENTS.md — Codex CLI, Gemini CLI, Cursor, opencode, Antigravity, and others —
+able to discover and run checkmyvibe.
+
+---
+
+## checkmyvibe (production readiness & code quality audit)
+
+When the user asks to "check my vibe", run a production readiness check, review
+code quality, do a pre-ship sanity check, check for exposed environment variables,
+check launch readiness, or asks for a scoped check (`secrets`, `auth`, `db`,
+`backend`, `frontend`, `payment`) — use the checkmyvibe skill:
+
+1. Locate its instructions file `SKILL.md` by checking, in order:
+   - `.claude/skills/checkmyvibe/SKILL.md`
+   - `~/.claude/skills/checkmyvibe/SKILL.md`
+   - Search the repo for a `SKILL.md` whose frontmatter contains `name: checkmyvibe`
+2. Read it fully and follow every instruction: scope selection, all applicable
+   checks, evidence/confidence rules, severity rubric, report format, and final summary.
+3. Run helper scripts from the `scripts/` folder next to SKILL.md where the skill
+   directs you to (Checks 1–4 and Check 7). They are Python 3: try `python <script> <target>`,
+   and if not found retry with `python3`.
+4. Save the full detailed audit report to `checkmyvibe-report.md` in the target directory,
+   and output the summary and verdict in the conversation response.
+5. If no scope is specified, run the full audit (all checks).
+
+Scopes map to checks exactly as defined in SKILL.md's "Scope selection" table:
+`secrets` = 1a+1b+2 · `auth` = 3 · `db` = 4 · `backend` = 1a+3+4+5+6(server)+7(server)
+· `frontend` = 1b+3(client)+7(client) · `payment` = 7 · full = everything.

package/adapters/checkmyvibe.mdc

@@ -0,0 +1,18 @@
+---
+description: checkmyvibe production readiness audit trigger and entry point
+globs:
+alwaysApply: true
+---
+
+# checkmyvibe (production readiness & code quality audit)
+
+When the user asks to "check my vibe", run a production readiness check, review code quality, do a pre-ship sanity check, check for exposed environment variables, check launch readiness, or asks for a scoped check (`secrets`, `auth`, `db`, `backend`, `frontend`, `payment`) — use the checkmyvibe skill.
+
+Locate its instructions file `SKILL.md` by checking, in order:
+1. `.claude/skills/checkmyvibe/SKILL.md`
+2. `~/.claude/skills/checkmyvibe/SKILL.md`
+3. Search the repo for a `SKILL.md` whose frontmatter contains `name: checkmyvibe`
+
+Read it fully and follow every instruction: scope selection, all applicable checks, evidence/confidence rules, severity rubric, report format, and final summary. If no scope is specified, run the full audit (all checks). Scopes map to checks exactly as defined in SKILL.md's "Scope selection" table.
+
+Run helper scripts from the `scripts/` folder next to SKILL.md where the skill directs (Checks 1–4 and Check 7). They are Python 3: try `python <script> <target>` first; if not found, retry with `python3`. Always save the complete, detailed audit report to `checkmyvibe-report.md` in the target directory, and provide the summary and verdict in your response.

package/adapters/opencode-checkmyvibe.md

@@ -0,0 +1,19 @@
+---
+description: Run a checkmyvibe production readiness audit. Optional scope argument: secrets | auth | db | backend | frontend | payment (empty = full audit).
+---
+
+$ARGUMENTS
+
+Run the checkmyvibe production readiness and code quality audit.
+
+First, locate the checkmyvibe skill file `SKILL.md`. Check these paths in order:
+
+1. `.claude/skills/checkmyvibe/SKILL.md` (project-level install)
+2. `~/.claude/skills/checkmyvibe/SKILL.md` (global install)
+3. If neither exists, search the working directory for a file named `SKILL.md` whose frontmatter contains `name: checkmyvibe`
+
+Read it in full and follow it completely: scope selection, checks, scripts, evidence/confidence rules, severity rubric, report format, post-fix verification, and final summary structure. Always save the complete, detailed audit report to `checkmyvibe-report.md` in the target directory and display the summary and verdict in your response.
+
+**Scope handling:** interpret `$ARGUMENTS` above as the scope keyword plus an optional target directory (e.g. `secrets src/`). Valid scopes: `secrets`, `auth`, `db`, `backend`, `frontend`, `payment`. No arguments means a full audit across all checks (1a, 1b, 2, 3, 4, 5, 6, 7). Run only the checks mapped to the chosen scope in SKILL.md's scope table and list skipped checks in the final summary.
+
+Helper scripts live in the `scripts/` folder next to SKILL.md. They are Python 3: try `python <script> <target>` first; if `python` is not found, retry with `python3`.

package/commands/checkmyvibe-auth.md

@@ -20,27 +20,33 @@ This is an **authentication-only check** (Check 3). Checks 1a/1b, 2, 4, 5, 6, an
 python <skill_dir>/scripts/check_auth_patterns.py <target>
 ```
 
-It flags stub names (`mockAuth`, `fakeLogin`, `tempAuth`, `bypassAuth`, ...) and always-true auth functions. If Python is unavailable or it fails, say so and do the equivalent greps manually. The script skips test directories — do not report mock auth inside unit tests even if you see it manually.
+It flags stub names (`mockAuth`, `fakeLogin`, `tempAuth`, `bypassAuth`), functions returning `true` unconditionally, mock user dictionary/object returns (`req.user = {...}`, `return { id: ... }`), middleware unconditionally calling `next()`, and insecure Supabase `getSession()` usage on server routes. The script skips test directories and documentation files.
 
 ## Step 2 — Manual reasoning pass (this is where the real findings are)
 
-The script is a first pass only. Read the actual auth code: login handlers, middleware, route guards, session checks, and every route that returns or modifies user-specific data.
+The script is a first pass only. Read the actual auth code across login handlers, middleware, route guards, session checks, and every route that returns or modifies user-specific data.
 
 Findings to hunt for:
 
-- **Always-true stubs:** `function isAuthenticated() { return true; }`, `const checkAdmin = () => true` — Critical.
-- **Stub-named helpers still wired in:** `mockAuth`, `devAuth`, `bypassAuth` reachable in production paths — Critical. Properly guarded behind `NODE_ENV === 'development'` → Should Fix (env misconfig leaks these constantly); verify the guard actually covers every import/call site.
-- **Protected routes with no auth check at all:** list every route returning user-specific data, then check each one calls the session/auth middleware. A `/api/orders/:id` with no guard is Critical regardless of what the UI does.
-- **Client-side-only enforcement:** UI hides a button/route for logged-out users but the underlying API never verifies the session — Critical. Anyone calls the API directly. To confirm this you MUST read the corresponding server route; do not clear a finding from the frontend alone.
-- **Commented-out auth checks** with an active bypass nearby.
-- **JWT/session verification gaps:** tokens decoded but not verified (`jwt.decode` instead of `jwt.verify`, no algorithm pinning), sessions accepted from client-controlled storage without server validation — Critical.
+- **Always-true stubs & mock user objects:** `function isAuthenticated() { return true; }`, `req.user = { id: "demo", role: "admin" }`, middleware calling `next()` unconditionally with a TODO comment — **Critical**.
+- **Stub-named helpers still wired in:** `mockAuth`, `devAuth`, `bypassAuth` reachable in production paths — **Critical**. Properly guarded behind `NODE_ENV === 'development'` → **Should Fix** (environment misconfigurations frequently expose these); verify the guard covers every call site.
+- **Provider-specific security gotchas:**
+  - **Clerk:** Check `middleware.ts` matcher regexes. If `/api/(.*)` is omitted from the protected matcher, or if Clerk v5 `auth.protect()` is omitted from sensitive API routes → **Critical**.
+  - **NextAuth / Auth.js:** Missing `AUTH_SECRET` / `NEXTAUTH_SECRET` in production configuration; exposing sensitive user properties or database credentials inside client session callbacks → **Should Fix**.
+  - **Supabase Auth:** Using `supabase.auth.getSession()` on the server (Server Components, API routes, Server Actions) instead of `supabase.auth.getUser()`. `getSession()` reads local cookies without re-validating the token with the Supabase Auth server → **Critical**.
+  - **Firebase Auth:** Unverified `auth.currentUser` on the client trusted on server routes without server-side `admin.auth().verifyIdToken()`.
+- **Protected routes with no auth check at all:** Compare routes that return or modify user-specific data against route definitions. Any route touching user records with no guard is **Critical**.
+- **Client-side-only enforcement:** UI hides a button or redirects on the client (`{user.isAdmin && <AdminPanel />}`), but the underlying API endpoint lacks an authentication/role check — **Critical**. Anyone can call the API directly. You MUST inspect the server route.
+- **Cookie & Token Storage Security:** Auth tokens stored in browser `localStorage` (vulnerable to XSS token theft) rather than `httpOnly`, `Secure`, `SameSite=Lax/Strict` cookies → **Should Fix**.
+- **Password hashing in custom auth:** Storing passwords in plaintext, or using outdated hash algorithms (MD5, SHA-1, plain SHA-256 without salt/work factor) instead of bcrypt or argon2 → **Critical**.
 
 ## Step 3 — Judgment rules
 
 - Read the function body fully before flagging or clearing — never decide from the name alone.
 - Prefer one precise finding over several weak ones; tag uncertain items `High confidence` / `Medium confidence` / `Needs manual review`.
-- Identify the stack's intended auth mechanism (NextAuth, Clerk, Supabase Auth, custom JWT) first; "missing" means missing relative to how routes access user data, not absence of a specific library.
+- Identify the stack's intended auth mechanism (Clerk, NextAuth, Supabase Auth, Firebase, custom JWT/session) first; "missing" means missing relative to how routes access user data, not absence of a specific library.
 
 ## Report
 
+Save the complete, detailed audit report to `checkmyvibe-report.md` in the target directory following the report structure in `SKILL.md`. Output the executive summary, key findings, and verdict in your conversation response, and include a reference to `checkmyvibe-report.md`.
 Use the format, severity rubric, and final-summary structure from SKILL.md. Scope reminder: "authentication-only check — secrets, .gitignore, database rules, IDOR, input validation, and payment checks were skipped. This does not mean the app is production-ready. Run a full `/checkmyvibe` audit before launch."

package/commands/checkmyvibe-backend.md

@@ -14,19 +14,20 @@ Use SKILL.md **only** for the report format, severity rubric, and final-summary
 
 This is a **backend-only check**: Check 1a (server-side secrets) + Check 3 (auth) + Check 4 (db) + Check 5 (IDOR) + Check 6 server-side + Check 7 server-side. Skipped and to be listed as such in the summary: Check 1b (client-exposed secrets), Check 2 (.gitignore hygiene), and client-side views of checks 3/6/7.
 
-## Step 1 — Run all three scripts
+## Step 1 — Run all four scripts
 
 ```bash
 python <skill_dir>/scripts/scan_secrets.py <target>
 python <skill_dir>/scripts/check_auth_patterns.py <target>
 python <skill_dir>/scripts/check_db_config.py <target>
+python <skill_dir>/scripts/check_payment_config.py <target>
 ```
 
-Triage per the rules in `/checkmyvibe-secrets`, `/checkmyvibe-auth`, and `/checkmyvibe-db` respectively: live keys Critical / test keys Should Fix; mock-auth hits outside tests need manual reading; missing RLS and `USING (true)` policies are Critical on user-data tables. If Python is unavailable, do each check manually and say so in the report.
+Triage findings per the rules in `/checkmyvibe-secrets`, `/checkmyvibe-auth`, `/checkmyvibe-db`, and `/checkmyvibe-payment` respectively. If Python is unavailable, do each check manually and say so in the report.
 
-## Step 2 — IDOR sweep (Check 5 — spend the most time here)
+## Step 2 — IDOR / BOLA sweep (Check 5 — spend the most time here)
 
-This is the single most common serious flaw in AI-generated apps. Enumerate every route that takes an ID (URL param, query string, or body field) and touches a database record:
+This is the single most common serious flaw in AI-generated apps. Enumerate every route, Next.js Server Action, or RPC procedure that takes an ID and touches a database record:
 
 ```js
 // Finding example — Critical: any logged-in user reads ANY order
@@ -41,22 +42,31 @@ const order = await db.query(
 if (!order) return res.status(404).json({ error: 'Not found' });
 ```
 
-Check GET (exposure), PUT/PATCH (unauthorized modification), and DELETE (often most damaging) for all of them. An auth guard alone is not enough — ownership must be enforced in the query or immediately after fetch.
+### Advanced IDOR Patterns to Check:
+- **Multi-Tenant / Organization IDOR:** In B2B or team workspaces, verifying `organization_id = req.params.orgId` is NOT enough. You must verify that the requesting `req.user.id` is an active member/admin of `orgId` before executing the query → **Critical**.
+- **Next.js Server Actions:** Functions marked `'use server'` (`export async function deleteDocument(docId)`) are public RPC endpoints. If user authentication and document ownership are not verified inside the function body, anyone can invoke the action remotely → **Critical**.
+- **tRPC / GraphQL Resolvers:** Check that resolvers pulling resources by ID verify authorization in context rather than returning records purely by input ID.
+- Check GET (exposure), PUT/PATCH (modification), and DELETE (often most damaging) across all endpoints.
 
-## Step 3 — Server-side input handling (Check 6)
+## Step 3 — Server-side input handling & validation (Check 6)
 
-- SQL built by string concatenation instead of parameterized queries/ORM → Critical.
-- **Mass assignment:** `req.body` spread straight into ORM create/update (`prisma.user.update({ data: req.body })`, `User.findByIdAndUpdate(id, req.body)`) letting users set `role`, `plan`, `isAdmin`, `emailVerified` → Critical; non-privileged fields → Should Fix.
-- Unescaped user input into HTML in non-auto-escaping frameworks → flag worst cases.
-- Login/signup/password-reset/OTP endpoints with no rate limiting → Should Fix for payment-handling apps, Worth Reviewing otherwise.
-- File uploads with no type/size restriction.
+- **SQL built by string concatenation** instead of parameterized queries or ORM methods → **Critical**.
+- **NoSQL / MongoDB Injection:** Passing `req.body` or `req.query` directly into `find()`, `findOne()`, or `deleteMany()` without sanitization → **Critical** (`{ "$gt": "" }` bypasses checks).
+- **Server-Side Request Forgery (SSRF):** Endpoints that fetch user-supplied URLs (link scrapers, webhooks, image proxies via `axios.get(req.body.url)` or `fetch()`). If URLs are not validated against private IP ranges (`127.0.0.1`, `localhost`, `169.254.169.254` AWS metadata, internal RFC1918 subnets), attackers can exfiltrate cloud credentials or hit internal services → **Critical**.
+- **Mass assignment:** `req.body` spread straight into ORM create/update (`prisma.user.update({ data: req.body })`, `User.findByIdAndUpdate(id, req.body)`) letting users set `role`, `plan`, `isAdmin`, `emailVerified` → **Critical**; non-privileged fields → **Should Fix**.
+- **CORS Misconfiguration:** Wildcard CORS reflection with credentials (`cors({ origin: '*', credentials: true })`) → **Critical**.
+- **Rate limiting on auth endpoints:** Login, signup, password reset, and OTP endpoints with no attempt throttle allow credential stuffing and SMS toll fraud → **Should Fix**.
+- **Unrestricted File Uploads:** Upload endpoints with no validation of MIME type or file size.
 
 ## Step 4 — Payment processing & webhooks (Check 7, server side)
 
-- Price/discount/total taken from request body, query param, or hidden field instead of looked up from the DB → Critical.
-- **Webhook signature verification:** every payment webhook route (Stripe, PayPal, Razorpay, Firebase) must verify the signature before trusting the body — e.g. Stripe's `stripe.webhooks.constructEvent(rawBody, sigHeader, webhookSecret)` with the raw body. A webhook route with no signature verification anywhere in its flow → Critical: anyone can POST "payment succeeded" and get their order marked paid.
-- Webhook handlers acting on unverified amounts read from the event body → same severity.
+- Price/discount/total taken from request body, query param, or hidden field instead of looked up from the DB → **Critical**.
+- **Webhook signature verification:** Every payment webhook route (**Stripe**, **Lemon Squeezy**, **Dodo Payments**, **Polar**, **Paddle**, **Razorpay**, **PayPal**) must verify cryptographic signatures before trusting the body. An unverified webhook route → **Critical** (anyone can POST fake successful payments).
+- **Webhook Idempotency:** Missing event deduplication on gateway `event.id` causing duplicate credits on retried webhooks → **Should Fix**.
+- **Subscription Revocation:** Missing handling for subscription cancellation/expiration events (`customer.subscription.deleted`, `subscription_cancelled`) → **Critical**.
+- **Customer Portal IDOR:** Creating customer billing sessions using `req.body.customerId` instead of the session user's record → **Critical**.
 
 ## Report
 
+Save the complete, detailed audit report to `checkmyvibe-report.md` in the target directory following the report structure in `SKILL.md`. Output the executive summary, key findings, and verdict in your conversation response, and include a reference to `checkmyvibe-report.md`.
 Use the format, severity rubric, evidence/confidence rules, and post-fix verification step from SKILL.md. Fix priority when multiple issues exist: critical user exposure > auth bypass > IDOR > payment logic > config > hygiene. Scope reminder: "backend-only check — client-exposed secrets, .gitignore hygiene, and frontend-side views were skipped. This does not mean the app is production-ready. Run a full `/checkmyvibe` audit before launch."

package/commands/checkmyvibe-db.md

@@ -20,32 +20,50 @@ This is a **database-only check** (Check 4). Checks 1a/1b, 2, 3, 5, 6, and 7 are
 python <skill_dir>/scripts/check_db_config.py <target>
 ```
 
-It scans SQL files for tables created without RLS and permissive policies (`USING (true)` / `WITH CHECK (true)`), Firestore/storage rules for `allow ...: if true`, and Realtime Database rules set to `"true"`. If Python is unavailable or it fails, do the equivalent checks by reading schema/rules files manually and say so in the report.
+It scans for:
+- SQL migrations/schemas for tables created without RLS and permissive policies (`USING (true)` / `WITH CHECK (true)`) in BaaS stacks.
+- Firestore/storage rules for `allow ...: if true` and Realtime Database rules set to `"true"`.
+- Exposed SQLite database files (`.sqlite`, `.db`) located in web-accessible directories (`public/`, `static/`, `www/`, `dist/`).
+- NoSQL/MongoDB direct object injection (`find(req.body)`).
+- Insecure database connection configs (`sslmode=disable`, `rejectUnauthorized: false`).
 
-## Step 2 — Supabase (if used)
+If Python is unavailable or it fails, do the equivalent checks by reading schema/rules files manually and say so in the report.
 
-- Every table holding user-specific data must have `ENABLE ROW LEVEL SECURITY`. A table without it → Critical.
-- Policies granting broad access fail: `FOR SELECT USING (true)`, policies `TO public/anon` with unconditional USING/CHECK → Critical.
-- Recommended fix pattern:
+## Step 2 — Determine the Database Architecture
+
+Distinguish between two very different database models:
+
+### Branch A: Client-Exposed BaaS (Supabase, Firebase, Convex)
+In these stacks, the browser connects directly to the database using an anonymous public API key. Security MUST be enforced at the database row/collection level:
+
+- **Supabase:** Every table holding user-specific data must have `ENABLE ROW LEVEL SECURITY`. A table without it → **Critical**.
+- Policies granting broad access fail: `FOR SELECT USING (true)`, policies `TO public/anon` with unconditional USING/CHECK → **Critical**.
+- Fix pattern:
   ```sql
   CREATE POLICY "users see own orders" ON orders
     FOR SELECT USING (auth.uid() = user_id);
   ```
-- Check migrations/schema files under `supabase/migrations/`, `db/`, or wherever `.sql` files live. Also confirm RLS wasn't enabled *after* data was already readable via the anon key in earlier deployments.
+- **Firebase:** `firestore.rules` containing `allow read, write: if true;` on user data collections → **Critical**. `database.rules.json` with `".read": "true"` → **Critical**.
+- **Convex:** Ensure functions returning private data are defined as `internalQuery` or validate `ctx.auth.getUserIdentity()`.
 
-## Step 3 — Firebase (if used)
+### Branch B: Server-Backed Databases & ORMs (Neon, AWS RDS, Prisma, Drizzle, Local DBs, Mongo)
+In these stacks, client browsers never talk to the database directly; all queries flow through a backend server (Express, FastAPI, Next.js server):
 
-- `firestore.rules`: any `allow read, write: if true;` on collections holding user data → Critical. Test-mode rules (`allow read, write: if <timestamp>`) pasted into prod-like configs → Should Fix minimum.
-- `database.rules.json` (Realtime DB): `".read": "true"` / `".write": "true"` on user-data nodes → Critical.
-- Rules files present but clearly unused/default → Worth Reviewing; verify which project they deploy to.
+- **Do NOT flag missing RLS on server-only tables:** Standard SQL migrations generated by Prisma or Drizzle do not require Postgres RLS if queries are filtered in backend application code.
+- **Neon & Serverless Pooling:** Verify that serverless functions connect via connection pooling (e.g. `@neondatabase/serverless` or PgBouncer pooled connection strings). Direct unpooled Postgres connections in serverless routes cause connection exhaustion and crashes → **Should Fix**.
+- **SSL / Transport Security:** Database connection URIs or pool configs with `sslmode=disable` or `rejectUnauthorized: false` transmit credentials and data in cleartext → **Critical** in production.
+- **SQLite / Embedded DBs:** SQLite databases (`*.db`, `*.sqlite`, `*.sqlite3`) placed in web-accessible public folders (`public/`, `static/`) or committed to git allow arbitrary database download by any visitor → **Critical**.
+- **MongoDB / NoSQL Injection:** Passing unescaped `req.body` or `req.query` directly into Mongoose/MongoDB query filters (e.g., `User.findOne(req.body)`) allows query selector injection (`{ "$gt": "" }` bypassing passwords) → **Critical**.
+- **Hardcoded DB Credentials:** Database connection strings with embedded plaintext passwords committed in code or schemas (e.g., in `schema.prisma` datasource) → **Critical**.
 
-## Step 4 — Storage buckets
+## Step 3 — Storage buckets
 
-Supabase Storage, Firebase Storage, S3:
+Supabase Storage, Firebase Storage, AWS S3:
 
-- Public buckets holding private user content (documents, receipts, profile files) → Critical.
-- Public buckets for genuinely public assets (avatars, static images) → not findings; note the distinction.
+- Public buckets holding private user content (documents, receipts, profile identity files) → **Critical**.
+- Public buckets for genuinely public assets (avatars, static product images) → not findings; note the distinction.
 
 ## Report
 
+Save the complete, detailed audit report to `checkmyvibe-report.md` in the target directory following the report structure in `SKILL.md`. Output the executive summary, key findings, and verdict in your conversation response, and include a reference to `checkmyvibe-report.md`.
 Use the format, severity rubric, and final-summary structure from SKILL.md. Scope reminder: "database-only check — secrets, .gitignore, authentication, IDOR, input validation, and payment checks were skipped. This does not mean the app is production-ready. Run a full `/checkmyvibe` audit before launch."

package/commands/checkmyvibe-frontend.md

@@ -12,7 +12,7 @@ Use SKILL.md **only** for the report format, severity rubric, and final-summary
 
 ## Scope
 
-This is a **frontend-only check**: Check 1b (client-exposed secrets) + Check 3 viewed from the client (UI-only enforcement) + Check 7 viewed from the client (client-controlled pricing). Skipped and to be listed as such in the summary: Check 1a standalone triage, Check 2 (.gitignore), Check 4 (db rules), Check 5 (IDOR sweep), and full server-side reviews of auth/input/payment.
+This is a **frontend-only check**: Check 1b (client-exposed secrets) + Check 3 viewed from the client (UI-only enforcement) + Check 6 viewed from the client (DOM XSS / AI markdown rendering) + Check 7 viewed from the client (client-controlled pricing). Skipped and to be listed as such in the summary: Check 1a standalone triage, Check 2 (.gitignore), Check 4 (db rules), Check 5 (IDOR sweep), and full server-side reviews.
 
 ## Step 1 — Client-exposed secrets (run script, then manual pass)
 
@@ -22,27 +22,41 @@ python <skill_dir>/scripts/scan_secrets.py <target>
 
 Then manually inspect everything reachable from the browser:
 
-- Framework env prefixes bundle values INTO shipped JS: `NEXT_PUBLIC_*`, `VITE_*`, `REACT_APP_*`, `EXPO_PUBLIC_*`. Any secret behind one of these → Critical.
-- Supabase `service_role` key, Firebase admin SDK JSON, OpenAI/Stripe secret keys anywhere under `src/`, `app/`, `components/`, `pages/`, `public/`, or client entry files → Critical.
-- Publishable keys (`pk_`, Supabase anon key, Firebase web config `apiKey`) are public-by-design → NOT findings; say so explicitly so the report isn't confusing.
+- **Framework Env Prefixes:** `NEXT_PUBLIC_*`, `VITE_*`, `REACT_APP_*`, `EXPO_PUBLIC_*`. Any secret behind one of these is inlined into shipped JavaScript → **Critical**.
+- **React Server Component (RSC) Prop Leaks:** In Next.js App Router, check if a Server Component imports a private secret and passes it as a prop to a client component (`<ClientComponent apiKey={process.env.PRIVATE_KEY} />`). Next.js serializes all props into the client HTML payload → **Critical**.
+- Supabase `service_role` key, Firebase admin SDK JSON, OpenAI (`sk-proj-`), Anthropic, or Stripe secret keys anywhere under `src/`, `app/`, `components/`, `pages/`, `public/`, or client entry files → **Critical**.
+- Publishable keys (`pk_`, Supabase anon key, Firebase web config `apiKey`) are public-by-design → **NOT findings**; note this explicitly so the user isn't confused.
 - Placeholders and test-fixture values → not findings.
 
-## Step 2 — UI-only auth enforcement (Check 3, client view)
+## Step 2 — DOM XSS & Unescaped AI Markdown Rendering
+
+AI-generated applications frequently display LLM responses, user bios, or chat logs:
+
+- Inspect components rendering HTML or markdown (`react-markdown`, `marked`, `markdown-it`).
+- **Unescaped rendering:** Rendering LLM or user markdown with `dangerouslySetInnerHTML`, `v-html`, or `react-markdown` without `rehype-sanitize` or DOMPurify → **Critical** (an attacker or malicious prompt injection can inject `<script>` tags, `<img onerror=...>`, or iframe exploits directly into users' browsers).
+
+## Step 3 — UI-only auth enforcement (Check 3, client view)
 
 Find every place the UI gates access: redirects on protected pages, hidden nav items, disabled buttons, client route guards:
 
-- For each gated feature, open the corresponding API route/mutation and confirm it independently verifies the session server-side. If it does not → Critical ("hiding the button does nothing; anyone calls the API directly").
-- Auth state trusted purely from client storage (localStorage JWT, global store) to protect data → Critical if no server verification exists.
+- For each gated feature, open the corresponding API route/mutation/Server Action and confirm it independently verifies the session server-side. If it does not → **Critical** ("hiding the button does nothing; anyone can call the endpoint directly").
+- Auth state trusted purely from client storage (localStorage JWT, global store) to protect data → **Critical** if no server verification exists.
 - You must read the server routes to clear or confirm findings — a clean-looking frontend proves nothing on its own.
 
-## Step 3 — Client-controlled pricing (Check 7, client view)
+## Step 4 — Client-controlled pricing (Check 7, client view)
 
 Inspect checkout/cart/pricing flows:
 
-- Prices, discounts, totals, or quantities computed client-side and sent as the chargeable value (hidden form fields, request bodies, query params) → Critical on the corresponding server endpoint.
+- Prices, discounts, totals, or quantities computed client-side and sent as the chargeable value (hidden form fields, request bodies, query params) → **Critical** on the corresponding server endpoint.
 - Coupon codes validated only in the UI → flag the endpoint that accepts them without server-side validation.
 - Note exactly which server endpoint accepts the tainted value so the backend fix is obvious.
 
+## Step 5 — Security Headers & Analytics Data Hygiene
+
+- **Clickjacking:** Missing `X-Frame-Options: DENY` or `Content-Security-Policy: frame-ancestors 'none'` allows malicious sites to embed the app in an invisible iframe → **Should Fix**.
+- **Analytics PII auto-capture:** Session recording tools (PostHog, Hotjar, LogRocket) capturing private form fields (passwords, credit card numbers, auth tokens) without masking classes (`data-mask` / `ph-no-capture`) → **Should Fix**.
+
 ## Report
 
+Save the complete, detailed audit report to `checkmyvibe-report.md` in the target directory following the report structure in `SKILL.md`. Output the executive summary, key findings, and verdict in your conversation response, and include a reference to `checkmyvibe-report.md`.
 Use the format, severity rubric, and final-summary structure from SKILL.md. Scope reminder: "frontend-only check — server-side secret triage, .gitignore hygiene, database rules, IDOR, server input validation, and webhook verification were skipped. This does not mean the app is production-ready. Run a full `/checkmyvibe` audit before launch."

package/commands/checkmyvibe-payment.md

@@ -14,17 +14,36 @@ Use SKILL.md **only** for the report format, severity rubric, and final-summary
 
 This is a **payment/pricing-only check** (Check 7, both client and server views). Checks 1a/1b, 2, 3, 4, 5, and 6 are skipped and must be listed as skipped in the final summary. Note: if this app handles real payments, state in the report that a professional external review is strongly recommended regardless of findings.
 
-## Step 1 — Map the payment surface
+## Step 1 — Run the first-pass script
 
-Identify the provider (Stripe, PayPal, Razorpay, Firebase-based, custom) and locate: checkout endpoints, webhook routes, cart/price calculation code (client and server), subscription/plan management, and coupon/discount handling. If there is no payment code at all, report "No issues found — no payment flow exists" and stop.
+```bash
+python <skill_dir>/scripts/check_payment_config.py <target>
+```
 
-## Step 2 — Server-side price trust
+It scans source files for client-controlled amounts/prices in checkout endpoints, detects payment webhook routes, checks for provider signature verification (Stripe, Lemon Squeezy, Dodo Payments, Paddle, Razorpay), checks for missing subscription cancellation listeners, and detects billing portal IDOR risks.
+
+If Python is unavailable or it fails, do the equivalent checks by reading payment handlers manually and say so in the report.
+
+## Step 2 — Map the payment surface
+
+Identify all payment and merchant-of-record providers in use:
+- **Stripe** (`stripe`, `@stripe/stripe-js`)
+- **Dodo Payments** (AI app monetization)
+- **Lemon Squeezy** (`@lemonsqueezy/lemonsqueezy.js`)
+- **Polar.sh** (`@polar-sh/sdk`)
+- **Paddle** (`@paddle/paddle-node-sdk`)
+- **Razorpay** (`razorpay`)
+- **PayPal** (`@paypal/checkout-server-sdk`)
+
+Locate checkout endpoints, webhook routes, cart/price calculation code, subscription tier handlers, and coupon/discount handling. If there is no payment code at all, report "No issues found — no payment flow exists" and stop.
+
+## Step 3 — Server-side price trust
 
 For each chargeable action:
 
-- Is the amount read from the request (body field, query param, hidden form field) or computed from client-supplied data? → Critical:
+- Is the amount read from the request (body field, query param, hidden form field) or computed from client-supplied data? → **Critical**:
   ```js
-  // Finding example — Critical
+  // Finding example — Critical: client controls price
   const { productId, price } = req.body;
   await chargeCard(req.user.paymentMethod, price);
 
@@ -33,20 +52,40 @@ For each chargeable action:
   const product = await db.query('SELECT price FROM products WHERE id = $1', [productId]);
   await chargeCard(req.user.paymentMethod, product.price);
   ```
-- Quantities, currency, plan tiers, or seat counts accepted from the client and multiplied into totals without server-side lookup → same severity.
-- Coupons/discounts validated only on the client, or discount values sent by the client rather than looked up server-side → Critical.
-- Free-trial/trial-flag booleans trusted from request bodies → Critical (anyone posts `trial: true` forever).
+- Quantities, currency, plan tiers, or seat counts accepted from the client and multiplied into totals without server-side validation → same severity.
+- Coupons/discounts validated only on the client, or discount values sent by the client rather than looked up server-side → **Critical**.
+- Free-trial/trial-flag booleans trusted from request bodies (`req.body.trial = true`) → **Critical** (anyone posts `trial: true` forever).
 
-## Step 3 — Webhook signature verification (most-missed check)
+## Step 4 — Webhook signature verification across providers
 
 Every payment webhook route must verify authenticity BEFORE trusting or acting on its body:
 
-- Stripe: `stripe.webhooks.constructEvent(rawBody, sigHeader, process.env.STRIPE_WEBHOOK_SECRET)` with `express.raw({ type: 'application/json' })` on the route. No signature verification anywhere in the handler chain → Critical: anyone who finds the URL can POST a fake `payment_intent.succeeded` and get orders marked paid for free.
-- PayPal: `verify-webhook-signature` API call missing → Critical.
-- Razorpay: missing `verifyPaymentSignature` / HMAC comparison → Critical.
-- Firebase/custom webhooks: no shared-secret header compared server-side → Critical.
-- Also flag webhook handlers that fulfill orders based on amounts read from the unverified event payload instead of re-fetching them server-side.
+- **Stripe:** `stripe.webhooks.constructEvent(rawBody, sigHeader, process.env.STRIPE_WEBHOOK_SECRET)` with `express.raw({ type: 'application/json' })`.
+- **Lemon Squeezy:** Verify `x-signature` header using `crypto.createHmac('sha256', secret).update(rawBody).digest('hex')` (with timing-safe comparison).
+- **Dodo Payments:** Verify webhook signature header via Dodo SDK or HMAC verification.
+- **Paddle:** Verify signature with `paddle.webhooks.unmarshal` or HMAC check.
+- **Razorpay:** `validateWebhookSignature` or `crypto.createHmac('sha256', secret)` comparison.
+- **PayPal:** `verify-webhook-signature` API call.
+
+No signature verification anywhere in the handler chain → **Critical**: anyone who finds the URL can POST a fake "payment succeeded" event and get orders or licenses marked paid for free.
+
+## Step 5 — Webhook Idempotency & Replay Attack Prevention
+
+Payment gateways retry webhooks if an endpoint takes >3s or returns 5xx:
+- Check if webhook handlers record the processed gateway event ID (`event.id`) in the database before granting access or fulfilling orders.
+- If missing, a retried webhook can cause duplicate credits, duplicate license generation, or double-shipping → **Should Fix**.
+
+## Step 6 — Subscription Cancellation & Revocation Lifecycle
+
+- AI apps often handle `checkout.session.completed` to grant access, but completely omit `customer.subscription.deleted`, `customer.subscription.updated`, `subscription_cancelled`, or `invoice.payment_failed`.
+- If the revocation event is not handled, users who cancel their plan or whose credit cards expire retain paid access indefinitely → **Critical**.
+
+## Step 7 — Billing Portal IDOR
+
+- Inspect customer billing portal session creation (e.g. `stripe.billingPortal.sessions.create`):
+- If `customerId` is taken from `req.body` rather than resolved from the authenticated user's session record in the database, users can manage, view invoices for, or cancel other customers' subscriptions → **Critical**.
 
 ## Report
 
+Save the complete, detailed audit report to `checkmyvibe-report.md` in the target directory following the report structure in `SKILL.md`. Output the executive summary, key findings, and verdict in your conversation response, and include a reference to `checkmyvibe-report.md`.
 Use the format, severity rubric, and final-summary structure from SKILL.md. Scope reminder: "payment-only check — secrets, .gitignore, authentication, database rules, IDOR, and input validation were skipped. This does not mean the app is production-ready. Run a full `/checkmyvibe` audit before launch, and get a professional security review before handling real money."

package/commands/checkmyvibe-secrets.md

@@ -21,35 +21,44 @@ python <skill_dir>/scripts/scan_secrets.py <target>
 python <skill_dir>/scripts/check_gitignore.py <target>
 ```
 
-If Python is unavailable or a script fails, say so explicitly in the report ("automated secret scan could not run; manually reviewed instead") and do the equivalent manually: grep for key prefixes (`sk_live_`, `sk_test_`, `AIza`, `AKIA`, `ghp_`, `xox[bp]-`) and literal assignments to names containing `key`, `secret`, `token`, `password`.
+If Python is unavailable or a script fails, say so explicitly in the report ("automated secret scan could not run; manually reviewed instead") and do the equivalent manually: grep for key prefixes (`sk-proj-`, `sk-ant-`, `gsk_`, `re_`, `sk_live_`, `sk_test_`, `AIza`, `AKIA`, `ghp_`, `xox[bp]-`), JWT tokens with `service_role`, database URIs, and literal assignments to names containing `key`, `secret`, `token`, `password`.
 
 ## Step 2 — Triage every script finding
 
 The scripts over-match on purpose. For each hit, open the file and decide:
 
-- **Live Stripe key (`sk_live_...`)** → Critical. Charges real cards. Recommend immediate rotation at dashboard.stripe.com, not just deletion.
-- **Test Stripe key (`sk_test_...`) in source** → Should Fix. Not production-critical but must not be committed; rotate if the repo was ever shared/pushed publicly.
-- **AWS `AKIA`, Google `AIza`, GitHub `ghp_`, Slack tokens in source** → Critical. Recommend revoking at the provider console.
-- **Publishable keys (`pk_live`, `pk_test`, Supabase anon keys, Firebase apiKey config)** → NOT findings. These are public-by-design; say so in one line so the user isn't confused.
+- **OpenAI Project Keys (`sk-proj-...`, `sk-None-...`)** → **Critical**. Charges API accounts. Revoke immediately at platform.openai.com.
+- **Anthropic Claude Keys (`sk-ant-api03-...`)** → **Critical**. Charges API usage. Revoke at console.anthropic.com.
+- **Groq (`gsk_...`), Perplexity (`pplx-...`), HuggingFace (`hf_...`)** → **Critical**. Revoke at provider consoles.
+- **Resend Email Keys (`re_...`)** → **Critical**. Used for phishing and mass spam abuse under your domain.
+- **Supabase `service_role` JWT (containing `"role":"service_role"`)** → **Critical**. Completely bypasses Row-Level Security across all tables.
+- **Database Connection URIs with passwords** (`postgres://...:...@...`, `mongodb+srv://...`) → **Critical**. Direct database access.
+- **Live Stripe key (`sk_live_...`)** → **Critical**. Charges real cards. Recommend immediate rotation at dashboard.stripe.com.
+- **Test Stripe key (`sk_test_...`) in source** → **Should Fix**. Must not be committed; rotate if repo was ever shared/pushed publicly.
+- **AWS `AKIA`, Google `AIza`, GitHub `ghp_`, Slack tokens in source** → **Critical**.
+- **Publishable keys (`pk_live`, `pk_test`, Supabase anon keys, Firebase apiKey config)** → **NOT findings**. These are public-by-design; note this distinction so the user isn't confused.
 - **Placeholders** (`your-api-key-here`, `<secret>`, dummy values) → not findings.
-- Anything inside test/fixture/mock directories → not findings (the scripts already skip these).
+- Anything inside test/fixture/mock directories → not findings (scripts skip these).
 
 ## Step 3 — Client-exposure pass (Check 1b)
 
-Manually verify secrets aren't reachable from the browser:
+Verify secrets aren't reachable from the browser:
 
 - Grep frontend code (`src/`, `app/`, `components/`, `pages/`, `public/`, client entry points) for references to secret env vars or service-role keys.
-- In Next.js: any secret used outside a server-only context, or a secret var incorrectly prefixed with `NEXT_PUBLIC_`. In Vite/CRA: secrets behind `VITE_*` / `REACT_APP_*` get bundled into shipped JS — Critical.
-- Supabase `service_role` key, Firebase admin SDK private key JSON, OpenAI/Stripe secret keys appearing anywhere client-reachable → Critical.
+- **Bundler Prefixes:** In Next.js, Vite, CRA, Expo: any secret placed behind `NEXT_PUBLIC_*`, `VITE_*`, `REACT_APP_*`, `EXPO_PUBLIC_*` gets bundled into shipped browser JavaScript → **Critical**.
+- **React Server Component (RSC) prop leaks:** In Next.js App Router, check if a Server Component imports a private secret and passes it as a prop to a client component (`<ClientComponent apiKey={process.env.PRIVATE_KEY} />`). Next.js serializes props into the client payload JSON → **Critical**.
+- Supabase `service_role` key, Firebase admin SDK private key JSON, OpenAI/Stripe/Anthropic secret keys appearing anywhere client-reachable → **Critical**.
 
-## Step 4 — .gitignore hygiene (Check 2)
+## Step 4 — .gitignore & Docker hygiene (Check 2)
 
 From `check_gitignore.py` output plus manual review:
 
-- `.env` / `.env.local` present but not ignored → Critical regardless of contents.
-- No `.gitignore` at all with secret files present → Critical.
-- Run `git log --all --full-history -- .env` (if git available). If `.env` was ever committed → Critical, and state plainly: removing it now is not enough; every secret in git history must be rotated because history stays recoverable.
+- `.env`, `.env.local`, `.env.production` present but not ignored in `.gitignore` → **Critical** regardless of contents.
+- **Docker risk:** If a `Dockerfile` exists and `.env` is omitted from `.dockerignore` → **Critical** (bakes secret environment files into public container image layers).
+- **NPM auth tokens:** `.npmrc` files containing `_authToken=` committed in git → **Critical**.
+- Run `git log --all --full-history -- .env` (if git available). If `.env` was ever committed → **Critical**, and state plainly: removing it now is not enough; every secret in git history must be rotated because git history remains permanently recoverable.
 
 ## Report
 
+Save the complete, detailed audit report to `checkmyvibe-report.md` in the target directory following the report structure in `SKILL.md`. Output the executive summary, key findings, and verdict in your conversation response, and include a reference to `checkmyvibe-report.md`.
 Use the format, severity rubric, and final-summary structure from SKILL.md. Scope reminder for this run: "secrets-only check — Checks 3 (auth), 4 (db), 5 (IDOR), 6 (inputs), and 7 (payments) were skipped. This does not mean the app is secure. Run a full `/checkmyvibe` audit before launch."

package/commands/checkmyvibe.md

@@ -12,15 +12,16 @@ If it still cannot be found, tell the user and stop — do not improvise an audi
 
 Then read `SKILL.md` in full and run the **complete audit: Checks 1a, 1b, 2, 3, 4, 5, 6, and 7**:
 
-- Check 1a — server-side secrets and credentials
-- Check 1b — client-exposed secrets
-- Check 2 — .gitignore hygiene (including git-history check for committed `.env`)
-- Check 3 — missing or fake authentication
-- Check 4 — database / BaaS misconfiguration (Supabase RLS, Firebase rules, storage)
-- Check 5 — broken object-level authorization (IDOR/BOLA), route by route
-- Check 6 — unvalidated inputs, SQLi/XSS risk, mass assignment, missing rate limiting on auth endpoints
-- Check 7 — client-side payment/pricing logic AND webhook signature verification
-
-Run every script in the skill's `scripts/` folder that maps to Checks 1–4 (`scan_secrets.py`, `check_gitignore.py`, `check_auth_patterns.py`, `check_db_config.py`) against the target directory before relying on your own reasoning. If Python is unavailable or a script fails, state that explicitly in the report and do the check manually instead of silently skipping it.
-
+- Check 1a — server-side secrets and credentials (OpenAI, Anthropic, Groq, Resend, Supabase service-role JWTs, database URIs, Stripe, cloud keys)
+- Check 1b — client-exposed secrets & RSC server-to-client prop leaks
+- Check 2 — .gitignore and .dockerignore hygiene (including git-history check for committed `.env` and `.npmrc`)
+- Check 3 — missing or fake authentication (mock user returns, no-op `next()` stubs, Clerk matcher holes, NextAuth secrets, Supabase `getUser`)
+- Check 4 — database misconfiguration (Supabase RLS, Firebase rules, Neon pooling/SSL, Prisma/Drizzle schema checks, public SQLite files, MongoDB injection)
+- Check 5 — broken object-level authorization (IDOR/BOLA across REST routes, Next.js Server Actions, tRPC, and multi-tenant org boundaries)
+- Check 6 — unvalidated inputs (SSRF in AI link/image scrapers, SQLi, NoSQL injection, DOM XSS in AI markdown, mass assignment, CORS wildcards, rate limiting)
+- Check 7 — client-side payment logic, webhook signature verification (Stripe, Lemon Squeezy, Dodo Payments, Polar, Paddle, Razorpay), webhook idempotency, and subscription lifecycle handling
+
+Run every script in the skill's `scripts/` folder (`scan_secrets.py`, `check_gitignore.py`, `check_auth_patterns.py`, `check_db_config.py`, `check_payment_config.py`) against the target directory before relying on your own reasoning. If Python is unavailable or a script fails, state that explicitly in the report and do the check manually instead of silently skipping it.
+
+Save the complete, detailed audit report to `checkmyvibe-report.md` in the target directory following the report structure in `SKILL.md`. Output the executive summary, key findings, and verdict in your conversation response, and include a reference to `checkmyvibe-report.md`.
 Use the report format, severity rubric, evidence/confidence rules, post-fix verification step, and full-audit final summary structure defined in `SKILL.md`.