Security Engineering

Threat-aware code review → vulnerability detection → risk-ranked remediation.

<when_to_use>

• Security audits and code reviews
• Authentication/authorization review
• Input validation and sanitization checks
• Cryptographic implementation review
• Dependency and supply chain security
• Threat modeling for new features
• Security incident investigation

NOT for: performance optimization, general code review without security focus, feature implementation </when_to_use>

<phases> Track with TodoWrite. Phases build comprehensive security assessment.

Phase	Trigger	activeForm
Threat Model	Session start, feature review	"Building threat model"
Attack Surface	Threat model complete	"Mapping attack surface"
Vulnerability Scan	Attack surface mapped	"Scanning for vulnerabilities"
Risk Assessment	Vulnerabilities identified	"Assessing risk levels"
Remediation Plan	Risks assessed	"Planning remediation"

Workflow:

• Start: Create "Threat Model" as in_progress
• Transition: Mark current completed, add next in_progress
• Critical findings: Add urgent remediation task immediately
• Each phase feeds next — build comprehensive security picture </phases>

<severity_levels> Risk indicator with CVSS-aligned severity:

◆◆ Critical (9.0–10.0)

• Remote code execution
• Authentication bypass
• Mass data exposure
• Privilege escalation to admin

◆ High (7.0–8.9)

• SQL injection
• Stored XSS
• Authentication weaknesses
• Sensitive data leaks

◇ Medium (4.0–6.9)

• CSRF vulnerabilities
• Reflected XSS
• Information disclosure
• Weak cryptography

△ Low (0.1–3.9)

• Security misconfigurations
• Missing security headers
• Verbose error messages
• Minor information leaks

Use indicators in findings: "◆◆ Remote code execution via unsanitized shell command" </severity_levels>

<threat_modeling>

STRIDE Framework

Spoofing — can attacker impersonate users/systems?

• Authentication mechanisms
• Token generation/validation
• Session management
• API key handling

Tampering — can attacker modify data?

• Input validation boundaries
• Data integrity checks
• Immutable audit logs
• Database access controls

Repudiation — can actions be denied?

• Logging and audit trails
• Transaction signatures
• Timestamp verification
• Non-repudiation controls

Information Disclosure — can attacker access sensitive data?

• Data classification
• Encryption at rest/transit
• Access control enforcement
• Logging sensitive data

Denial of Service — can attacker disrupt service?

• Rate limiting
• Resource exhaustion
• Timeout handling
• Input size validation

Elevation of Privilege — can attacker gain unauthorized access?

• Authorization checks
• Role-based access control
• Principle of least privilege
• Permission validation

Attack Trees

Map attack paths from goal to entry points:

Goal: Steal user credentials
├─ Attack login endpoint
│  ├─ SQL injection in username field
│  ├─ Brute force (no rate limiting)
│  └─ Session fixation
├─ Intercept network traffic
│  ├─ HTTPS downgrade
│  └─ Man-in-the-middle
└─ Social engineering
   ├─ Phishing (out of scope)
   └─ Password reset exploit

For each branch, assess:

• Feasibility — how easy to exploit?
• Impact — what damage if successful?
• Detection — will we notice attack?
• Mitigation — current defenses? </threat_modeling>

<attack_surface>

Entry Points Inventory

External Interfaces:

• HTTP/API endpoints (REST, GraphQL, gRPC)
• WebSocket connections
• File uploads
• OAuth/SAML flows
• Webhooks

Data Inputs:

• User-supplied data (forms, query params, headers)
• File uploads (type, size, content)
• API payloads (JSON, XML, protobuf)
• Database queries
• Third-party integrations

Authentication Boundaries:

• Public endpoints (no auth required)
• Authenticated endpoints
• Admin/privileged endpoints
• Service-to-service auth

Trust Boundaries:

• User browser → web server
• Web server → database
• Service → third-party API
• Internal services (microservices)

Exposure Analysis

For each entry point document:

• Authentication required? (none/user/admin)
• Input validation? (none/basic/strict)
• Rate limiting? (yes/no)
• Logging? (yes/no)
• Encryption? (transit/rest/both/none)

Prioritize review:

1. Unauthenticated external inputs
2. Privileged operations
3. Data persistence layers
4. Third-party integrations </attack_surface>

<vulnerability_patterns>

Input Validation

SQL Injection:

// VULNERABLE
const query = `SELECT * FROM users WHERE email = '${userEmail}'`;

// SECURE — parameterized queries
const query = 'SELECT * FROM users WHERE email = ?';
db.execute(query, [userEmail]);

XSS (Cross-Site Scripting):

// VULNERABLE — direct HTML insertion
element.innerHTML = userInput;

// SECURE — sanitized or use textContent
element.textContent = userInput;
// OR use DOMPurify for rich content
element.innerHTML = DOMPurify.sanitize(userInput);

Command Injection:

// VULNERABLE
exec(`convert ${userFilename} output.png`);

// SECURE — parameterized or whitelist
execFile('convert', [userFilename, 'output.png']);

Path Traversal:

// VULNERABLE
const filePath = `/uploads/${userFileName}`;

// SECURE — validate and normalize
const safeName = path.basename(userFileName);
const filePath = path.join('/uploads', safeName);
if (!filePath.startsWith('/uploads/')) {
  throw new Error('Invalid path');
}

XML External Entity (XXE):

// VULNERABLE
const parser = new DOMParser();
const doc = parser.parseFromString(xmlInput, 'text/xml');

// SECURE — disable external entities
const parser = new DOMParser({
  locator: {},
  errorHandler: {},
  // Disable DTD processing
  entityResolver: () => null,
});

Authentication & Sessions

Password Storage:

// VULNERABLE — plain text or weak hash
const hash = md5(password);

// SECURE — bcrypt/argon2 with salt
const hash = await bcrypt.hash(password, 12);

Session Management:

// VULNERABLE — predictable session IDs
const sessionId = userId + Date.now();

// SECURE — cryptographically random
const sessionId = crypto.randomBytes(32).toString('hex');

// Add security attributes
res.cookie('session', sessionId, {
  httpOnly: true,
  secure: true, // HTTPS only
  sameSite: 'strict',
  maxAge: 3600000, // 1 hour
});

JWT Handling:

// VULNERABLE — no signature verification
const payload = JSON.parse(atob(token.split('.')[1]));

// SECURE — verify signature
const payload = jwt.verify(token, SECRET_KEY, {
  algorithms: ['HS256'], // Specify allowed algorithms
  issuer: 'your-app',
  audience: 'your-api',
});

Password Reset:

// VULNERABLE — predictable tokens
const resetToken = userId + '-' + Date.now();

// SECURE — cryptographically random with expiry
const resetToken = crypto.randomBytes(32).toString('hex');
await db.execute(
  'INSERT INTO reset_tokens (user_id, token, expires_at) VALUES (?, ?, ?)',
  [userId, await bcrypt.hash(resetToken, 10), Date.now() + 3600000]
);

Authorization

Broken Access Control:

// VULNERABLE — client-side only check
if (user.isAdmin) {
  // show admin panel
}

// SECURE — server-side enforcement
app.get('/admin/users', requireAdmin, (req, res) => {
  // Verify on every request
  if (!req.user?.isAdmin) {
    return res.status(403).json({ error: 'Forbidden' });
  }
  // Admin operation
});

Insecure Direct Object Reference (IDOR):

// VULNERABLE — no ownership check
app.get('/api/documents/:id', async (req, res) => {
  const doc = await db.getDocument(req.params.id);
  res.json(doc);
});

// SECURE — verify ownership
app.get('/api/documents/:id', async (req, res) => {
  const doc = await db.getDocument(req.params.id);
  if (doc.userId !== req.user.id && !req.user.isAdmin) {
    return res.status(403).json({ error: 'Forbidden' });
  }
  res.json(doc);
});

Privilege Escalation:

// VULNERABLE — role from client input
app.post('/api/users', async (req, res) => {
  const user = await createUser({
    ...req.body, // Includes role: 'admin' from malicious client
  });
});

// SECURE — explicit allowlist
app.post('/api/users', async (req, res) => {
  const allowedFields = ['name', 'email', 'password'];
  const userData = pick(req.body, allowedFields);
  const user = await createUser({
    ...userData,
    role: 'user', // Server controls role
  });
});

Cryptography

Weak Algorithms:

// VULNERABLE — deprecated algorithms
const hash = crypto.createHash('md5').update(data).digest('hex');
const cipher = crypto.createCipher('des', key);

// SECURE — modern algorithms
const hash = crypto.createHash('sha256').update(data).digest('hex');
const cipher = crypto.createCipheriv('aes-256-gcm', key, iv);

Hardcoded Secrets:

// VULNERABLE
const API_KEY = 'sk-1234567890abcdef';
const DB_PASSWORD = 'admin123';

// SECURE — environment variables
const API_KEY = process.env.API_KEY;
const DB_PASSWORD = process.env.DB_PASSWORD;

if (!API_KEY || !DB_PASSWORD) {
  throw new Error('Missing required environment variables');
}

Insufficient Randomness:

// VULNERABLE — predictable
const token = Math.random().toString(36);

// SECURE — cryptographically secure
const token = crypto.randomBytes(32).toString('hex');

Data Exposure

Sensitive Data in Logs:

// VULNERABLE
logger.info('User login', { email, password, ssn });

// SECURE — redact sensitive fields
logger.info('User login', {
  email,
  password: '[REDACTED]',
  ssn: '[REDACTED]',
});

Error Message Disclosure:

// VULNERABLE — exposes internals
catch (err) {
  res.status(500).json({ error: err.stack });
}

// SECURE — generic message
catch (err) {
  logger.error('Internal error', err);
  res.status(500).json({ error: 'Internal server error' });
}

Timing Attacks:

// VULNERABLE — early exit leaks info
if (user.password !== inputPassword) {
  return false;
}

// SECURE — constant-time comparison
return crypto.timingSafeEqual(
  Buffer.from(user.password),
  Buffer.from(inputPassword)
);

</vulnerability_patterns>

<owasp_top_10> 2021 OWASP Top 10 — primary vulnerability categories.

A01:2021 – Broken Access Control

• Missing function/resource level access control
• IDOR vulnerabilities
• CORS misconfigurations
• Force browsing to authenticated pages

CWE: 200, 201, 352, 359, 377, 402, 425, 639, 759, 639, 918, 1275

A02:2021 – Cryptographic Failures

• Sensitive data transmitted in clear text
• Old/weak cryptographic algorithms
• Missing encryption at rest
• Weak key generation/management

CWE: 259, 327, 331

A03:2021 – Injection

• SQL, NoSQL, OS command injection
• LDAP, XPath injection
• Expression language injection
• ORM injection

CWE: 20, 74, 75, 77, 78, 79, 80, 83, 89, 91, 93, 94, 95, 96, 97, 183, 184

A04:2021 – Insecure Design

• Missing security controls by design
• Ineffective security design patterns
• Lack of threat modeling
• Insecure reference architecture

CWE: 209, 256, 257, 266, 269, 280, 311, 312, 313, 316, 419, 430, 434, 444

A05:2021 – Security Misconfiguration

• Missing security hardening
• Unnecessary features enabled
• Default accounts/passwords
• Verbose error messages
• Missing security headers

CWE: 2, 11, 13, 15, 16, 260, 315, 520, 526, 537, 541, 547, 611, 614, 756, 776

A06:2021 – Vulnerable & Outdated Components

• Outdated dependencies with known CVEs
• Unsupported libraries
• No dependency scanning
• Missing security patches

CWE: 1035, 1104

A07:2021 – Identification & Authentication Failures

• Permits brute force attacks
• Weak password requirements
• Exposed session IDs in URLs
• Session fixation
• Missing MFA

CWE: 287, 288, 290, 294, 295, 297, 300, 302, 304, 306, 307, 346, 384, 521, 613, 640, 798, 940, 1216

A08:2021 – Software & Data Integrity Failures

• Unsigned/unverified CI/CD pipelines
• Insecure deserialization
• Missing integrity checks
• Auto-update without verification

CWE: 345, 353, 426, 494, 502, 565, 784, 829

A09:2021 – Security Logging & Monitoring Failures

• No audit trail for critical operations
• Insufficient log detail
• Logs not monitored
• Logs stored insecurely

CWE: 117, 223, 532, 778

A10:2021 – Server-Side Request Forgery (SSRF)

• Fetching remote resources without validation
• URL redirection to untrusted sites
• No network segmentation

CWE: 918

See owasp-top-10.md for detailed breakdowns. </owasp_top_10>

<workflow> Loop: Model Threats → Map Surface → Scan Vulnerabilities → Assess Risk → Plan Remediation

1. Threat Model — identify what could go wrong

   • STRIDE analysis for feature/component
   • Build attack trees for critical paths
   • Identify trust boundaries
   • Document threat actors (external/internal/privileged)

2. Attack Surface — map entry points

   • Inventory all inputs (API, files, user data)
   • Classify by authentication level
   • Identify data flows across trust boundaries
   • Prioritize high-risk entry points

3. Vulnerability Scan — systematic code review

   • Check each entry point against OWASP Top 10
   • Review authentication/authorization
   • Validate input handling
   • Check cryptographic usage
   • Scan dependencies for CVEs

4. Risk Assessment — severity and likelihood

   • Rate each vulnerability (◆◆/◆/◇/△)
   • Consider exploitability
   • Assess impact (confidentiality/integrity/availability)
   • Calculate risk score

5. Remediation Plan — prioritized fixes

   • Critical (◆◆) — immediate action required
   • High (◆) — fix before release
   • Medium (◇) — schedule in sprint
   • Low (△) — backlog or accept risk

Update todos as you progress through phases. </workflow>

<security_review_checklist> Before completing security review, verify:

Authentication:

• Passwords hashed with bcrypt/argon2 (cost ≥12)
• Session tokens cryptographically random
• Session cookies have httpOnly, secure, sameSite
• Password reset tokens random + expiring
• Rate limiting on login attempts
• MFA available for sensitive accounts

Authorization:

• All endpoints check authentication server-side
• Resource ownership verified before access
• Role checks on server, not client
• Principle of least privilege applied
• No IDOR vulnerabilities

Input Validation:

• All inputs validated (type, length, format)
• SQL queries use parameterized statements
• HTML output escaped or sanitized
• File uploads validated (type, size, content)
• Path traversal prevented in file operations
• Command injection prevented

Cryptography:

• No hardcoded secrets in code
• Strong algorithms (AES-256, SHA-256+)
• Cryptographically secure random generation
• HTTPS enforced (no HTTP)
• Certificate validation not disabled

Data Protection:

• Sensitive data encrypted at rest
• TLS 1.2+ for data in transit
• Sensitive data not logged
• Error messages don't leak internals
• PII handling complies with regulations

Dependencies:

• All dependencies up to date
• No known CVEs in dependencies
• Dependency scanning in CI/CD
• Package lock files committed
• Source verification for dependencies

Logging & Monitoring:

• Authentication events logged
• Authorization failures logged
• Sensitive operations audited
• Security events monitored
• Logs protected from tampering </security_review_checklist>

<reporting> ## Security Findings Format

For each vulnerability found:

## {SEVERITY_INDICATOR} {VULNERABILITY_NAME}

**Category**: {OWASP_CATEGORY}
**CWE**: {CWE_IDS}
**Severity**: {CRITICAL/HIGH/MEDIUM/LOW}

### Location
- File: {FILE_PATH}
- Lines: {LINE_RANGE}
- Function: {FUNCTION_NAME}

### Description
{CLEAR_EXPLANATION_OF_VULNERABILITY}

### Impact
{WHAT_ATTACKER_COULD_DO}

### Proof of Concept
{CODE_SNIPPET_OR_STEPS_TO_EXPLOIT}

### Remediation
{SPECIFIC_FIX_WITH_CODE_EXAMPLE}

### References
- OWASP: {URL}
- CWE: {URL}

Summary Report Structure

# Security Audit Report

**Date**: {DATE}
**Scope**: {COMPONENTS_REVIEWED}
**Reviewer**: {NAME}

## Executive Summary
{HIGH_LEVEL_OVERVIEW}

## Risk Summary
- Critical (◆◆): {COUNT}
- High (◆): {COUNT}
- Medium (◇): {COUNT}
- Low (△): {COUNT}

## Key Findings
{TOP_3_MOST_CRITICAL}

## Detailed Findings
{FULL_VULNERABILITY_LIST}

## Recommendations
{PRIORITIZED_REMEDIATION_PLAN}

## Conclusion
{OVERALL_SECURITY_POSTURE_ASSESSMENT}

</reporting> <rules> ALWAYS: - Start with threat modeling before code review - Map complete attack surface - Check against all OWASP Top 10 categories - Use severity indicators (◆◆/◆/◇/△) consistently - Provide specific remediation with code examples - Verify fixes don't introduce new vulnerabilities - Document security assumptions - Update todos when transitioning phases

NEVER:

• Skip threat modeling for "simple" features
• Assume input is trustworthy
• Rely on client-side security
• Use deprecated cryptographic algorithms
• Log sensitive data
• Disable security checks "temporarily"
• Recommend quick fixes without understanding context
• Mark complete without remediation plan </rules>

<references> Core methodology: - [owasp-top-10.md](references/owasp-top-10.md) — detailed OWASP Top 10 breakdown with CWE mappings - [FORMATTING.md](../../shared/rules/FORMATTING.md) — formatting conventions

Related skills:

• codebase-analysis — evidence-based investigation (foundation)
• debugging — systematic investigation when security issues manifest as bugs </references>