Review my app setup and highlight potential security threats.  
Explain them in plain business language with High/Medium/Low priority.  
Show the risk to customers and to the business.  
Suggest simple next steps a founder can assign to the team to fix them.  
End with a 3-sentence summary of overall risk.

COMPREHENSIVE SECURITY AUDIT AND FIX

Analyze my application for critical security vulnerabilities and implement fixes. Given the context provided [PASTE YOUR COMPLETE APP CODE HERE]:

Scan for and fix these 7 critical security issues:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. TRUSTING CLIENT DATA
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
FIND:
- Form inputs used directly without validation
- URL parameters inserted into queries/operations
- User input rendered without escaping
- Data from client used in database queries

FIX:
- Add server-side validation for ALL inputs (type, length, format)
- Sanitize data before database operations
- Escape output when rendering user content
- Use parameterized queries/prepared statements
- Implement input whitelisting, not just blacklisting

PROVIDE: Updated code with validation middleware/functions

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2. SECRETS IN FRONTEND CODE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
FIND:
- API keys, database credentials, or secrets in client-side code
- Hardcoded tokens in React/Next.js components
- Private keys or passwords in JavaScript files
- .env files not in .gitignore

FIX:
- Move ALL secrets to server-side environment variables
- Create/update .env file with proper variables
- Ensure .env is in .gitignore
- Use server-side API routes to call external services
- For Next.js: use NEXT_PUBLIC_ prefix ONLY for truly public values
- Never expose database credentials to client

PROVIDE: 
- Updated code with secrets removed from client
- .env.example file showing required variables
- .gitignore with .env listed

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
3. WEAK AUTHORIZATION
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
FIND:
- Routes that only check "is user logged in?"
- Missing permission checks for specific actions
- No role-based access control
- Frontend-only authorization logic

FIX:
- Implement permission checks on EVERY server endpoint
- Verify user roles/permissions for each action (read/write/delete)
- Check authorization at multiple levels: route, controller, data access
- Example checks needed:
  * Can this user view this resource?
  * Can this user edit this resource?
  * Can this user delete this resource?
- Never rely on frontend to hide/show features

PROVIDE: Authorization middleware and permission checking functions

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
4. LEAKY ERROR MESSAGES
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
FIND:
- Stack traces shown to users
- Database error messages exposed in API responses
- Detailed system information in error responses
- Console.logs with sensitive data in production

FIX:
- Return generic error messages to users: "Something went wrong"
- Log detailed errors server-side only
- Implement proper error handling middleware
- Different error responses for dev vs production
- Remove or conditionally disable console.logs in production

PROVIDE: Error handling middleware with safe user-facing messages

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
5. NO OWNERSHIP CHECKS (IDOR - Insecure Direct Object Reference)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
FIND:
- Endpoints like /api/user/123 that don't verify ownership
- Database queries using user-supplied IDs without permission check
- Ability to access/modify other users' data by changing URL parameters
- Resources accessed by predictable sequential IDs

FIX:
- Add ownership verification before EVERY resource access:
  * GET /api/expense/456 → verify current user owns expense 456
  * PUT /api/profile/789 → verify current user is user 789
  * DELETE /api/post/321 → verify current user created post 321
- Server must confirm: currentUserId === resource.ownerId
- Return 403 Forbidden if user doesn't own resource
- Consider using UUIDs instead of sequential IDs

PROVIDE: Ownership verification middleware/functions for all resource endpoints

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
6. IGNORING DATABASE-LEVEL SECURITY
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
FIND:
- No Row-Level Security (RLS) policies in database
- Application-only access control (bypassing database protections)
- Missing database constraints and foreign keys
- No database-level user isolation

FIX (if using PostgreSQL/Supabase/similar):
- Enable Row-Level Security on all tables
- Create RLS policies that enforce data access rules at database level
- Example policies:
  * Users can only SELECT their own rows (WHERE user_id = auth.uid())
  * Users can only UPDATE/DELETE rows they own
  * Public read but authenticated write
- Add database constraints for data integrity
- Use database roles/permissions properly

FIX (if using other databases):
- Implement equivalent access control at database layer
- Use database views for filtered data access
- Leverage database user permissions

PROVIDE: Database migration/setup scripts with security policies

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
7. UNPROTECTED APIs & SENSITIVE DATA
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
FIND:
- API endpoints with no rate limiting
- Sensitive data (passwords, SSNs, credit cards) stored in plain text
- HTTP instead of HTTPS
- No CORS configuration
- Authentication tokens in URLs or localStorage without protection

FIX:
- Add rate limiting middleware to all API routes
  * Example: 100 requests per 15 minutes per IP
  * Stricter limits for authentication endpoints
- Encrypt sensitive data at rest (use bcrypt for passwords)
- Never store plain text passwords or payment info
- Enforce HTTPS in production (redirect HTTP to HTTPS)
- Configure CORS to allow only specific origins
- Store auth tokens securely (httpOnly cookies preferred over localStorage)
- Add security headers (helmet.js for Node/Express)

PROVIDE: 
- Rate limiting middleware implementation
- Data encryption examples for sensitive fields
- Security headers configuration
- CORS setup

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

OUTPUT FORMAT:

For each vulnerability found, provide:

1. 🔴 VULNERABILITY FOUND:
   [Describe the specific issue in my code with line numbers/file names]

2. ⚠️ RISK LEVEL: Critical / High / Medium
   [Explain what could happen if exploited]

3. ✅ FIX IMPLEMENTATION:
   [Provide the complete corrected code]

4. 📝 EXPLANATION:
   [Briefly explain why this fix works]

After all fixes, provide:
- Summary checklist of all security improvements made
- Additional recommendations for my specific tech stack
- Testing steps to verify fixes work correctly

MY APPLICATION USES:
- Framework: [e.g., Next.js, Express, React + Node]
- Database: [e.g., PostgreSQL, MongoDB, Supabase, Firebase]
- Authentication: [e.g., JWT, session-based, NextAuth, Supabase Auth]
- Hosting: [e.g., Vercel, Netlify, AWS, self-hosted]

Begin security audit now.

SECURITY CHECKLIST & AUTO-FIX

Given my application code [PASTE CODE], go through this security checklist and fix every issue found:

☐ 1. Client Data Validation: Add server-side validation for all inputs
☐ 2. Secret Management: Move all API keys/credentials to server-side .env
☐ 3. Authorization: Add permission checks on every protected endpoint
☐ 4. Error Handling: Replace detailed errors with generic user messages
☐ 5. Ownership Verification: Confirm users can only access their own data
☐ 6. Database Security: Implement Row-Level Security or equivalent
☐ 7. API Protection: Add rate limiting, encrypt sensitive data, enforce HTTPS

For each item:
- Search my code for violations
- Provide the fixed code
- Mark [✓] when implemented

Tech stack: [YOUR STACK]