Merge branch 'main' into palette-collapsible-a11y-6862435676078644038

Author: aicoder2009

.agents/skills/vibe-security/SKILL.md

@@ -0,0 +1,122 @@
+---
+name: vibe-security
+description: Audits codebases for common security vulnerabilities that AI coding assistants introduce in "vibe-coded" applications. Checks for exposed API keys, broken access control (Supabase RLS, Firebase rules), missing auth validation, client-side trust issues, insecure payment flows, and more. Use this skill whenever the user asks about security, wants a code review, mentions "vibe coding", or when you're writing or reviewing code that handles authentication, payments, database access, API keys, secrets, or user data — even if they don't explicitly mention security. Also trigger when the user says things like "is this safe?", "check my code", "audit this", "review for vulnerabilities", or "can someone hack this?".
+license: MIT
+metadata:
+  author: Chris Raroque
+  version: "1.0"
+---
+
+Audit code for security vulnerabilities commonly introduced by AI code generation. These issues are prevalent in "vibe-coded" apps — projects built rapidly with AI assistance where security fundamentals get skipped.
+
+AI assistants consistently get these patterns wrong, leading to real breaches, stolen API keys, and drained billing accounts. This skill exists to catch those mistakes before they ship.
+
+
+## The Core Principle
+
+Never trust the client. Every price, user ID, role, subscription status, feature flag, and rate limit counter must be validated or enforced server-side. If it exists only in the browser, mobile bundle, or request body, an attacker controls it.
+
+
+## Audit Process
+
+Examine the codebase systematically. For each step, load the relevant reference file only if the codebase uses that technology or pattern. Skip steps that aren't relevant.
+
+1. **Secrets & Environment Variables** — Scan for hardcoded API keys, tokens, or credentials. Check for secrets exposed via client-side env var prefixes (`NEXT_PUBLIC_`, `VITE_`, `EXPO_PUBLIC_`). Verify `.env` is in `.gitignore`. See `references/secrets-and-env.md`.
+
+2. **Database Access Control** — Check Supabase RLS policies, Firebase Security Rules, or Convex auth guards. This is the #1 source of critical vulnerabilities in vibe-coded apps. See `references/database-security.md`.
+
+3. **Authentication & Authorization** — Validate JWT handling, middleware auth, Server Action protection, and session management. See `references/authentication.md`.
+
+4. **Rate Limiting & Abuse Prevention** — Ensure auth endpoints, AI calls, and expensive operations have rate limits. Verify rate limit counters can't be tampered with. See `references/rate-limiting.md`.
+
+5. **Payment Security** — Check for client-side price manipulation, webhook signature verification, and subscription status validation. See `references/payments.md`.
+
+6. **Mobile Security** — Verify secure token storage, API key protection via backend proxy, and deep link validation. See `references/mobile.md`.
+
+7. **AI / LLM Integration** — Check for exposed AI API keys, missing usage caps, prompt injection vectors, and unsafe output rendering. See `references/ai-integration.md`.
+
+8. **Deployment Configuration** — Verify production settings, security headers, source map exposure, and environment separation. See `references/deployment.md`.
+
+9. **Data Access & Input Validation** — Check for SQL injection, ORM misuse, and missing input validation. See `references/data-access.md`.
+
+If doing a partial review or generating code in a specific area, load only the relevant reference files.
+
+
+## Core Instructions
+
+- Report only genuine security issues. Do not nitpick style or non-security concerns.
+- When multiple issues exist, prioritize by exploitability and real-world impact.
+- If the codebase doesn't use a particular technology (e.g., no Supabase), skip that section entirely.
+- When generating new code, consult the relevant reference files proactively to avoid introducing vulnerabilities in the first place.
+- If you find a critical issue (exposed secrets, disabled RLS, auth bypass), flag it immediately at the top of your response — don't bury it in a long list.
+
+
+## Output Format
+
+Organize findings by severity: **Critical** → **High** → **Medium** → **Low**.
+
+For each issue:
+1. State the file and relevant line(s).
+2. Name the vulnerability.
+3. Explain what an attacker could do (concrete impact, not abstract risk).
+4. Show a before/after code fix.
+
+Skip areas with no issues. End with a prioritized summary.
+
+### Example Output
+
+#### Critical
+
+**`lib/supabase.ts:3` — Supabase `service_role` key exposed in client bundle**
+
+The `service_role` key bypasses all Row-Level Security. Anyone can extract it from the browser bundle and read, modify, or delete every row in your database.
+
+```typescript
+// Before
+const supabase = createClient(url, process.env.NEXT_PUBLIC_SUPABASE_SERVICE_KEY!)
+
+// After — use the anon key client-side; service_role belongs only in server-side code
+const supabase = createClient(url, process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!)
+```
+
+#### High
+
+**`app/api/checkout/route.ts:15` — Price taken from client request body**
+
+An attacker can set any price (including $0.01) by modifying the request. Prices must be looked up server-side.
+
+```typescript
+// Before
+const session = await stripe.checkout.sessions.create({
+  line_items: [{ price_data: { unit_amount: req.body.price } }]
+})
+
+// After — look up the price server-side
+const product = await db.products.findUnique({ where: { id: req.body.productId } })
+const session = await stripe.checkout.sessions.create({
+  line_items: [{ price: product.stripePriceId }]
+})
+```
+
+### Summary
+
+1. **Service role key exposed (Critical):** Anyone can bypass all database security. Rotate the key immediately and move it to server-side only.
+2. **Client-controlled pricing (High):** Attackers can purchase at any price. Use server-side price lookup.
+
+
+## When Generating Code
+
+These rules also apply proactively. Before writing code that touches auth, payments, database access, API keys, or user data, consult the relevant reference file to avoid introducing the vulnerability in the first place. Prevention is better than detection.
+
+
+## References
+
+- `references/secrets-and-env.md` — API keys, tokens, environment variable configuration, and `.gitignore` rules.
+- `references/database-security.md` — Supabase RLS, Firebase Security Rules, and Convex auth patterns.
+- `references/authentication.md` — JWT verification, middleware, Server Actions, and session management.
+- `references/rate-limiting.md` — Rate limiting strategies and abuse prevention.
+- `references/payments.md` — Stripe security, webhook verification, and price validation.
+- `references/mobile.md` — React Native and Expo security: secure storage, API proxy, deep links.
+- `references/ai-integration.md` — LLM API key protection, usage caps, prompt injection, and output sanitization.
+- `references/deployment.md` — Production configuration, security headers, and environment separation.
+- `references/data-access.md` — SQL injection prevention, ORM safety, and input validation.

.agents/skills/vibe-security/agents/openai.yaml

@@ -0,0 +1,8 @@
+interface:
+  display_name: "Vibe Security"
+  short_description: "Audits vibe-coded apps for common security vulnerabilities."
+  brand_color: "#DC2626"
+  default_prompt: "Use $vibe-security to audit my project for security issues."
+
+policy:
+  allow_implicit_invocation: true

.agents/skills/vibe-security/references/ai-integration.md

@@ -0,0 +1,61 @@
+# AI / LLM Integration Security
+
+## API Keys Are Server-Side Only
+
+AI API keys (OpenAI, Anthropic, Google, etc.) must never appear in client-side code. They allow unlimited API usage at your expense. A leaked key can drain thousands of dollars in minutes.
+
+- No `NEXT_PUBLIC_OPENAI_API_KEY`
+- No API keys in React Native / Expo bundles
+- No API keys in client-side JavaScript
+
+All AI API calls go through your backend. The client sends the user's message to your server; your server calls the AI API.
+
+## Spending Caps
+
+Set hard spending caps on every AI API provider:
+- OpenAI: Usage limits in dashboard
+- Anthropic: Spending limits in console
+- Google: Budget alerts in Cloud Console
+
+Also implement **per-user usage limits** in your application:
+- Track token usage per user in your database
+- Set daily/monthly caps per user or per tier
+- Return a clear error when limits are exceeded
+- Don't rely on the AI provider's caps alone — they may have lag
+
+## Prompt Injection
+
+User input must be sanitized before inclusion in prompts. Never concatenate raw user input into system prompts:
+
+```typescript
+// BAD: user can override system instructions
+const prompt = `You are a helpful assistant. User says: ${userInput}`;
+
+// BETTER: separate system and user messages
+const messages = [
+  { role: 'system', content: 'You are a helpful assistant.' },
+  { role: 'user', content: userInput },
+];
+```
+
+Even with separate messages, be aware that sophisticated prompt injection can still occur. For high-stakes applications, consider:
+- Input validation and filtering
+- Output validation before acting on LLM responses
+- Limiting the LLM's capabilities (no tool access for user-facing chat)
+
+## LLM Output Is Untrusted
+
+LLM responses should be treated as untrusted user input:
+
+- **Sanitize before rendering as HTML** — LLM output can contain script tags or event handlers
+- **Never execute LLM output as code** without sandboxing
+- **Validate tool/function call parameters** — if using function calling, validate all returned parameters against an allowlist and schema before executing
+
+## Tool / Function Calling
+
+If your application gives an LLM access to tools (database queries, API calls, file operations):
+- Restrict operations to a safe allowlist
+- Validate all parameters from the LLM against a schema
+- Use least-privilege access (read-only where possible)
+- Log all tool invocations for audit
+- Never let the LLM construct raw SQL or shell commands from user input

.agents/skills/vibe-security/references/authentication.md

@@ -0,0 +1,90 @@
+# Authentication & Authorization
+
+## JWT Handling
+
+- **Use `jwt.verify()`, never `jwt.decode()` alone.** `decode` reads the payload without checking the signature — an attacker can forge any payload.
+- **Explicitly reject `"alg": "none"`.** Some JWT libraries accept unsigned tokens if the algorithm is set to `"none"`. Your verification must reject this.
+- **Validate issuer, audience, and expiration** — not just the signature.
+
+```typescript
+// BAD: reads token without verifying signature
+const payload = jwt.decode(token);
+
+// GOOD: verifies signature, rejects tampered tokens
+const payload = jwt.verify(token, secret, {
+  algorithms: ['HS256'],
+  issuer: 'your-app',
+});
+```
+
+## Next.js Middleware Is Not Enough
+
+Next.js middleware runs at the edge and is convenient for auth checks, but it is **not a reliable sole auth layer**. CVE-2025-29927 demonstrated that middleware could be completely bypassed via a spoofed `x-middleware-subrequest` header.
+
+Always verify auth again in:
+- Server Actions
+- Route Handlers (`app/api/`)
+- Data access functions / database queries
+
+Middleware should be a convenience layer, not the only wall between an attacker and your data.
+
+## Server Actions Are Public Endpoints
+
+Server Actions compile into public POST endpoints. Anyone can call them with `curl`. AI assistants frequently generate Server Actions that assume they're only called by the UI:
+
+```typescript
+// BAD: no auth check, no input validation
+'use server';
+export async function deleteItem(id: string) {
+  await db.items.delete({ where: { id } });
+}
+
+// GOOD: validates input, authenticates, and authorizes
+'use server';
+export async function deleteItem(input: unknown) {
+  const parsed = schema.safeParse(input);
+  if (!parsed.success) return { error: 'Invalid input' };
+
+  const session = await auth();
+  if (!session?.user) redirect('/login');
+
+  // Authorize: verify ownership, not just login
+  await db.items.deleteMany({
+    where: { id: parsed.data.id, userId: session.user.id }
+  });
+}
+```
+
+Every Server Action needs three things at the top:
+1. **Input validation** (Zod or similar runtime schema)
+2. **Authentication** (verify the user is logged in)
+3. **Authorization** (verify the user owns the resource)
+
+## API Route Handlers
+
+Same rules apply to `app/api/` route handlers. Every route handler is a public endpoint. Authenticate and authorize at the top of every handler.
+
+## Data Leakage to Client Components
+
+Never pass entire database objects to Client Components. They may contain sensitive fields (hashed passwords, internal IDs, admin flags). Select only the fields the client needs:
+
+```typescript
+// BAD: leaks all fields to the client
+const user = await db.users.findUnique({ where: { id } });
+return <UserProfile user={user} />;
+
+// GOOD: select only needed fields
+const user = await db.users.findUnique({
+  where: { id },
+  select: { name: true, avatarUrl: true }
+});
+return <UserProfile user={user} />;
+```
+
+Use `import 'server-only'` at the top of data access modules to prevent them from being accidentally imported into Client Components.
+
+## Session & Token Storage
+
+- Store tokens in `HttpOnly + Secure + SameSite=Lax` cookies, **not localStorage**.
+- localStorage is accessible to any JavaScript on the page — a single XSS vulnerability exposes all tokens.
+- `HttpOnly` cookies are invisible to JavaScript and sent automatically by the browser.

.agents/skills/vibe-security/references/data-access.md

@@ -0,0 +1,79 @@
+# Data Access & Input Validation
+
+## SQL Injection
+
+Always use parameterized queries or ORM methods. Never concatenate user input into SQL strings:
+
+```typescript
+// BAD: SQL injection via string concatenation
+const result = await db.query(`SELECT * FROM users WHERE id = '${userId}'`);
+
+// GOOD: parameterized query
+const result = await db.query('SELECT * FROM users WHERE id = $1', [userId]);
+```
+
+## ORM Safety (Prisma)
+
+Even with an ORM, injection is possible:
+
+- **Validate input types with Zod before passing to Prisma.** `findFirst` and similar methods are vulnerable to operator injection if unvalidated objects are passed as filter values. An attacker can send `{ "email": { "contains": "" } }` to match all records.
+
+```typescript
+// BAD: raw request body passed directly to Prisma
+const user = await prisma.user.findFirst({ where: req.body });
+
+// GOOD: validate with Zod first
+const schema = z.object({ email: z.string().email() });
+const parsed = schema.parse(req.body);
+const user = await prisma.user.findFirst({ where: { email: parsed.email } });
+```
+
+- **Never use `$queryRawUnsafe` or `$executeRawUnsafe` with user-supplied input.** These bypass Prisma's parameterization entirely.
+
+```typescript
+// BAD: raw SQL with user input
+const results = await prisma.$queryRawUnsafe(
+  `SELECT * FROM users WHERE name = '${name}'`
+);
+
+// GOOD: use the safe raw query with parameters
+const results = await prisma.$queryRaw`
+  SELECT * FROM users WHERE name = ${name}
+`;
+```
+
+## Input Validation
+
+Validate all external input at system boundaries using a runtime schema validator (Zod, Yup, Joi, etc.):
+
+- API route handlers
+- Server Actions
+- Webhook handlers
+- Form submissions
+- URL parameters and query strings
+
+Don't rely on TypeScript types alone — they're compile-time only and don't exist at runtime. An attacker sending a malformed request bypasses all TypeScript checks.
+
+```typescript
+// TypeScript type provides NO runtime protection
+type CreateUserInput = { name: string; email: string };
+
+// Zod schema provides ACTUAL runtime validation
+const CreateUserSchema = z.object({
+  name: z.string().min(1).max(100),
+  email: z.string().email(),
+});
+```
+
+## Mass Assignment
+
+Don't spread request bodies directly into database operations. An attacker can add unexpected fields:
+
+```typescript
+// BAD: attacker can add { isAdmin: true, credits: 99999 }
+await db.users.update({ where: { id }, data: req.body });
+
+// GOOD: pick only allowed fields
+const { name, email } = validated.data;
+await db.users.update({ where: { id }, data: { name, email } });
+```