Comprehensive security audit and report for Next.js app, with severity and grading.

Loading PromptJoy

Prompt body

19,208 chars3,031 wordsRoleInputsOutputRulesSafety

You are working in my Next.js app repo as a defensive security auditor.

Goal:
Perform a comprehensive read-only security audit of this generic Next.js application and return a graded report with findings prioritized by severity.

Important:
- Do not edit files.
- Do not write code.
- Do not create files.
- Do not install packages.
- Do not run destructive commands.
- Do not perform active attacks.
- Do not brute force anything.
- Do not call production services unless the repo already has safe local test commands.
- Do not print secret values.
- Do not rotate secrets.
- Do not make assumptions without labeling them.
- This is an audit-only task.

You may inspect the codebase, configuration files, package files, middleware, route handlers, API routes, server actions, auth logic, environment variable usage, and documentation.

Primary output:
Return a graded security report with:
1. Overall security grade.
2. Executive summary.
3. Findings prioritized by severity.
4. Evidence for each finding.
5. Risk explanation.
6. Affected files and routes.
7. Recommended remediation.
8. Priority order for fixes.
9. Manual follow-up checklist.
10. Confidence level for each finding.

Severity levels:
- Critical: likely account takeover, auth bypass, exposed production secret, private data exposure, payment abuse, admin bypass, remote code execution, or public write access to private data.
- High: broken authorization, missing protection on sensitive mutation routes, severe rate limit gap, unsafe token/session handling, broad CORS on authenticated routes, exposed admin functionality, or webhook signature risk.
- Medium: missing important security headers, weak CSP, inconsistent validation, overly verbose errors, missing CSRF protection on cookie-authenticated mutations, weak webhook handling, or missing rate limits on abuse-prone endpoints.
- Low: minor hardening gaps, missing docs, incomplete logs, inconsistent cookie attributes, weak defaults, or cleanup items.
- Info: useful observations that are not immediately exploitable.

Grading:
Give the app one overall grade:
- A: Strong security posture. Only minor hardening items.
- B: Generally solid, with some medium-risk gaps.
- C: Usable but several meaningful security issues need attention.
- D: Serious security gaps that should be fixed before production growth.
- F: Critical issues or multiple high-risk flaws that make the app unsafe for production.

Also provide category grades:
- Security headers.
- Secrets handling.
- Environment variable safety.
- Authentication.
- Authorization.
- Rate limiting.
- API route security.
- Session and cookie security.
- CSRF protection.
- CORS.
- Input validation.
- Webhook security.
- File upload security if uploads exist.
- Payment and billing security if payments exist.
- Admin route security.
- Logging and error leakage.
- Dependency risk.
- Public/private route separation.

First inspect the repo:
1. Detect whether this is Next.js App Router, Pages Router, or mixed.
2. Find public routes, private routes, API routes, route handlers, middleware, server actions, and edge functions.
3. Find auth-related files.
4. Find session, cookie, token, JWT, OAuth, magic link, password, role, workspace, or permission logic.
5. Find database client usage.
6. Find environment variable usage.
7. Find file upload, webhook, payment, email, analytics, admin, and user-generated content code.
8. Find security headers, CSP, CORS, redirects, rewrites, middleware, and next.config files.
9. Find places where user input reaches a database, API call, HTML rendering, file path, redirect, email, webhook, or third-party service.
10. Find existing tests, linting, typecheck, and build commands, but do not modify them.

Security headers audit:
Check whether the app sets strong headers globally and on sensitive routes.

Review:
- Strict-Transport-Security.
- Content-Security-Policy.
- X-Content-Type-Options.
- Referrer-Policy.
- Permissions-Policy.
- X-Frame-Options or CSP frame-ancestors.
- Cross-Origin-Opener-Policy where appropriate.
- Cross-Origin-Resource-Policy where appropriate.
- Cross-Origin-Embedder-Policy only if appropriate.
- Cache-Control on sensitive authenticated responses.
- Static asset behavior.
- API route behavior.

Report:
- What headers exist.
- What headers are missing.
- Whether the CSP is missing, weak, overly broad, or likely to break if tightened.
- Whether sensitive responses could be cached.
- Recommended header policy.

Secrets audit:
Search for secrets safely.

Check:
- .env files.
- .env.local.
- .env.production.
- .env.development.
- .env.example.
- next.config files.
- Vercel config.
- source files.
- test files.
- scripts.
- markdown docs.
- JSON files.
- package scripts.
- GitHub Actions or CI configs.
- Docker files.
- Supabase config if present.
- public directory.
- client components.
- browser-exposed code.

Look for:
- API keys.
- JWT secrets.
- OAuth client secrets.
- Supabase service role keys.
- Database URLs.
- Stripe secret keys.
- Stripe webhook secrets.
- Resend or email provider keys.
- OpenAI or LLM provider keys.
- Private tokens.
- Session secrets.
- Encryption keys.
- Webhook signing secrets.
- Admin passwords.
- Hardcoded credentials.
- Bearer tokens.
- Basic auth credentials.
- Private URLs with credentials.
- Secrets accidentally prefixed with NEXT_PUBLIC_.
- Server-only values imported into client components.
- Secrets passed to props that render client-side.
- Secrets used in logs or error messages.
- Secrets included in public JSON, static files, generated metadata, sitemap, robots, or llms files.

Rules:
- Never print full secret values.
- If a secret is found, report only file, line number if available, variable name or type, and redacted preview such as sk_live_...abcd.
- Mark exposed committed secrets as Critical or High depending on blast radius.
- Recommend rotation where appropriate.
- Do not rotate anything.

Environment variable audit:
Check:
- Which env vars are used client-side.
- Which env vars are used server-side.
- Which env vars are used in middleware.
- Which env vars are used at build time.
- Whether private values use NEXT_PUBLIC_.
- Whether public env vars are actually safe to expose.
- Whether missing env vars fail safely.
- Whether production, preview, and development env handling is documented.
- Whether server-only env values can leak into the browser bundle.

Authentication audit:
Inspect:
- Login.
- Signup.
- Logout.
- Magic link.
- OAuth callback.
- Password reset.
- Email verification.
- Session refresh.
- Token exchange.
- Invite acceptance.
- Workspace switching.
- Role changes.
- Admin login.
- Account deletion.
- Billing portal access.
- Checkout creation.
- Webhook handling.
- Any route that assumes auth from client state.

Look for:
- Missing server-side auth checks.
- Client-only auth guards.
- Private pages protected only by UI hiding.
- API routes that trust userId from request body.
- API routes that trust workspaceId from request body without membership checks.
- Missing role checks.
- Missing ownership checks.
- Broken object level authorization.
- Broken function level authorization.
- Admin actions callable by non-admins.
- Users able to access other users’ records by changing IDs or slugs.
- Users able to change their role, plan, limits, or billing state directly.
- Insecure redirects after login.
- OAuth callback open redirect issues.
- Sessions not invalidated on logout.
- Sensitive actions not requiring fresh auth or confirmation.
- Missing email verification checks where required.
- Missing account disabled or deleted checks.
- Auth middleware that protects pages but not APIs.
- APIs protected but server actions unprotected.
- Webhooks without signature verification.
- Test or preview auth bypasses enabled in production.

Authorization audit:
Map protected resources.

For each protected resource, determine:
- Who can create it.
- Who can read it.
- Who can update it.
- Who can delete it.
- Who can invite others.
- Who can export it.
- Who can see billing.
- Who can change settings.
- Who can trigger expensive jobs.
- Who can access admin or support views.

Look for IDOR and BOLA issues:
- Direct access by numeric ID.
- Direct access by UUID.
- Slug-based access without ownership check.
- Workspace ID changed in request.
- User ID changed in request.
- Query filters missing user or workspace scope.
- Database updates missing user or workspace scope.
- Deletes missing user or workspace scope.
- Public sharing links that do not validate visibility.
- Soft-deleted records still accessible.
- Draft or private records accessible through public routes.
- Admin APIs hidden in UI but callable directly.

If Supabase or Postgres RLS exists:
- Check whether RLS is enabled on sensitive tables.
- Review policies if available in repo.
- Check whether service role keys are server-only.
- Check whether user-facing routes use admin clients unnecessarily.
- Check whether client queries can bypass ownership rules.

Rate limiting audit:
Find all endpoints and actions that should have rate limits.

Prioritize:
- Login.
- Signup.
- Magic link requests.
- Password reset.
- Email sending.
- Invite sending.
- Contact forms.
- Waitlists.
- Public forms.
- AI or LLM endpoints.
- Expensive generation endpoints.
- File uploads.
- Search endpoints.
- Checkout creation.
- Billing portal creation.
- API routes that write data.
- API routes that call paid third-party services.
- API routes that read large data sets.
- Admin actions.
- User-generated content actions.

Report:
- Existing rate limit strategy.
- Which endpoints are protected.
- Which endpoints are missing limits.
- Whether rate limiting is per IP, user, email, workspace, session, or API key.
- Whether rate limiting is persistent across serverless instances.
- Whether in-memory limits are being used in production.
- Whether limits can be bypassed with spoofed headers.
- Recommended limit strategy by endpoint type.

Session and cookie audit:
Check:
- Cookie attributes.
- HttpOnly.
- Secure.
- SameSite.
- Path.
- Domain.
- Expiration.
- Session rotation.
- Session invalidation.
- Logout behavior.
- Refresh token storage.
- JWT storage.
- Whether tokens are stored in localStorage or sessionStorage.
- Whether tokens are exposed to JavaScript unnecessarily.
- Whether session IDs are regenerated after auth state changes.
- Whether sensitive operations require valid fresh auth.

CSRF audit:
Determine whether the app uses cookie-based auth, bearer-token auth, or mixed auth.

If cookie-based auth is used, inspect all state-changing requests:
- POST.
- PUT.
- PATCH.
- DELETE.
- Server actions.
- Form submissions.
- API mutations.
- Checkout and billing actions.
- Account settings.
- Workspace settings.
- Invite actions.

Check:
- Are state-changing requests protected against CSRF?
- Are SameSite cookies configured?
- Are Origin or Referer headers validated on sensitive mutations?
- Is there a CSRF token strategy?
- Are custom headers required for API mutations?
- Are GET routes incorrectly changing state?
- Are login and logout protected appropriately?
- Are server actions protected sufficiently?
- Are webhook routes exempt from browser CSRF but protected by signature verification?

CORS audit:
Inspect all CORS headers and handlers.

Look for:
- Access-Control-Allow-Origin: *
- Wildcard origin on authenticated routes.
- Access-Control-Allow-Credentials: true with broad origins.
- Overly broad allowed methods.
- Overly broad allowed headers.
- Missing OPTIONS handling where CORS is intentionally supported.
- CORS used as auth.
- API routes exposed cross-origin without need.

API route and server action audit:
For every route handler, API route, and server action, check:
- Auth required.
- Authorization required.
- Rate limit required.
- Input validation present.
- Output filtered.
- Sensitive data excluded.
- Correct HTTP methods.
- Correct status codes.
- Request body size limits.
- Error messages safe.
- Logs safe.
- CSRF protection needed.
- CORS needed.
- Cache disabled for private data.
- Webhook signature verified if webhook.
- Idempotency required.
- Replay protection needed.
- Paid third-party API abuse possible.

Input validation and injection audit:
Inspect:
- Database queries.
- Raw SQL.
- ORM usage.
- Supabase filters.
- Search params.
- Dynamic route params.
- Form submissions.
- Webhook payloads.
- JSON parsing.
- Markdown or MDX rendering.
- HTML rendering.
- dangerouslySetInnerHTML.
- Redirect URLs.
- File paths.
- Shell commands.
- Email templates.
- Third-party API calls.

Look for:
- Missing validation.
- Unsafe string interpolation.
- SQL injection risk.
- XSS risk.
- Open redirect risk.
- Path traversal risk.
- Command injection risk.
- SSRF risk.
- Unsafe markdown rendering.
- Unsafe HTML rendering.
- User input passed to metadata or JSON-LD without escaping.
- User input passed to emails without safe handling.
- User input used to build URLs to internal services.

File upload audit if uploads exist:
Check:
- Auth required.
- Authorization required.
- File size limits.
- File type validation.
- MIME type validation not trusted alone.
- Extension validation.
- Storage bucket privacy.
- Public vs private file access.
- Signed URL expiry.
- Malware scanning if relevant.
- Image processing safety.
- SVG handling.
- User file names sanitized.
- Path traversal impossible.
- Upload rate limits.
- Download authorization.
- Metadata stripping if sensitive.
- Direct upload policies.

Webhook audit if webhooks exist:
Check:
- Signature verification.
- Raw body handling.
- Replay protection if supported.
- Idempotency.
- Event type allowlist.
- Safe error handling.
- Auth middleware not breaking provider signatures.
- No blind trust of event payload for user identity or plan changes.
- Rate limiting or abuse controls where appropriate.
- Logs do not include full sensitive payloads.
- Webhook secrets are server-only.

Payment and billing audit if payments exist:
Check:
- Checkout session creation requires auth.
- Price IDs are server-controlled, not client-controlled.
- User cannot set their own plan, price, trial, credits, or limits.
- Billing portal session requires auth and ownership.
- Stripe customer ID is bound to authenticated user or workspace.
- Webhook is source of truth for subscription state.
- Webhook signature is verified.
- Webhook events are idempotent.
- Subscription status cannot be spoofed by client requests.
- Server checks plan limits before paid actions.
- Credit or usage counters cannot be directly manipulated by users.

Admin security audit:
Check:
- Admin routes are not just hidden in the UI.
- Admin APIs require server-side admin role checks.
- Admin role cannot be self-assigned.
- Admin pages are excluded from sitemap and public nav.
- Admin routes are noindexed.
- Admin data is not fetched in public layouts.
- Admin logs do not expose secrets.
- Support impersonation, if present, is audited and logged.

Logging and error handling audit:
Check:
- Secrets in logs.
- Tokens in logs.
- Full webhook payloads in logs.
- Passwords or magic links in logs.
- PII in logs.
- Stack traces in production responses.
- Error boundaries leaking details.
- API errors leaking database or provider details.
- Console logs in production-sensitive paths.

Dependency audit:
Inspect:
- package.json.
- lockfile.
- Next.js version.
- React version.
- Auth library version.
- Database client version.
- Markdown or HTML sanitizer libraries.
- File upload libraries.
- Image processing libraries.
- JWT libraries.
- Crypto usage.

Do not upgrade anything.
Only report risks and recommended updates.

Middleware audit:
Inspect middleware.ts if present.

Check:
- Correct matcher.
- Private routes protected.
- API routes protected where needed.
- Auth bypasses.
- Locale or rewrite behavior that skips auth.
- Redirect loops.
- Open redirects.
- Preview mode bypasses.
- Static assets excluded correctly.
- Admin routes protected.
- Middleware does not rely on client state.
- Middleware does not expose secrets.

Public/private route audit:
Create a route inventory.

Classify routes as:
- Public indexable.
- Public noindex.
- Auth required.
- Admin required.
- API public.
- API protected.
- Webhook.
- Internal.
- Unknown.

Check:
- Private routes are not included in sitemap.
- Private routes are not linked from public metadata.
- Private routes have noindex if rendered.
- Private route data is not fetched in public layouts.
- Public pages do not expose private state.

Output format:
Return the report in this exact structure.

# Security Audit Report

## Overall Grade
Grade:
Rationale:

## Category Grades
| Category | Grade | Rationale |
|---|---:|---|
| Security headers |  |  |
| Secrets handling |  |  |
| Environment variable safety |  |  |
| Authentication |  |  |
| Authorization |  |  |
| Rate limiting |  |  |
| API route security |  |  |
| Session and cookie security |  |  |
| CSRF protection |  |  |
| CORS |  |  |
| Input validation |  |  |
| Webhook security |  |  |
| File upload security |  |  |
| Payment and billing security |  |  |
| Admin route security |  |  |
| Logging and error leakage |  |  |
| Dependency risk |  |  |
| Public/private route separation |  |  |

## Executive Summary
Summarize the most important risks in plain English.

## Top Priority Fixes
List the highest leverage fixes in order.

Use this format:
1. [Severity] Finding title
   - Why it matters:
   - Where:
   - Recommended fix:
   - Confidence:

## Findings by Severity

### Critical
For each finding:
- Title:
- Severity:
- Confidence:
- Evidence:
- Affected files/routes:
- Risk:
- Recommended remediation:
- Notes:

### High
Use the same format.

### Medium
Use the same format.

### Low
Use the same format.

### Informational
Use the same format.

## Route Inventory
| Route or pattern | Type | Auth required | Risk notes |
|---|---|---:|---|

## API and Server Action Inventory
| Endpoint/action | Method | Auth | Authorization | Rate limit | Validation | Notes |
|---|---|---:|---:|---:|---:|---|

## Secrets Review
Do not print secret values.

| Finding | File | Line | Type | Exposure risk | Recommended action |
|---|---|---:|---|---|---|

## Rate Limit Review
| Endpoint/action | Current protection | Risk | Recommended limit |
|---|---|---|---|

## Auth and Authorization Review
Summarize the auth model and the biggest risks.

## Headers and CSP Review
List current headers and recommended changes.

## CORS and CSRF Review
Summarize current state and risks.

## Dependency Review
List risky or outdated dependencies if found.

## Manual Follow-Up Checklist
Create a practical checklist ordered by priority.

## Assumptions and Unknowns
List anything you could not verify from the repo.

## Commands Run
List only read-only commands used.
If no commands were run, say so.

Rules for final answer:
- Do not include full secrets.
- Do not include exploit instructions.
- Do not include code patches.
- Do not modify files.
- Be specific and evidence-based.
- If something is not found, say “not found in repo” rather than assuming it is absent in production.
- Prioritize practical production risk over theoretical issues.

Votes

Saves

Copies

Prompt Score Breakdown

Trust score

Combines all prompt score categories using the current rubric.

Task clarity

+8 detected coding-agent prompt mode (67% confidence)

Input contract

+28 provides repo, stack, environment, and implementation context for a coding agent

Output contract

+22 defines concrete implementation deliverables

Guardrails

+26 includes explicit constraints

Safety

100

+14 mentions sensitive data only inside redaction and reporting boundaries

Reusability

+18 separates context, output, and rules into readable blocks

Community signal

+24 has 4 up-votes

RemixRemix Prompt

Comprehensive security audit and report for Next.js app, with severity and grading. | PromptJoy

Prompt body

19,208 chars3,031 wordsRoleInputsOutputRulesSafety

You are working in my Next.js app repo as a defensive security auditor.

Goal:
Perform a comprehensive read-only security audit of this generic Next.js application and return a graded report with findings prioritized by severity.

Important:
- Do not edit files.
- Do not write code.
- Do not create files.
- Do not install packages.
- Do not run destructive commands.
- Do not perform active attacks.
- Do not brute force anything.
- Do not call production services unless the repo already has safe local test commands.
- Do not print secret values.
- Do not rotate secrets.
- Do not make assumptions without labeling them.
- This is an audit-only task.

You may inspect the codebase, configuration files, package files, middleware, route handlers, API routes, server actions, auth logic, environment variable usage, and documentation.

Primary output:
Return a graded security report with:
1. Overall security grade.
2. Executive summary.
3. Findings prioritized by severity.
4. Evidence for each finding.
5. Risk explanation.
6. Affected files and routes.
7. Recommended remediation.
8. Priority order for fixes.
9. Manual follow-up checklist.
10. Confidence level for each finding.

Severity levels:
- Critical: likely account takeover, auth bypass, exposed production secret, private data exposure, payment abuse, admin bypass, remote code execution, or public write access to private data.
- High: broken authorization, missing protection on sensitive mutation routes, severe rate limit gap, unsafe token/session handling, broad CORS on authenticated routes, exposed admin functionality, or webhook signature risk.
- Medium: missing important security headers, weak CSP, inconsistent validation, overly verbose errors, missing CSRF protection on cookie-authenticated mutations, weak webhook handling, or missing rate limits on abuse-prone endpoints.
- Low: minor hardening gaps, missing docs, incomplete logs, inconsistent cookie attributes, weak defaults, or cleanup items.
- Info: useful observations that are not immediately exploitable.

Grading:
Give the app one overall grade:
- A: Strong security posture. Only minor hardening items.
- B: Generally solid, with some medium-risk gaps.
- C: Usable but several meaningful security issues need attention.
- D: Serious security gaps that should be fixed before production growth.
- F: Critical issues or multiple high-risk flaws that make the app unsafe for production.

Also provide category grades:
- Security headers.
- Secrets handling.
- Environment variable safety.
- Authentication.
- Authorization.
- Rate limiting.
- API route security.
- Session and cookie security.
- CSRF protection.
- CORS.
- Input validation.
- Webhook security.
- File upload security if uploads exist.
- Payment and billing security if payments exist.
- Admin route security.
- Logging and error leakage.
- Dependency risk.
- Public/private route separation.

First inspect the repo:
1. Detect whether this is Next.js App Router, Pages Router, or mixed.
2. Find public routes, private routes, API routes, route handlers, middleware, server actions, and edge functions.
3. Find auth-related files.
4. Find session, cookie, token, JWT, OAuth, magic link, password, role, workspace, or permission logic.
5. Find database client usage.
6. Find environment variable usage.
7. Find file upload, webhook, payment, email, analytics, admin, and user-generated content code.
8. Find security headers, CSP, CORS, redirects, rewrites, middleware, and next.config files.
9. Find places where user input reaches a database, API call, HTML rendering, file path, redirect, email, webhook, or third-party service.
10. Find existing tests, linting, typecheck, and build commands, but do not modify them.

Security headers audit:
Check whether the app sets strong headers globally and on sensitive routes.

Review:
- Strict-Transport-Security.
- Content-Security-Policy.
- X-Content-Type-Options.
- Referrer-Policy.
- Permissions-Policy.
- X-Frame-Options or CSP frame-ancestors.
- Cross-Origin-Opener-Policy where appropriate.
- Cross-Origin-Resource-Policy where appropriate.
- Cross-Origin-Embedder-Policy only if appropriate.
- Cache-Control on sensitive authenticated responses.
- Static asset behavior.
- API route behavior.

Report:
- What headers exist.
- What headers are missing.
- Whether the CSP is missing, weak, overly broad, or likely to break if tightened.
- Whether sensitive responses could be cached.
- Recommended header policy.

Secrets audit:
Search for secrets safely.

Check:
- .env files.
- .env.local.
- .env.production.
- .env.development.
- .env.example.
- next.config files.
- Vercel config.
- source files.
- test files.
- scripts.
- markdown docs.
- JSON files.
- package scripts.
- GitHub Actions or CI configs.
- Docker files.
- Supabase config if present.
- public directory.
- client components.
- browser-exposed code.

Look for:
- API keys.
- JWT secrets.
- OAuth client secrets.
- Supabase service role keys.
- Database URLs.
- Stripe secret keys.
- Stripe webhook secrets.
- Resend or email provider keys.
- OpenAI or LLM provider keys.
- Private tokens.
- Session secrets.
- Encryption keys.
- Webhook signing secrets.
- Admin passwords.
- Hardcoded credentials.
- Bearer tokens.
- Basic auth credentials.
- Private URLs with credentials.
- Secrets accidentally prefixed with NEXT_PUBLIC_.
- Server-only values imported into client components.
- Secrets passed to props that render client-side.
- Secrets used in logs or error messages.
- Secrets included in public JSON, static files, generated metadata, sitemap, robots, or llms files.

Rules:
- Never print full secret values.
- If a secret is found, report only file, line number if available, variable name or type, and redacted preview such as sk_live_...abcd.
- Mark exposed committed secrets as Critical or High depending on blast radius.
- Recommend rotation where appropriate.
- Do not rotate anything.

Environment variable audit:
Check:
- Which env vars are used client-side.
- Which env vars are used server-side.
- Which env vars are used in middleware.
- Which env vars are used at build time.
- Whether private values use NEXT_PUBLIC_.
- Whether public env vars are actually safe to expose.
- Whether missing env vars fail safely.
- Whether production, preview, and development env handling is documented.
- Whether server-only env values can leak into the browser bundle.

Authentication audit:
Inspect:
- Login.
- Signup.
- Logout.
- Magic link.
- OAuth callback.
- Password reset.
- Email verification.
- Session refresh.
- Token exchange.
- Invite acceptance.
- Workspace switching.
- Role changes.
- Admin login.
- Account deletion.
- Billing portal access.
- Checkout creation.
- Webhook handling.
- Any route that assumes auth from client state.

Look for:
- Missing server-side auth checks.
- Client-only auth guards.
- Private pages protected only by UI hiding.
- API routes that trust userId from request body.
- API routes that trust workspaceId from request body without membership checks.
- Missing role checks.
- Missing ownership checks.
- Broken object level authorization.
- Broken function level authorization.
- Admin actions callable by non-admins.
- Users able to access other users’ records by changing IDs or slugs.
- Users able to change their role, plan, limits, or billing state directly.
- Insecure redirects after login.
- OAuth callback open redirect issues.
- Sessions not invalidated on logout.
- Sensitive actions not requiring fresh auth or confirmation.
- Missing email verification checks where required.
- Missing account disabled or deleted checks.
- Auth middleware that protects pages but not APIs.
- APIs protected but server actions unprotected.
- Webhooks without signature verification.
- Test or preview auth bypasses enabled in production.

Authorization audit:
Map protected resources.

For each protected resource, determine:
- Who can create it.
- Who can read it.
- Who can update it.
- Who can delete it.
- Who can invite others.
- Who can export it.
- Who can see billing.
- Who can change settings.
- Who can trigger expensive jobs.
- Who can access admin or support views.

Look for IDOR and BOLA issues:
- Direct access by numeric ID.
- Direct access by UUID.
- Slug-based access without ownership check.
- Workspace ID changed in request.
- User ID changed in request.
- Query filters missing user or workspace scope.
- Database updates missing user or workspace scope.
- Deletes missing user or workspace scope.
- Public sharing links that do not validate visibility.
- Soft-deleted records still accessible.
- Draft or private records accessible through public routes.
- Admin APIs hidden in UI but callable directly.

If Supabase or Postgres RLS exists:
- Check whether RLS is enabled on sensitive tables.
- Review policies if available in repo.
- Check whether service role keys are server-only.
- Check whether user-facing routes use admin clients unnecessarily.
- Check whether client queries can bypass ownership rules.

Rate limiting audit:
Find all endpoints and actions that should have rate limits.

Prioritize:
- Login.
- Signup.
- Magic link requests.
- Password reset.
- Email sending.
- Invite sending.
- Contact forms.
- Waitlists.
- Public forms.
- AI or LLM endpoints.
- Expensive generation endpoints.
- File uploads.
- Search endpoints.
- Checkout creation.
- Billing portal creation.
- API routes that write data.
- API routes that call paid third-party services.
- API routes that read large data sets.
- Admin actions.
- User-generated content actions.

Report:
- Existing rate limit strategy.
- Which endpoints are protected.
- Which endpoints are missing limits.
- Whether rate limiting is per IP, user, email, workspace, session, or API key.
- Whether rate limiting is persistent across serverless instances.
- Whether in-memory limits are being used in production.
- Whether limits can be bypassed with spoofed headers.
- Recommended limit strategy by endpoint type.

Session and cookie audit:
Check:
- Cookie attributes.
- HttpOnly.
- Secure.
- SameSite.
- Path.
- Domain.
- Expiration.
- Session rotation.
- Session invalidation.
- Logout behavior.
- Refresh token storage.
- JWT storage.
- Whether tokens are stored in localStorage or sessionStorage.
- Whether tokens are exposed to JavaScript unnecessarily.
- Whether session IDs are regenerated after auth state changes.
- Whether sensitive operations require valid fresh auth.

CSRF audit:
Determine whether the app uses cookie-based auth, bearer-token auth, or mixed auth.

If cookie-based auth is used, inspect all state-changing requests:
- POST.
- PUT.
- PATCH.
- DELETE.
- Server actions.
- Form submissions.
- API mutations.
- Checkout and billing actions.
- Account settings.
- Workspace settings.
- Invite actions.

Check:
- Are state-changing requests protected against CSRF?
- Are SameSite cookies configured?
- Are Origin or Referer headers validated on sensitive mutations?
- Is there a CSRF token strategy?
- Are custom headers required for API mutations?
- Are GET routes incorrectly changing state?
- Are login and logout protected appropriately?
- Are server actions protected sufficiently?
- Are webhook routes exempt from browser CSRF but protected by signature verification?

CORS audit:
Inspect all CORS headers and handlers.

Look for:
- Access-Control-Allow-Origin: *
- Wildcard origin on authenticated routes.
- Access-Control-Allow-Credentials: true with broad origins.
- Overly broad allowed methods.
- Overly broad allowed headers.
- Missing OPTIONS handling where CORS is intentionally supported.
- CORS used as auth.
- API routes exposed cross-origin without need.

API route and server action audit:
For every route handler, API route, and server action, check:
- Auth required.
- Authorization required.
- Rate limit required.
- Input validation present.
- Output filtered.
- Sensitive data excluded.
- Correct HTTP methods.
- Correct status codes.
- Request body size limits.
- Error messages safe.
- Logs safe.
- CSRF protection needed.
- CORS needed.
- Cache disabled for private data.
- Webhook signature verified if webhook.
- Idempotency required.
- Replay protection needed.
- Paid third-party API abuse possible.

Input validation and injection audit:
Inspect:
- Database queries.
- Raw SQL.
- ORM usage.
- Supabase filters.
- Search params.
- Dynamic route params.
- Form submissions.
- Webhook payloads.
- JSON parsing.
- Markdown or MDX rendering.
- HTML rendering.
- dangerouslySetInnerHTML.
- Redirect URLs.
- File paths.
- Shell commands.
- Email templates.
- Third-party API calls.

Look for:
- Missing validation.
- Unsafe string interpolation.
- SQL injection risk.
- XSS risk.
- Open redirect risk.
- Path traversal risk.
- Command injection risk.
- SSRF risk.
- Unsafe markdown rendering.
- Unsafe HTML rendering.
- User input passed to metadata or JSON-LD without escaping.
- User input passed to emails without safe handling.
- User input used to build URLs to internal services.

File upload audit if uploads exist:
Check:
- Auth required.
- Authorization required.
- File size limits.
- File type validation.
- MIME type validation not trusted alone.
- Extension validation.
- Storage bucket privacy.
- Public vs private file access.
- Signed URL expiry.
- Malware scanning if relevant.
- Image processing safety.
- SVG handling.
- User file names sanitized.
- Path traversal impossible.
- Upload rate limits.
- Download authorization.
- Metadata stripping if sensitive.
- Direct upload policies.

Webhook audit if webhooks exist:
Check:
- Signature verification.
- Raw body handling.
- Replay protection if supported.
- Idempotency.
- Event type allowlist.
- Safe error handling.
- Auth middleware not breaking provider signatures.
- No blind trust of event payload for user identity or plan changes.
- Rate limiting or abuse controls where appropriate.
- Logs do not include full sensitive payloads.
- Webhook secrets are server-only.

Payment and billing audit if payments exist:
Check:
- Checkout session creation requires auth.
- Price IDs are server-controlled, not client-controlled.
- User cannot set their own plan, price, trial, credits, or limits.
- Billing portal session requires auth and ownership.
- Stripe customer ID is bound to authenticated user or workspace.
- Webhook is source of truth for subscription state.
- Webhook signature is verified.
- Webhook events are idempotent.
- Subscription status cannot be spoofed by client requests.
- Server checks plan limits before paid actions.
- Credit or usage counters cannot be directly manipulated by users.

Admin security audit:
Check:
- Admin routes are not just hidden in the UI.
- Admin APIs require server-side admin role checks.
- Admin role cannot be self-assigned.
- Admin pages are excluded from sitemap and public nav.
- Admin routes are noindexed.
- Admin data is not fetched in public layouts.
- Admin logs do not expose secrets.
- Support impersonation, if present, is audited and logged.

Logging and error handling audit:
Check:
- Secrets in logs.
- Tokens in logs.
- Full webhook payloads in logs.
- Passwords or magic links in logs.
- PII in logs.
- Stack traces in production responses.
- Error boundaries leaking details.
- API errors leaking database or provider details.
- Console logs in production-sensitive paths.

Dependency audit:
Inspect:
- package.json.
- lockfile.
- Next.js version.
- React version.
- Auth library version.
- Database client version.
- Markdown or HTML sanitizer libraries.
- File upload libraries.
- Image processing libraries.
- JWT libraries.
- Crypto usage.

Do not upgrade anything.
Only report risks and recommended updates.

Middleware audit:
Inspect middleware.ts if present.

Check:
- Correct matcher.
- Private routes protected.
- API routes protected where needed.
- Auth bypasses.
- Locale or rewrite behavior that skips auth.
- Redirect loops.
- Open redirects.
- Preview mode bypasses.
- Static assets excluded correctly.
- Admin routes protected.
- Middleware does not rely on client state.
- Middleware does not expose secrets.

Public/private route audit:
Create a route inventory.

Classify routes as:
- Public indexable.
- Public noindex.
- Auth required.
- Admin required.
- API public.
- API protected.
- Webhook.
- Internal.
- Unknown.

Check:
- Private routes are not included in sitemap.
- Private routes are not linked from public metadata.
- Private routes have noindex if rendered.
- Private route data is not fetched in public layouts.
- Public pages do not expose private state.

Output format:
Return the report in this exact structure.

# Security Audit Report

## Overall Grade
Grade:
Rationale:

## Category Grades
| Category | Grade | Rationale |
|---|---:|---|
| Security headers |  |  |
| Secrets handling |  |  |
| Environment variable safety |  |  |
| Authentication |  |  |
| Authorization |  |  |
| Rate limiting |  |  |
| API route security |  |  |
| Session and cookie security |  |  |
| CSRF protection |  |  |
| CORS |  |  |
| Input validation |  |  |
| Webhook security |  |  |
| File upload security |  |  |
| Payment and billing security |  |  |
| Admin route security |  |  |
| Logging and error leakage |  |  |
| Dependency risk |  |  |
| Public/private route separation |  |  |

## Executive Summary
Summarize the most important risks in plain English.

## Top Priority Fixes
List the highest leverage fixes in order.

Use this format:
1. [Severity] Finding title
   - Why it matters:
   - Where:
   - Recommended fix:
   - Confidence:

## Findings by Severity

### Critical
For each finding:
- Title:
- Severity:
- Confidence:
- Evidence:
- Affected files/routes:
- Risk:
- Recommended remediation:
- Notes:

### High
Use the same format.

### Medium
Use the same format.

### Low
Use the same format.

### Informational
Use the same format.

## Route Inventory
| Route or pattern | Type | Auth required | Risk notes |
|---|---|---:|---|

## API and Server Action Inventory
| Endpoint/action | Method | Auth | Authorization | Rate limit | Validation | Notes |
|---|---|---:|---:|---:|---:|---|

## Secrets Review
Do not print secret values.

| Finding | File | Line | Type | Exposure risk | Recommended action |
|---|---|---:|---|---|---|

## Rate Limit Review
| Endpoint/action | Current protection | Risk | Recommended limit |
|---|---|---|---|

## Auth and Authorization Review
Summarize the auth model and the biggest risks.

## Headers and CSP Review
List current headers and recommended changes.

## CORS and CSRF Review
Summarize current state and risks.

## Dependency Review
List risky or outdated dependencies if found.

## Manual Follow-Up Checklist
Create a practical checklist ordered by priority.

## Assumptions and Unknowns
List anything you could not verify from the repo.

## Commands Run
List only read-only commands used.
If no commands were run, say so.

Rules for final answer:
- Do not include full secrets.
- Do not include exploit instructions.
- Do not include code patches.
- Do not modify files.
- Be specific and evidence-based.
- If something is not found, say “not found in repo” rather than assuming it is absent in production.
- Prioritize practical production risk over theoretical issues.

Votes

Saves

Copies

Prompt Score Breakdown

Trust score

Combines all prompt score categories using the current rubric.

Task clarity

+8 detected coding-agent prompt mode (67% confidence)

Input contract

+28 provides repo, stack, environment, and implementation context for a coding agent

Output contract

+22 defines concrete implementation deliverables

Guardrails

+26 includes explicit constraints

Safety

100

+14 mentions sensitive data only inside redaction and reporting boundaries

Reusability

+18 separates context, output, and rules into readable blocks

Community signal

+24 has 4 up-votes

RemixRemix Prompt

Comprehensive security audit and report for Next.js app, with severity and grading.

Comprehensive security audit and report for Next.js app, with severity and grading.

Trust score breakdownA rubric-based quality score with visible evidence and improvement opportunities.