# Security Audit Prompt

**Act as a Senior Application Security Engineer and Penetration Tester.**

I need you to audit my current codebase for "App Killer" vulnerabilities. Review my frontend, backend, and database definitions. Be extremely critical. Specifically, I want you to look for and fix the following four vulnerabilities based on real-world incident reports:

---

## 1. The "Free Premium" Exploit (RLS & Schema Audit)

- Analyze my database schema (specifically Supabase/PostgreSQL definitions).
- **Check:** Am I storing sensitive system-controlled data (e.g., `is_premium`, `subscription_tier`, `credits_remaining`, `user_rate_limit`) in the same table where users have `UPDATE` permissions?
- **Attack Vector:** Can a user send a custom API request to modify their own row and give themselves free premium or infinite credits?
- **Task:** If this vulnerability exists, refactor the schema to move these fields to a separate `protected_user_data` table OR write a strict RLS policy that limits user `UPDATE` access to *only* safe columns (e.g., `display_name`).

---

## 2. The "Leaky Key" Check (Frontend Audit)

- Scan all client-side files.
- **Check:** Are there any direct fetch calls to `api.openai.com`, `openrouter.ai`, or `anthropic.com` originating from the frontend? Are any environment variables containing keys (like `NEXT_PUBLIC_API_KEY`) exposed to the browser?
- **Task:** If found, refactor this immediately. Create a backend API route (Edge Function) that acts as a proxy. The frontend should call my backend, and *only* the backend should hold the keys and call the AI provider.

---

## 3. The "Bankruptcy" Prevention (Rate Limiting Logic)

- Review the backend logic where I process AI requests.
- **Check:** Do I verify the user's rate limit *before* making the expensive API call? Do I have a check for IP-based rate limiting to stop multi-account spamming?
- **Task:** Implement a check that verifies `current_usage < max_limit` before executing the external request. If they exceed it, throw a 429 error immediately.

---

## 4. The "Circular Dependency" Check (Error Handling)

- Look at how I handle database connection failures.
- **Check:** If my main database is offline, does the app crash/white-screen? Do I try to fetch the "System Status" message *from* the database that might be down?
- **Task:** Ensure that if the backend fails, the app degrades gracefully (e.g., "Offline Mode") rather than crashing.

---

## Output Format

- **🚨 Critical Vulnerability Found:** [Description]
- **🛡️ Proposed Fix:** [Code Snippet]
- **✅ Verification:** [How to test the fix]