Default output: return only the result, blockers, and required evidence. Omit preambles, process narration, repeated context, confidence scores, and follow-up offers. Use at most five bullets unless a required artifact or schema needs more.
Security and Hardening
Overview
Apply security best practices systematically across the codebase. Prevent OWASP Top 10 vulnerabilities, manage secrets safely, audit dependencies, and enforce boundary validation at all system edges.
When to Use
- Handling user input or external data
- Implementing authentication or authorization
- Storing or transmitting sensitive data
- Integrating with external services
- Before deploying any change to production
OWASP Top 10 Prevention
Injection
- Use parameterized queries for all database access
- Validate and sanitize all user input
- Use ORM/query builders that handle escaping
- Never concatenate user input into queries, commands, or HTML
Broken Authentication
- Use established auth libraries (do not roll your own)
- Implement proper session management
- Require strong passwords and multi-factor authentication
- Use secure cookie flags (HttpOnly, Secure, SameSite)
Sensitive Data Exposure
- Encrypt data at rest and in transit
- Never log sensitive data (passwords, tokens, PII)
- Use environment variables for secrets, never hardcode
- Minimize data collection to what is needed
Security Misconfiguration
- Disable unnecessary features and services
- Keep all dependencies updated
- Use secure defaults (deny by default)
- Remove default credentials and sample data
Broken Access Control
- Enforce authorization on every protected endpoint
- Do not rely on client-side access control
- Implement proper CORS policies
- Validate resource ownership
Three-Tier Boundary System
Tier 1: External Boundary
All data from outside the system is untrusted:
- HTTP request bodies, headers, and query parameters
- File uploads and external API responses
- Webhook payloads and email content
Tier 2: Module Boundary
Data crossing module boundaries should be validated:
- Function parameters across module lines
- Queue message payloads
- Database read results when crossing service boundaries
Tier 3: Internal Boundary
Data within a trusted module needs less validation, but:
- Validate at state transitions
- Assert invariants in critical paths
- Use type systems to catch mistakes
Secrets Management
- Never hardcode secrets in source code
- Use environment variables or secret managers
- Validate required secrets at startup
- Rotate any exposed secrets immediately
- Add secret patterns to .gitignore
Process
Step 1: Identify Trust Boundaries
- List all points where data enters or leaves the system
- Identify authentication and authorization checkpoints
- Map data flows for sensitive information
Step 2: Apply Boundary Validation
- Validate input at every trust boundary
- Sanitize output when crossing boundaries
- Use allow-lists over deny-lists where possible
Step 3: Audit Dependencies
- Run dependency audit (npm audit, socket security)
- Check for known vulnerabilities
- Update or replace vulnerable packages
Step 4: Verify Security Controls
- Test authentication flows
- Test authorization for each role
- Verify CORS and CSP policies
- Check that error messages do not leak sensitive data
Common Rationalizations
| Rationalization |
Reality |
| "This is internal, security does not matter" |
Internal systems are targets for lateral movement after perimeter breach. |
| "We can add security later" |
Retrofitting security is more expensive and less effective than building it in. |
| "Validation is redundant" |
Defense in depth means multiple layers of validation. |
Verification
Anti-Rationalization Table
| Excuse |
Counter |
| "This is internal, security doesn't matter" |
Internal systems are targets for lateral movement after perimeter breach. |
| "We can add security later" |
Retrofitting security is more expensive and less effective than building it in. |
| "Validation is redundant" |
Defense in depth means multiple layers of validation. Each layer catches what others miss. |
| "The dependency audit is clean, we're safe" |
Dependency audits catch known vulnerabilities. They do not catch logic errors or misconfigurations. |
| "HTTPS is enough for data protection" |
HTTPS protects data in transit. Data at rest, in logs, and in memory also need protection. |
1---2name: security-and-hardening3description: OWASP Top 10 prevention, auth patterns, secrets management, dependency auditing, boundary validation. Use when handling user input, auth, or external integrations.4---56Default output: return only the result, blockers, and required evidence. Omit preambles, process narration, repeated context, confidence scores, and follow-up offers. Use at most five bullets unless a required artifact or schema needs more.78# Security and Hardening910## Overview1112Apply security best practices systematically across the codebase. Prevent OWASP Top 10 vulnerabilities, manage secrets safely, audit dependencies, and enforce boundary validation at all system edges.1314## When to Use1516- Handling user input or external data17- Implementing authentication or authorization18- Storing or transmitting sensitive data19- Integrating with external services20- Before deploying any change to production2122## OWASP Top 10 Prevention2324### Injection2526- Use parameterized queries for all database access27- Validate and sanitize all user input28- Use ORM/query builders that handle escaping29- Never concatenate user input into queries, commands, or HTML3031### Broken Authentication3233- Use established auth libraries (do not roll your own)34- Implement proper session management35- Require strong passwords and multi-factor authentication36- Use secure cookie flags (HttpOnly, Secure, SameSite)3738### Sensitive Data Exposure3940- Encrypt data at rest and in transit41- Never log sensitive data (passwords, tokens, PII)42- Use environment variables for secrets, never hardcode43- Minimize data collection to what is needed4445### Security Misconfiguration4647- Disable unnecessary features and services48- Keep all dependencies updated49- Use secure defaults (deny by default)50- Remove default credentials and sample data5152### Broken Access Control5354- Enforce authorization on every protected endpoint55- Do not rely on client-side access control56- Implement proper CORS policies57- Validate resource ownership5859## Three-Tier Boundary System6061### Tier 1: External Boundary6263All data from outside the system is untrusted:64- HTTP request bodies, headers, and query parameters65- File uploads and external API responses66- Webhook payloads and email content6768### Tier 2: Module Boundary6970Data crossing module boundaries should be validated:71- Function parameters across module lines72- Queue message payloads73- Database read results when crossing service boundaries7475### Tier 3: Internal Boundary7677Data within a trusted module needs less validation, but:78- Validate at state transitions79- Assert invariants in critical paths80- Use type systems to catch mistakes8182## Secrets Management8384- Never hardcode secrets in source code85- Use environment variables or secret managers86- Validate required secrets at startup87- Rotate any exposed secrets immediately88- Add secret patterns to .gitignore8990## Process9192### Step 1: Identify Trust Boundaries9394- List all points where data enters or leaves the system95- Identify authentication and authorization checkpoints96- Map data flows for sensitive information9798### Step 2: Apply Boundary Validation99100- Validate input at every trust boundary101- Sanitize output when crossing boundaries102- Use allow-lists over deny-lists where possible103104### Step 3: Audit Dependencies105106- Run dependency audit (npm audit, socket security)107- Check for known vulnerabilities108- Update or replace vulnerable packages109110### Step 4: Verify Security Controls111112- Test authentication flows113- Test authorization for each role114- Verify CORS and CSP policies115- Check that error messages do not leak sensitive data116117## Common Rationalizations118119| Rationalization | Reality |120|---|---|121| "This is internal, security does not matter" | Internal systems are targets for lateral movement after perimeter breach. |122| "We can add security later" | Retrofitting security is more expensive and less effective than building it in. |123| "Validation is redundant" | Defense in depth means multiple layers of validation. |124125## Verification126127- [ ] All user input is validated at trust boundaries128- [ ] No secrets in source code or logs129- [ ] Authentication and authorization tested for each role130- [ ] Dependency audit shows no critical vulnerabilities131- [ ] Error messages do not leak sensitive information132133## Anti-Rationalization Table134135| Excuse | Counter |136|--------|---------|137| "This is internal, security doesn't matter" | Internal systems are targets for lateral movement after perimeter breach. |138| "We can add security later" | Retrofitting security is more expensive and less effective than building it in. |139| "Validation is redundant" | Defense in depth means multiple layers of validation. Each layer catches what others miss. |140| "The dependency audit is clean, we're safe" | Dependency audits catch known vulnerabilities. They do not catch logic errors or misconfigurations. |141| "HTTPS is enough for data protection" | HTTPS protects data in transit. Data at rest, in logs, and in memory also need protection. |
v1truv1us