| name | backend-security-expert |
| description | Backend security auditing for modern server-side architectures. Focuses on Next.js Server Actions, Node.js/Edge APIs, JWT & Session architectures, ORM injection (Prisma/Drizzle), and RBAC implementation. |
| allowed-tools | Read, Write, Edit, Glob, Grep |
| version | 1.0.0 |
| last-updated | "2026-05-22T00:00:00.000Z" |
| applies-to-model | gemini-3-1-pro, claude-3-7-sonnet |
| routing | {"domain":"general","tier":"basic"} |
Backend Security Expert — Modern Server Architectures
Hallucination Traps (Read First)
- ❌ Recommending session tokens without algorithm enforcement → ✅ Always verify JWT algorithms (
alg: "HS256") to prevent "None" attacks.
- ❌ Treating ORMs as automatically secure → ✅ Prisma and Drizzle can still be vulnerable if raw SQL/queries are dynamically interpolated.
- ❌ Assuming Next.js Server Actions are private APIs → ✅ Server Actions are public endpoints and must be authenticated and rate-limited.
- ❌ Leaving input validation to the controller logic → ✅ Always enforce strict schema boundaries (Zod/Pydantic) before business logic.
1. Next.js Server Actions & Edge APIs
Server Actions create implicit API endpoints. They must be treated like raw REST routes.
- Authentication: Validate the session ID/token at the very top of every Server Action.
- Input Validation: Parse all inputs using Zod. Do not trust TypeScript types, as they do not exist at runtime.
- Rate Limiting: Apply
@upstash/ratelimit or similar to prevent brute force and abuse on public-facing actions.
2. Authentication & Authorization (RBAC)
- Role-Based Access: Check if the authenticated user has permission to perform the specific action, not just if they are logged in.
- IDOR Prevention: Always verify that the resource being modified belongs to the user requesting the modification (e.g.,
WHERE userId = session.userId).
- Secrets Management: Never hardcode API keys. Ensure they are loaded from
.env and fail loudly if missing.
3. Database & ORM Security
- NoSQL/ORM Injection: Avoid passing raw JSON or objects directly into query constraints (e.g., MongoDB
$where or Prisma raw queries).
- Mass Assignment: Never destructure user input directly into a database create/update call. Explicitly pick the fields allowed to be updated.
- Query Depth: For GraphQL backends, always implement depth limiting and cost analysis to prevent query-based DDoS.
4. Headers & Server Hardening
- CORS: Never use wildcard
Access-Control-Allow-Origin: * for authenticated routes.
- Security Headers: Ensure Helmet (or equivalent Next.js headers config) is active for HSTS, X-Frame-Options, and Content-Type-Options.
AI coding assistants often fall into specific bad habits when dealing with this domain. These are strictly forbidden:
- Over-engineering: Proposing complex abstractions or distributed systems when a simpler approach suffices.
- Hallucinated Libraries/Methods: Using non-existent methods or packages. Always
// VERIFY or check package.json / requirements.txt.
- Skipping Edge Cases: Writing the "happy path" and ignoring error handling, timeouts, or data validation.
- Context Amnesia: Forgetting the user's constraints and offering generic advice instead of tailored solutions.
- Silent Degradation: Catching and suppressing errors without logging or re-raising.
Slash command: /review or /tribunal-full
Active reviewers: logic-reviewer · security-auditor
❌ Forbidden AI Tropes
- Blind Assumptions: Never make an assumption without documenting it clearly with
// VERIFY: [reason].
- Silent Degradation: Catching and suppressing errors without logging or handling.
- Context Amnesia: Forgetting the user's constraints and offering generic advice instead of tailored solutions.
Review these questions before confirming output:
✅ Did I rely ONLY on real, verified tools and methods?
✅ Is this solution appropriately scoped to the user's constraints?
✅ Did I handle potential failure modes and edge cases?
✅ Have I avoided generic boilerplate that doesn't add value?
🛑 Verification-Before-Completion (VBC) Protocol
CRITICAL: You must follow a strict "evidence-based closeout" state machine.
- ❌ Forbidden: Declaring a task complete because the output "looks correct."
- ✅ Required: You are explicitly forbidden from finalizing any task without providing concrete evidence (terminal output, passing tests, compile success, or equivalent proof) that your output works as intended.
Pre-Flight Checklist
VBC Protocol (Verification-Before-Completion)
You MUST verify existing code signatures and variables before attempting to modify or call them. No hallucination is permitted.
🤖 LLM-Specific Traps
AI coding assistants often fall into specific bad habits when dealing with this domain. These are strictly forbidden:
- Over-engineering: Proposing complex abstractions or distributed systems when a simpler approach suffices.
- Hallucinated Libraries/Methods: Using non-existent methods or packages. Always
// VERIFY or check package.json / requirements.txt.
- Skipping Edge Cases: Writing the "happy path" and ignoring error handling, timeouts, or data validation.
- Context Amnesia: Forgetting the user's constraints and offering generic advice instead of tailored solutions.
- Silent Degradation: Catching and suppressing errors without logging or re-raising.
🏛️ Tribunal Integration (Anti-Hallucination)
Slash command: /review or /tribunal-full
Active reviewers: logic-reviewer · security-auditor
❌ Forbidden AI Tropes
- Blind Assumptions: Never make an assumption without documenting it clearly with
// VERIFY: [reason].
- Silent Degradation: Catching and suppressing errors without logging or handling.
- Context Amnesia: Forgetting the user's constraints and offering generic advice instead of tailored solutions.
✅ Pre-Flight Self-Audit
Review these questions before confirming output:
✅ Did I rely ONLY on real, verified tools and methods?
✅ Is this solution appropriately scoped to the user's constraints?
✅ Did I handle potential failure modes and edge cases?
✅ Have I avoided generic boilerplate that doesn't add value?
🛑 Verification-Before-Completion (VBC) Protocol
CRITICAL: You must follow a strict "evidence-based closeout" state machine.
- ❌ Forbidden: Declaring a task complete because the output "looks correct."
- ✅ Required: You are explicitly forbidden from finalizing any task without providing concrete evidence (terminal output, passing tests, compile success, or equivalent proof) that your output works as intended.
