Framework Security Patterns
Framework-specific vulnerability patterns that arise from how modern web frameworks handle requests, responses, and data flow. These patterns are more durable than version-specific CVEs.
Why Framework Patterns Matter
- Frameworks have implicit behaviors - redirect(), Server Actions, template rendering have side effects
- Trust assumptions differ - Internal vs external, server vs client boundaries
- Chains emerge - Framework A's feature enables exploitation of Framework B's weakness
Pattern Categories
1. Request Handling Patterns
- Server Actions (Next.js) - Host header influence on internal requests
- Route Handlers - Missing authentication on API routes
- Middleware bypass - Path normalization differences
2. Template/Rendering Patterns
- SSTI (Flask, Jinja2, Django, Twig) - User input in template strings
- XSS via unsafe HTML insertion (React)
- Prototype pollution in SSR
3. Redirect Patterns
- Open redirect via unvalidated URLs
- SSRF via server-side redirect (Next.js, PHP)
- Header injection through redirect URLs
4. Deserialization Patterns
- Pickle (Python)
- Marshal (Ruby)
- PHP unserialize
- Java ObjectInputStream
Detection Workflow
- Identify frameworks in use (package.json, requirements.txt, Gemfile)
- Search for pattern signatures specific to each framework
- Map data flow from user input to dangerous framework APIs
- Check for sanitization or validation before reaching sink
Framework-Specific Skills
nextjs-patterns.md- Next.js Server Actions, redirect, Route Handlersflask-patterns.md- Flask/Jinja2 SSTI, unsafe deserializationreferences/django-patterns.md- Django ORM bypass, template injection, CSRF bypass, settings exposure, mass assignment, open redirectreferences/rails-patterns.md- Rails mass assignment, SQL injection, SSTI, command injection, insecure deserialization, unscoped finds, arbitrary file renderreferences/spring-security-patterns.md- Spring SpEL injection, method security misconfiguration, CORS, CSRF, actuator exposure, mass binding, insecure JWTreferences/graphql-patterns.md- GraphQL introspection, query depth/complexity abuse, batching attacks, authorization bypass, error disclosure
Integration with Audit Workflow
During /full-audit:
- Step 1 identifies frameworks during language detection
- Step 2 threat model considers framework-specific trust boundaries
- Step 4 deep dive uses framework-specific sink patterns
Example: DoxPit Pattern
Frontend: Next.js with Server Actions
Backend: Flask with Jinja2 templates
Chain:
1. Server Action uses redirect() → Host header controls internal fetch URL
2. SSRF reaches Flask backend on internal port
3. Flask uses render_template_string() with user input
4. SSTI → RCE via Jinja2 payload
This pattern detection focuses on the code behavior, not version numbers.