Security Review for an AI SaaS

Problem this prompt solves

AI features create new abuse paths on top of classic web bugs: users inject instructions into content you later send to a model, IDORs on generation ids leak someone else’s output, and verbose errors reveal system prompts. A useful review prioritises exploitable issues in authz, data access, and model tool boundaries — not a theoretical threat catalog.

When to use it

• You process user content with LLMs and have not threat-modeled prompt injection.
• You are pre-beta or pre-paid and need a security pass beyond “HTTPS on Vercel.”
• You added tool-calling, webhooks, or service-role paths that bypass RLS.
• You store sensitive inputs/outputs and need retention and access clarity.

Conduct a security review of this AI SaaS codebase and fix critical issues.

Scope:
- Authentication and session handling (Next.js + Supabase)
- Authorisation and RLS (IDOR on resources and ai_runs)
- Secret management (OpenAI, service role, webhook secrets)
- AI-specific risks: prompt injection, system prompt leakage, unsafe tool/function calling, SSRF via model tools if present
- File/storage access if used
- Logging/PII leakage
- Dependency debug endpoints and misconfigured CORS

Output SECURITY_REVIEW.md with:
- Threat summary (top 5 realistic attacks)
- Findings table: severity (Critical/High/Medium/Low), evidence, impact, fix
- Residual risks accepted for MVP

Fixes to implement now when found:
1) Any unauthenticated or cross-user access to private data/generations
2) Service role or API keys reachable from the client
3) Webhooks without signature verification
4) AI tools that can fetch arbitrary URLs or read server files based on model output — disable or tightly allow-list
5) Overly verbose errors that return system prompts or stack traces to clients

Hardening guidance to apply where practical:
- Separate untrusted user content from system instructions in the prompt structure
- Treat model output as untrusted; validate before DB writes or side effects
- Minimise data sent to the model; redact secrets from context
- Rate limit sensitive routes

Do not claim “secure” or “compliant.” This is an engineering review, not a certification. Do not expand into a full SOC2 programme.

Expected result

A SECURITY_REVIEW.md with realistic threats and evidence-based findings, plus patches for critical authz/secret/tooling issues and clearer prompt/data boundaries for LLM calls.

Implementation notes

• Prompt injection is about trust boundaries — assume user-owned documents can contain hostile instructions.
• Never let the model choose arbitrary SQL, shell, or URLs without an allow-list and server-side checks.
• Service-role bypasses RLS; every use needs a comment justifying why and what authz was enforced in code.
• Store fewer secrets in logs than you think you need; run ids beat payloads.
• If you return model refusals to users, scrub system prompt echoes.
• Re-test RLS with two real users after any policy change — SQL typos fail open more often than you expect.

Testing checklist

• User B cannot GET/PUT user A’s resources or ai_runs by UUID guessing.
• Client bundle / network responses contain no API keys or service-role key.
• Webhook endpoints reject unsigned or badly signed payloads.
• Planted injection text in user content cannot exfiltrate system env vars via the model response path you ship.
• Tool/function calling (if any) cannot hit internal IPs or file:// URLs.
• Error responses in production do not include stack traces or system prompts.
• Storage URLs (if any) are not listable/public for private objects.

Common mistakes

• Checking only XSS on the marketing site while AI routes ignore auth.
• Believing “the model won’t follow bad instructions” is a control.
• Using service role for all DB access because RLS was hard.
• Echoing the full upstream OpenAI error to the browser.
• Logging prompts that contain passwords users pasted into documents.
• Calling the review “GDPR compliant” without legal review — keep claims engineering-scoped.