Loading...
Loading...
Application security covering threat modeling (STRIDE), OWASP Top 10 (2025), OWASP API Security Top 10 (2023), secure coding review, authentication/authorization patterns, input validation, encryption, security headers, supply chain security, compliance (GDPR/HIPAA/SOC2/PCI-DSS), and security monitoring. Use when reviewing code for vulnerabilities, implementing auth patterns, securing APIs, configuring security headers, hardening supply chain, preventing injection attacks, or preparing for compliance audits.
npx skill4agent add oakoss/agent-skills application-security| # | Vulnerability | Prevention |
|---|---|---|
| 1 | Broken Access Control | Verify permissions server-side, default deny |
| 2 | Security Misconfiguration | Secure defaults, remove unused features |
| 3 | Software Supply Chain Failures | SBOM, dependency scanning, signed builds |
| 4 | Cryptographic Failures | Use TLS, hash passwords (argon2id), encrypt PII |
| 5 | Injection | Parameterized queries, input validation |
| 6 | Insecure Design | Threat modeling, security requirements |
| 7 | Authentication Failures | Strong passwords, MFA, secure session mgmt |
| 8 | Software or Data Integrity | Verify dependencies, sign releases |
| 9 | Logging and Alerting Failures | Log security events, set up alerts |
| 10 | Mishandling Exceptional Conditions | Fail securely, generic errors to clients |
| Principle | Rule |
|---|---|
| Defense in Depth | Multiple layers: firewall, auth, authz, encryption, audit |
| Least Privilege | Minimum permissions needed, nothing more |
| Zero Trust | Never trust, always verify. Assume breach. |
| Secure by Default | HTTPS, strict passwords, secure cookies out of the box |
| Fail Securely | Access denied on error, no internal details to users |
| Validate on Server | Client validation is UX, server validation is security |
| Area | Requirements |
|---|---|
| Passwords | Hashed with argon2id (preferred) or bcrypt (12+ rounds) |
| Tokens | JWT with EdDSA/ES256, 15min access / 7d refresh, httpOnly cookies |
| Sessions | HttpOnly, Secure, SameSite=Strict cookies |
| Rate Limiting | Auth endpoints: 5 attempts/15min |
| Authorization | All routes check auth server-side, default deny |
| Input | Validated with schema (Zod), parameterized SQL |
| Uploads | Whitelist types, enforce size limits |
| Secrets | No secrets in code or VCS |
| Headers | CSP (with nonces), HSTS, Permissions-Policy, X-Content-Type-Options |
| CORS | Configured restrictively |
| Encryption | PII encrypted at rest (AES-256) and in transit (TLS 1.3) |
| Logging | Audit logging for security events |
| Dependencies | SBOM generated, |
| Threat | Category | Key Mitigations |
|---|---|---|
| Spoofing | Authentication | MFA, strong passwords, JWT with short expiry |
| Tampering | Integrity | Input validation, HTTPS/TLS, signed tokens |
| Repudiation | Accountability | Audit logging, digital signatures |
| Info Disclosure | Confidentiality | Encryption, least privilege, secret management |
| Denial of Service | Availability | Rate limiting, input validation, CDN/DDoS protection |
| Elevation of Privilege | Authorization | Authz checks on every request, ABAC, permission audits |
| Level | Action |
|---|---|
| Critical | Immediate action required |
| High | Address before launch |
| Medium | Address post-launch |
| Low | Monitor, may accept risk |
| Framework | Scope | Key Requirements |
|---|---|---|
| GDPR | EU data subjects | Consent, data subject rights, breach notification (72h), DPIA |
| HIPAA | US healthcare data | PHI encryption, RBAC, audit logs, BAA with providers |
| SOC 2 | SaaS customer data | Security policies, MFA, encryption, incident response |
| PCI-DSS | Credit card data | Use payment processor (Stripe), tokenization, network segmentation |
| Anti-Pattern | Fix |
|---|---|
| Security as afterthought | Integrate from design phase |
| Client-side authorization | Always verify permissions server-side |
| Trusting client data (e.g., userId from body) | Get user ID from authenticated session |
| Rolling your own crypto | Use proven libraries (argon2, bcrypt, libsodium) |
| Compliance = security | Compliance is the minimum; security is ongoing |
| Verbose error responses | Generic messages to clients, details server-side |
| Mistake | Correct Pattern |
|---|---|
| Performing authorization checks only on the client side | Always verify permissions server-side; client checks are UX only |
| Trusting user-supplied IDs from request body (e.g., userId) | Derive user identity from the authenticated session or token |
| Rolling custom cryptography instead of using proven libraries | Use argon2id, bcrypt, or libsodium for all cryptographic operations |
| Treating compliance certification as equivalent to security | Compliance is the minimum bar; security requires ongoing review |
| Returning verbose error messages with stack traces to clients | Show generic messages to clients; log details server-side only |
ExploreTaskPlanFor database-layer security (RLS policies, Postgres/Supabase hardening, audit trails), use theskill. For AI/LLM security (prompt injection defense, agentic zero-trust, MCP tool hardening), use thedatabase-securityskill.secure-ai