Security And Hardening

---
name: security-and-hardening
description: OWASP Top 10 prevention, auth patterns, secrets management, dependency auditing, boundary validation. Use when handling user input, auth, or external integrations.
metadata:
  category: user-invoked
disable-model-invocation: true
---

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

- [ ] All user input is validated at trust boundaries
- [ ] No secrets in source code or logs
- [ ] Authentication and authorization tested for each role
- [ ] Dependency audit shows no critical vulnerabilities
- [ ] Error messages do not leak sensitive information

## 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. |