security
Application security - OWASP, validation, secrets. Use when securing the app.
When & Why to Use This Skill
This Claude skill provides a comprehensive framework for application security, focusing on OWASP Top 10:2025 compliance, secure header implementation, and robust secrets management. It helps developers secure Next.js applications on Vercel by enforcing non-negotiable safety standards, such as rate limiting with Upstash Redis, CSRF protection, and Multi-Factor Authentication (MFA) for administrative roles.
Use Cases
- Scenario 1: Auditing a web application's architecture to ensure compliance with OWASP Top 10:2025 standards and identifying potential vulnerabilities in authentication flows.
- Scenario 2: Implementing and verifying essential security headers including CSP, HSTS, and X-Frame-Options to protect against cross-site scripting and clickjacking.
- Scenario 3: Setting up 'fail-fast' build configurations to ensure that no application starts or deploys if critical secrets or environment variables are missing.
- Scenario 4: Reviewing codebase and telemetry logs to detect and eliminate hardcoded secrets or plaintext sensitive data, ensuring a 'zero-trust' logging environment.
- Scenario 5: Integrating rate-limiting strategies using Upstash Redis to mitigate brute-force attacks and ensure service availability.
| name | security |
|---|---|
| description | Application security - OWASP, validation, secrets. Use when securing the app. |
Security Guideline
Tech Stack
- Rate Limiting: Upstash Redis
- Framework: Next.js
- Platform: Vercel
Non-Negotiables
- OWASP Top 10:2025 vulnerabilities must be addressed
- CSP, HSTS, X-Frame-Options, X-Content-Type-Options headers must be present
- CSRF protection on state-changing requests
- No plaintext passwords in logs, returns, storage, or telemetry
- MFA required for Admin/SUPER_ADMIN roles
- Required configuration must fail-fast at build/startup if missing
- Secrets must not be hardcoded or committed
Context
Security isn't a feature — it's a foundational property. A single vulnerability can compromise everything else. The review should think like an attacker: where are the weak points? What would I exploit?
Beyond fixing vulnerabilities, consider the security architecture holistically. Is defense-in-depth implemented? Are there single points of failure? Would you trust this system with your own data?
Driving Questions
- What would an attacker target first?
- Where is rate limiting missing or insufficient?
- What attack vectors exist in authentication flows?
- How are secrets managed and what's the rotation strategy?
- What happens when a secret is compromised — is incident response exercisable?
- Where does "security by obscurity" substitute for real controls?