feat: add 3 new rules (25 total) - middleware-auth, api-validation, file-uploads

Author: vibestackdev

.cursor/rules/api-validation.mdc

@@ -0,0 +1,111 @@
+---
+description: API route validation — enforces Zod validation on all route handlers and server actions
+globs: ["**/api/**", "**/actions/**", "**/app/api/**"]
+alwaysApply: false
+---
+
+# API Route Validation Rules
+
+## RULE 1: NEVER Access Request Body Without Zod Validation
+
+Unvalidated request bodies are the #1 source of runtime crashes and injection vulnerabilities.
+Every API route MUST validate the incoming body with Zod before any processing.
+
+✅ CORRECT — validate first:
+```typescript
+import { z } from 'zod'
+import { NextRequest, NextResponse } from 'next/server'
+
+const CreatePostSchema = z.object({
+  title: z.string().min(1).max(200),
+  content: z.string().min(1).max(10000),
+  published: z.boolean().default(false),
+})
+
+export async function POST(request: NextRequest) {
+  const body = await request.json()
+
+  const result = CreatePostSchema.safeParse(body)
+  if (!result.success) {
+    return NextResponse.json(
+      { error: 'Invalid request', details: result.error.flatten() },
+      { status: 400 }
+    )
+  }
+
+  const { title, content, published } = result.data
+  // Now safe to use
+}
+```
+
+❌ WRONG — raw body access:
+```typescript
+export async function POST(request: NextRequest) {
+  const { title, content } = await request.json() // No validation — crashes on missing fields
+  // title could be undefined, an object, a number — anything
+}
+```
+
+## RULE 2: Validate Server Action Parameters With Zod
+
+Server Actions receive untyped FormData or direct calls — always validate.
+
+✅ CORRECT:
+```typescript
+'use server'
+import { z } from 'zod'
+
+const UpdateProfileSchema = z.object({
+  name: z.string().min(1).max(100),
+  bio: z.string().max(500).optional(),
+})
+
+export async function updateProfile(data: unknown) {
+  const result = UpdateProfileSchema.safeParse(data)
+  if (!result.success) {
+    return { error: result.error.flatten().fieldErrors }
+  }
+  // Process result.data safely
+}
+```
+
+## RULE 3: Always Return Consistent Error Shapes
+
+API routes must return a consistent error shape: `{ error: string, details?: unknown }`.
+Never expose raw error messages, stack traces, or database errors to the client.
+
+✅ CORRECT:
+```typescript
+try {
+  // ... operation
+} catch (error) {
+  console.error('[API_ERROR]', error) // Log server-side only
+  return NextResponse.json({ error: 'Internal server error' }, { status: 500 })
+}
+```
+
+❌ WRONG:
+```typescript
+} catch (error) {
+  return NextResponse.json({ error: error.message }, { status: 500 }) // Leaks internals
+}
+```
+
+## RULE 4: Authenticate Before Validating Business Logic
+
+Auth check always happens BEFORE any database operations, even with valid Zod data.
+
+```typescript
+export async function POST(request: NextRequest) {
+  // 1. Auth first
+  const supabase = await createClient()
+  const { data: { user } } = await supabase.auth.getUser()
+  if (!user) return NextResponse.json({ error: 'Unauthorized' }, { status: 401 })
+
+  // 2. Validate input
+  const result = Schema.safeParse(await request.json())
+  if (!result.success) return NextResponse.json({ error: 'Invalid' }, { status: 400 })
+
+  // 3. Business logic with trusted user and validated data
+}
+```

.cursor/rules/file-uploads.mdc

@@ -0,0 +1,97 @@
+---
+description: Image and file upload patterns — prevents insecure client-side uploads and missing file validation
+globs: ["**/api/upload/**", "**/actions/**", "**/components/**upload**", "**/app/**upload**"]
+alwaysApply: false
+---
+
+# File Upload Security Rules
+
+## RULE 1: NEVER Upload Directly From Client to Supabase Storage With the Anon Key
+
+Client-side uploads with the anon key allow users to upload to any bucket path.
+Always generate a signed upload URL server-side, scoped to the authenticated user.
+
+✅ CORRECT — server generates signed URL:
+```typescript
+// Server Action
+'use server'
+import { createClient } from '@/lib/supabase/server'
+
+export async function getUploadUrl(filename: string, contentType: string) {
+  const supabase = await createClient()
+  const { data: { user } } = await supabase.auth.getUser()
+  if (!user) throw new Error('Unauthorized')
+
+  // Scope the path to the user's ID — prevents path traversal
+  const path = `${user.id}/${Date.now()}-${filename}`
+
+  const { data, error } = await supabase.storage
+    .from('uploads')
+    .createSignedUploadUrl(path)
+
+  if (error) throw error
+  return { signedUrl: data.signedUrl, path }
+}
+```
+
+❌ WRONG — direct client upload with anon key:
+```typescript
+// Client Component -- exposes storage to manipulation
+const { data, error } = await supabase.storage
+  .from('uploads')
+  .upload(`${filename}`, file) // No user scoping — any path writable
+```
+
+## RULE 2: Validate File Type and Size Server-Side
+
+Client-side validation is bypassed trivially. Always re-validate on the server.
+
+✅ CORRECT:
+```typescript
+const ALLOWED_TYPES = ['image/jpeg', 'image/png', 'image/webp']
+const MAX_SIZE_BYTES = 5 * 1024 * 1024 // 5MB
+
+export async function POST(request: NextRequest) {
+  const formData = await request.formData()
+  const file = formData.get('file') as File
+
+  if (!file) return NextResponse.json({ error: 'No file provided' }, { status: 400 })
+  if (!ALLOWED_TYPES.includes(file.type)) {
+    return NextResponse.json({ error: 'Invalid file type' }, { status: 400 })
+  }
+  if (file.size > MAX_SIZE_BYTES) {
+    return NextResponse.json({ error: 'File too large' }, { status: 400 })
+  }
+  // Safe to process
+}
+```
+
+## RULE 3: Always Scope Storage Paths to User ID
+
+Storage paths must always be prefixed with the authenticated user's ID.
+This prevents users from reading or overwriting other users' files.
+
+```typescript
+// Pattern: userId/timestamp-originalFilename
+const storagePath = `${user.id}/${Date.now()}-${sanitizedFilename}`
+
+// RLS policy on the bucket should enforce: auth.uid()::text = (storage.foldername(name))[1]
+```
+
+## RULE 4: Use Next.js Image Component for Supabase Storage URLs
+
+Never use raw `<img>` tags with Supabase storage URLs. Configure Next.js image domains
+and use `<Image>` for automatic optimization and lazy loading.
+
+```typescript
+// next.config.js
+images: {
+  remotePatterns: [
+    {
+      protocol: 'https',
+      hostname: '*.supabase.co',
+      pathname: '/storage/v1/object/public/**',
+    },
+  ],
+},
+```

.cursor/rules/middleware-auth.mdc

@@ -0,0 +1,71 @@
+---
+description: Next.js middleware auth — prevents auth logic being placed in middleware instead of route handlers
+globs: ["**/middleware.ts", "**/middleware.tsx", "**/app/**"]
+alwaysApply: false
+---
+
+# Middleware Auth Rules
+
+## RULE 1: Middleware is for Session REFRESH, Not Auth Enforcement
+
+SECURITY CRITICAL: Next.js middleware CANNOT securely enforce authentication.
+Middleware runs on the Edge Runtime and cannot verify Supabase JWTs reliably.
+The ONLY job of middleware is to call `updateSession()` to refresh the token.
+
+✅ CORRECT — middleware only refreshes:
+```typescript
+// middleware.ts
+import { updateSession } from '@/lib/supabase/middleware'
+import { type NextRequest } from 'next/server'
+
+export async function middleware(request: NextRequest) {
+  return await updateSession(request) // Refresh only — no auth logic here
+}
+
+export const config = {
+  matcher: ['/((?!_next/static|_next/image|favicon.ico).*)'],
+}
+```
+
+❌ WRONG — do NOT put auth enforcement in middleware:
+```typescript
+// VULNERABILITY: middleware auth check can be bypassed
+export async function middleware(request: NextRequest) {
+  const session = await getSession() // Wrong: unreliable in Edge Runtime
+  if (!session) return NextResponse.redirect('/login') // Can be bypassed
+}
+```
+
+## RULE 2: Auth Enforcement Belongs in Layouts and Pages
+
+Every protected route must call `getUser()` server-side in the layout or page component.
+This is the cryptographically secure check.
+
+✅ CORRECT — auth in layout:
+```typescript
+// app/(protected)/layout.tsx
+import { createClient } from '@/lib/supabase/server'
+import { redirect } from 'next/navigation'
+
+export default async function ProtectedLayout({ children }: { children: React.ReactNode }) {
+  const supabase = await createClient()
+  const { data: { user } } = await supabase.auth.getUser()
+
+  if (!user) redirect('/login')
+
+  return <>{children}</>
+}
+```
+
+## RULE 3: Never Check Auth in Client Components
+
+Auth state from Client Components can be spoofed through browser devtools.
+The server-side `getUser()` call in layouts is the source of truth.
+
+❌ WRONG:
+```typescript
+'use client'
+// Do NOT gate features based on client-side auth state alone
+const { data: { user } } = await supabase.auth.getSession() // Untrusted
+if (!user) return <LoginPrompt />
+```