| name | security-mindset |
| description | Thinking like an attacker. Threat modeling, secure-by-default design, security trade-offs. Use when: designing authentication/authorization, reviewing code for vulnerabilities, making security vs usability trade-offs, threat modeling, handling secrets or user input. Triggers: security, threat model, STRIDE, OWASP, authentication, authorization, input validation, secrets, attack surface, vulnerability |
Security Mindset
Attacker-perspective thinking framework for design and code review. Not pen-testing tools, not compliance checklists (project-specific).
Threat Modeling (STRIDE)
Microsoft STRIDE model — apply per component in your architecture:
| Threat | Property Violated | Example |
|---|
| Spoofing | Authentication | Forged JWT, session hijacking |
| Tampering | Integrity | Modified request body, SQL injection |
| Repudiation | Non-repudiation | No audit log, unsigned transactions |
| Information Disclosure | Confidentiality | Leaked API keys, verbose error messages |
| Denial of Service | Availability | Unbounded queries, resource exhaustion |
| Elevation of Privilege | Authorization | IDOR, missing role check, path traversal |
Threat Modeling Process (Shostack)
- What are we building? — DFD / architecture diagram, identify trust boundaries
- What can go wrong? — STRIDE per element crossing trust boundaries
- What are we going to do about it? — Mitigate, accept, transfer, or avoid
- Did we do a good job? — Review, test, revisit after changes
OWASP Top 10 as Design Decisions
| Category | Design Response |
|---|
| Injection (SQL, NoSQL, OS cmd, LDAP) | Parameterized queries. Never concatenate user input into queries/commands |
| Broken Authentication | MFA, session timeout, credential stuffing protection, no default credentials |
| Sensitive Data Exposure | Encrypt at rest + in transit, minimize data retention, mask in logs |
| Broken Access Control | Deny by default, RBAC/ABAC, validate server-side, test authz on every endpoint |
| Security Misconfiguration | Hardened defaults, disable unused features, automated config scanning |
| XSS | Context-aware output encoding (HTML/JS/URL/CSS), CSP headers |
| Insecure Deserialization | Validate before deserializing, prefer JSON over pickle/Java serialization |
| SSRF | Allowlist outbound destinations, block user-controlled URLs to internal services |
Secure-by-Default Design Principles
- Least Privilege — minimum permissions per component. No shared admin accounts
- Defense in Depth — multiple layers. Never rely on a single control
- Fail Secure — on error, deny access (don't fail open). Default-deny
- Zero Trust — verify every request regardless of network location. No trusted zones
- Minimize Attack Surface — fewer endpoints, fewer dependencies, fewer features = fewer vulnerabilities
- Separation of Duties — different credentials for build vs deploy, read vs write, admin vs user
Practical Security Judgments
Input validation boundary
- Validate at system boundary (API entry point). Trust nothing from outside
- Allowlist > denylist. Reject unknown, don't filter known-bad
Secret management
- Never in source code. Use vault/KMS
- Rotate regularly. Audit access
- Separate secrets per environment
Dependency security
npm audit / pip audit / Dependabot — run in CI- Known CVE = immediate action. Pin versions, review transitive deps
Logging for security
- Log: authentication events, authorization failures, input validation failures
- Never log: secrets, PII, full request bodies, session tokens
Error messages
- External: generic message. Internal: detailed log
- Never expose stack traces, DB schemas, internal paths to users
Security vs Usability Trade-offs
| More Security | Less Usability | Judgment |
|---|
| Strict password policy | Frustration, password reuse | Prefer passkeys/MFA over complex passwords |
| Short session timeout | Frequent re-auth | Adjust by risk level of operation |
| IP allowlisting | Remote work friction | Use device trust + MFA instead |
| Verbose audit logging | Storage cost, perf hit | Log security events, sample normal traffic |
| Rate limiting | Legitimate burst blocked | Adaptive limits, exempt authenticated users at lower risk |
Anti-Patterns
- Security as afterthought ("we'll add it later" → you won't)
- Security by obscurity alone (obscurity supplements, never replaces, real controls)
- Trusting the client (validation only in JS — server must re-validate)
- Catching and swallowing security exceptions (hides active attacks)
- Shared credentials between environments (dev key works in prod)
- Overly broad permissions "for convenience" (wildcard IAM policies)
Reference Books
- Threat Modeling: Designing for Security — Shostack
- Secure by Design — Johnsson, Deogun, Sawano
- The Web Application Hacker's Handbook — Stuttard, Pinto
- OWASP Top 10
