Owasp Top 10

OWASP Top 10 Security Vulnerabilities

Expert guidance for identifying, preventing, and remediating the most critical web application security risks based on OWASP Top 10 2021.

When to Use This Skill

• Conducting security audits and code reviews
• Implementing secure coding practices in new features
• Reviewing authentication and authorization systems
• Assessing input validation and sanitization
• Evaluating third-party dependencies for vulnerabilities
• Designing security controls and defense-in-depth strategies
• Preparing for security certifications or compliance audits
• Investigating security incidents or suspicious behavior

OWASP Top 10 2021 Overview

Ranked by Risk Severity:

1. A01 - Broken Access Control (↑ from #5) 2. A02 - Cryptographic Failures (formerly Sensitive Data Exposure) 3. A03 - Injection (↓ from #1) 4. A04 - Insecure Design (NEW) 5. A05 - Security Misconfiguration 6. A06 - Vulnerable and Outdated Components 7. A07 - Identification and Authentication Failures 8. A08 - Software and Data Integrity Failures (NEW) 9. A09 - Security Logging and Monitoring Failures 10. A10 - Server-Side Request Forgery (SSRF) (NEW)

Quick Reference

Load detailed guidance for each vulnerability:

Security Audit Workflow

1. Identify Scope: Determine application components and attack surface 2. Select Vulnerabilities: Choose relevant OWASP categories based on features 3. Load Reference: Read appropriate reference file(s) for detailed patterns 4. Analyze Code: Review code against vulnerable and secure patterns 5. Document Findings: Record vulnerabilities with severity and remediation 6. Verify Fixes: Test that remediations properly address issues 7. Test Security: Run automated security testing (SAST, DAST, SCA)

Core Security Principles

Defense in Depth

• Layer security controls at network, application, data, and monitoring levels
• Ensure failure of one control doesn't compromise entire system

Secure by Default

• Deny all access by default, explicitly grant permissions
• Fail securely (errors don't expose sensitive information)
• Minimize attack surface (disable unused features)
• Apply least privilege to all accounts and services

Input Validation

• Validate type, length, format, and allowed values
• Use allow-lists over deny-lists
• Sanitize for specific context (SQL, HTML, shell, etc.)
• Never trust client input

Common Mistakes

1. Trusting User Input: Always validate and sanitize all user-supplied data 2. Rolling Your Own Crypto: Use established libraries (bcrypt, AES-256) 3. Exposing Errors: Log detailed errors internally, show generic messages to users 4. Missing Authorization: Check permissions on every request, not just UI 5. Weak Session Management: Use secure, httpOnly, sameSite cookies with HTTPS 6. Ignoring Dependencies: Regularly audit and update third-party libraries 7. No Logging: Log security events for detection and incident response 8. Default Configurations: Harden all systems, disable defaults

Security Testing Tools

SAST (Static): SonarQube, Semgrep, ESLint security plugins DAST (Dynamic): OWASP ZAP, Burp Suite SCA (Dependencies): npm audit, Snyk, Dependabot Secrets Scanning: GitGuardian, TruffleHog Penetration Testing: Metasploit, Kali Linux tools

Resources

• OWASP Top 10 2021: https://owasp.org/Top10/
• OWASP Cheat Sheets: https://cheatsheetseries.owasp.org/
• OWASP ASVS: Application Security Verification Standard
• CWE Top 25: Common Weakness Enumeration
• NIST Cybersecurity Framework: https://www.nist.gov/cyberframework
• CVE Database: https://cve.mitre.org/
• Snyk Vulnerability DB: https://snyk.io/vuln/

OWASP Assessment Workflow

Structured methodology for conducting OWASP Top 10 security assessments, from scoping through remediation tracking.

Phase 1: Scoping and Pre-Assessment

Define Assessment Boundaries

• Application inventory: Identify all in-scope components (frontend, backend, APIs, microservices, databases)
• Technology stack: Document languages, frameworks, libraries, infrastructure
• Data classification: Identify sensitive data flows (PII, credentials, financial, health)
• Trust boundaries: Map where data crosses privilege levels or network zones
• Third-party integrations: Catalog external services, APIs, and dependencies

Establish Rules of Engagement

## Assessment Scope Document

**Target Application**: [name]
**Environment**: [production/staging/dev]
**Assessment Type**: [code review / dynamic testing / both]
**Timeline**: [start] - [end]
**Excluded Components**: [list]
**Emergency Contact**: [name, phone, email]
**Authorization Reference**: [document ID]

Prioritize Assessment Areas

Map application features to OWASP categories by risk:

Phase 2: Testing Methodology

Per-Category Testing Approach

A01 - Broken Access Control

Checklist:
[ ] Verify RBAC enforcement on every endpoint
[ ] Test horizontal privilege escalation (user A accessing user B data)
[ ] Test vertical privilege escalation (user accessing admin functions)
[ ] Check IDOR via sequential/predictable IDs
[ ] Verify CORS policy is restrictive
[ ] Test directory traversal on file operations
[ ] Confirm deny-by-default on new endpoints
[ ] Validate JWT/session token scope enforcement

A02 - Cryptographic Failures

Checklist:
[ ] Verify TLS 1.2+ on all external connections
[ ] Check for sensitive data in URLs or logs
[ ] Validate password hashing (bcrypt/argon2, not MD5/SHA1)
[ ] Verify encryption at rest for sensitive data
[ ] Check key management (rotation, storage, access)
[ ] Confirm no hardcoded secrets in source
[ ] Validate certificate pinning where applicable

A03 - Injection

Checklist:
[ ] Test SQL injection on all parameterized inputs
[ ] Verify ORM/parameterized queries (no string concatenation)
[ ] Test NoSQL injection on document queries
[ ] Check command injection on system calls
[ ] Test LDAP injection on directory queries
[ ] Validate template injection in server-side rendering
[ ] Verify XSS (reflected, stored, DOM-based) on all outputs

A04 - Insecure Design

Checklist:
[ ] Review threat model for business logic flaws
[ ] Check rate limiting on sensitive operations
[ ] Verify multi-step workflows can't be bypassed
[ ] Test for race conditions in concurrent operations
[ ] Validate business rule enforcement server-side
[ ] Review error handling for information disclosure

A05 - Security Misconfiguration

Checklist:
[ ] Check for default credentials on all services
[ ] Verify unnecessary features/ports are disabled
[ ] Review HTTP security headers (CSP, HSTS, X-Frame-Options)
[ ] Confirm error pages don't leak stack traces
[ ] Validate cloud/container security configurations
[ ] Check for directory listing on web servers
[ ] Review CORS, cookie, and cache-control settings

A06 - Vulnerable Components

Checklist:
[ ] Run dependency audit (npm audit, pip-audit, etc.)
[ ] Check for known CVEs in all dependencies
[ ] Verify dependency versions are actively maintained
[ ] Review transitive dependency risks
[ ] Confirm automated dependency update process exists
[ ] Check container base image for vulnerabilities

A07 - Authentication Failures

Checklist:
[ ] Test brute force protection (lockout/rate limiting)
[ ] Verify password complexity requirements
[ ] Check session fixation on login
[ ] Test multi-factor authentication bypass
[ ] Validate session timeout and invalidation
[ ] Verify credential recovery flow security
[ ] Check for credential stuffing protections

A08 - Integrity Failures

Checklist:
[ ] Verify CI/CD pipeline integrity (signed commits, protected branches)
[ ] Check for insecure deserialization of user input
[ ] Validate software update mechanisms use signatures
[ ] Review data integrity checks on critical operations
[ ] Verify CSP and SRI for frontend assets

A09 - Logging and Monitoring

Checklist:
[ ] Verify authentication events are logged
[ ] Check authorization failure logging
[ ] Validate log integrity (tamper protection)
[ ] Confirm alerting on suspicious patterns
[ ] Verify logs don't contain sensitive data
[ ] Check log retention meets compliance requirements
[ ] Test incident response playbook activation

A10 - SSRF

Checklist:
[ ] Test all URL/URI input parameters for SSRF
[ ] Verify allow-list enforcement on outbound requests
[ ] Check for cloud metadata endpoint access (169.254.169.254)
[ ] Test DNS rebinding protections
[ ] Validate internal network access restrictions
[ ] Check redirect-following behavior

Testing Tools by Phase

Phase 3: Risk Scoring

CVSS v3.1 Quick Reference

Score each finding using CVSS Base metrics:

Severity Bands: Critical (9.0-10.0), High (7.0-8.9), Medium (4.0-6.9), Low (0.1-3.9), Info (0.0)

DREAD Risk Model (Lightweight Alternative)

When full CVSS scoring is impractical, use DREAD for rapid triage:

Score: Sum / 5 = Average (1.0-3.0 scale). Map to severity: >2.5 Critical, >2.0 High, >1.5 Medium, <=1.5 Low.

Contextual Risk Adjustment

Adjust raw scores based on business context:

Adjusted Risk = Base Score x Environment Factor x Data Sensitivity Factor

Environment Factors:
  Production (internet-facing): 1.0
  Production (internal):        0.8
  Staging:                      0.5
  Development:                  0.3

Data Sensitivity Factors:
  PII / Financial / Health:     1.2
  Internal business data:       1.0
  Public data:                  0.7

Phase 4: Evidence Documentation

Finding Template

## [FINDING-ID]: [Title]

**Severity**: [Critical/High/Medium/Low/Info]
**CVSS Score**: [0.0-10.0] ([vector string])
**OWASP Category**: [A01-A10]
**CWE**: [CWE-ID]
**Status**: [Open/In Progress/Remediated/Accepted Risk]

### Description
[What the vulnerability is and why it matters]

### Affected Components
- [file:line or endpoint]

### Steps to Reproduce
1. [step]
2. [step]
3. [step]

### Evidence
[Screenshots, request/response pairs, code snippets]

### Impact
[What an attacker could achieve]

### Remediation
**Recommended fix**: [specific guidance]
**Code example**:
[secure code pattern]

### References
- [relevant OWASP page, CWE link, etc.]

Evidence Collection Standards

• Screenshots: Annotated with timestamps, redacted sensitive data
• HTTP traffic: Full request/response pairs from Burp/ZAP (sanitized)
• Code snippets: Include file path, line numbers, and surrounding context
• Tool output: Raw scanner output with false positives marked
• Proof of concept: Minimal, safe PoC that demonstrates the issue without causing damage

Phase 5: Remediation Prioritization

Priority Matrix

Prioritization Decision Framework

For each finding, evaluate:

1. Is it actively exploitable in production?
   YES -> P0 (immediate hotfix)

2. Does it expose sensitive data or allow privilege escalation?
   YES + Easy to exploit -> P0
   YES + Hard to exploit -> P1

3. Is it a configuration or dependency issue with a known fix?
   YES -> P1 (low effort, high value)

4. Does it require architectural changes?
   YES -> P2 with design spike

5. Is it informational or defense-in-depth?
   YES -> P3 (backlog)

Remediation Tracking

## Remediation Status Report

| Finding ID | Severity | Owner | Status | Target Date | Verified |
|---|---|---|---|---|---|
| FIND-001 | Critical | @dev-a | In Progress | 2025-02-01 | - |
| FIND-002 | High | @dev-b | Remediated | 2025-01-20 | Pending |
| FIND-003 | Medium | @dev-a | Open | 2025-03-01 | - |

Retest Protocol

After remediation: 1. Re-run the original test case to confirm the fix 2. Test for regressions (did the fix break adjacent functionality) 3. Test for bypass (can the fix be circumvented with a variation) 4. Update finding status and add verification evidence 5. Run automated scanners to catch any new issues introduced by the fix

Assessment Report Structure

1. Executive Summary
   - Scope and methodology
   - Key findings summary (critical/high/medium/low counts)
   - Overall risk posture assessment
   - Top 3 recommendations

2. Detailed Findings (by severity, then OWASP category)
   - Finding details using template above
   - Grouped by OWASP category for remediation planning

3. Remediation Roadmap
   - Prioritized action items with owners and timelines
   - Quick wins vs. strategic fixes
   - Dependency mapping between fixes

4. Appendices
   - Full tool output and scan results
   - Testing methodology details
   - Glossary and references

A07: Identification and Authentication Failures

Description: Weaknesses in authentication mechanisms allowing attackers to compromise accounts.

Common Weaknesses

// VULNERABLE: Weak session management
app.post('/login', async (req, res) => {
  const user = await authenticate(req.body);
  req.session.userId = user.id; // Predictable session ID
  req.session.cookie.secure = false; // Transmitted over HTTP
});

// SECURE: Strong session management
const session = require('express-session');
app.use(session({
  secret: process.env.SESSION_SECRET,
  resave: false,
  saveUninitialized: false,
  cookie: {
    secure: true, // HTTPS only
    httpOnly: true, // No JavaScript access
    maxAge: 3600000, // 1 hour
    sameSite: 'strict'
  },
  name: 'sessionId', // Custom name, not default 'connect.sid'
}));

Best Practices

• Implement multi-factor authentication (MFA)
• Use strong password policies (length, complexity, breach detection)
• Harden registration and credential recovery flows
• Limit or delay failed login attempts
• Use cryptographically random session identifiers
• Invalidate sessions on logout and timeout
• Implement account lockout after repeated failures
• Use secure password reset mechanisms
• Avoid exposing session IDs in URLs
• Rotate session IDs after login
• Check passwords against breached password databases (Have I Been Pwned)

A01: Broken Access Control

Description: Users can act outside their intended permissions, accessing unauthorized data or functions.

Common Patterns

// VULNERABLE: Direct object reference without authorization
app.get('/api/users/:id/profile', (req, res) => {
  const profile = db.getProfile(req.params.id);
  res.json(profile); // No check if user can access this profile
});

// VULNERABLE: Path traversal
app.get('/files/:filename', (req, res) => {
  res.sendFile(`./uploads/${req.params.filename}`);
  // Attack: GET /files/../../etc/passwd
});

// VULNERABLE: Missing function-level access control
app.post('/api/admin/users', (req, res) => {
  // No admin role check
  createUser(req.body);
});

Secure Implementation

// SECURE: Verify authorization for each request
app.get('/api/users/:id/profile', authenticate, (req, res) => {
  if (req.user.id !== req.params.id && !req.user.isAdmin) {
    return res.status(403).json({ error: 'Forbidden' });
  }
  const profile = db.getProfile(req.params.id);
  res.json(profile);
});

// SECURE: Sanitize file paths
const path = require('path');
app.get('/files/:filename', authenticate, (req, res) => {
  const filename = path.basename(req.params.filename);
  const filepath = path.join(__dirname, 'uploads', filename);

  if (!filepath.startsWith(path.join(__dirname, 'uploads'))) {
    return res.status(400).json({ error: 'Invalid path' });
  }
  res.sendFile(filepath);
});

// SECURE: Function-level access control
app.post('/api/admin/users', authenticate, requireRole('admin'), (req, res) => {
  createUser(req.body);
});

Prevention Checklist

• [ ] Deny by default, explicit allow for authorized access
• [ ] Implement attribute-based or role-based access control (ABAC/RBAC)
• [ ] Disable directory listing on web servers
• [ ] Log access control failures and alert on repeated violations
• [ ] Invalidate JWT tokens on logout
• [ ] Rate-limit API endpoints to minimize automated attacks

A02: Cryptographic Failures

Description: Exposing sensitive data due to missing or weak cryptography.

Common Vulnerabilities

// VULNERABLE: Storing passwords in plaintext
db.createUser({ username, password: password });

// VULNERABLE: Weak hashing
const hash = crypto.createHash('md5').update(password).digest('hex');

// VULNERABLE: Transmitting sensitive data over HTTP
fetch('http://api.example.com/payment', {
  body: JSON.stringify({ cardNumber, cvv })
});

// VULNERABLE: Hardcoded secrets
const API_KEY = 'sk_live_a3f7c9b2d8e1f4g6h9';

Secure Implementation

// SECURE: Strong password hashing with bcrypt
const bcrypt = require('bcrypt');
const saltRounds = 12;
const hash = await bcrypt.hash(password, saltRounds);
db.createUser({ username, passwordHash: hash });

// Verification
const isValid = await bcrypt.compare(password, user.passwordHash);

// SECURE: Encrypt sensitive data at rest
const crypto = require('crypto');
const algorithm = 'aes-256-gcm';
const key = Buffer.from(process.env.ENCRYPTION_KEY, 'hex'); // 32 bytes

function encrypt(text) {
  const iv = crypto.randomBytes(16);
  const cipher = crypto.createCipheriv(algorithm, key, iv);
  const encrypted = Buffer.concat([cipher.update(text, 'utf8'), cipher.final()]);
  const authTag = cipher.getAuthTag();
  return { iv: iv.toString('hex'), authTag: authTag.toString('hex'), data: encrypted.toString('hex') };
}

// SECURE: Use environment variables for secrets
require('dotenv').config();
const apiKey = process.env.API_KEY;

Prevention Checklist

• [ ] Classify data based on sensitivity (PII, financial, health)
• [ ] Encrypt all sensitive data at rest (AES-256)
• [ ] Encrypt data in transit with TLS 1.2+ only
• [ ] Use strong adaptive hashing (bcrypt, scrypt, Argon2)
• [ ] Rotate keys regularly and use proper key management (KMS)
• [ ] Disable caching for sensitive data responses
• [ ] Apply data retention policies and secure deletion

A03: Injection

Description: Untrusted data sent to interpreters as part of commands or queries.

Types: SQL, NoSQL, OS command, LDAP, XPath, template injection

SQL Injection

// VULNERABLE: String concatenation
const query = `SELECT * FROM users WHERE username = '${username}' AND password = '${password}'`;
// Attack: username = "admin'--"

// SECURE: Parameterized queries
const query = 'SELECT * FROM users WHERE username = ? AND password = ?';
db.query(query, [username, password]);

// SECURE: ORM with parameterization
const user = await User.findOne({
  where: { username, password }
});

NoSQL Injection

// VULNERABLE: Direct object injection
db.collection('users').findOne({
  username: req.body.username,
  password: req.body.password
});
// Attack: { "username": "admin", "password": { "$ne": null } }

// SECURE: Type validation and sanitization
const { username, password } = req.body;
if (typeof username !== 'string' || typeof password !== 'string') {
  return res.status(400).json({ error: 'Invalid input' });
}
db.collection('users').findOne({ username, password });

Command Injection

// VULNERABLE: Shell command with user input
const { exec } = require('child_process');
exec(`ping -c 4 ${req.body.host}`, callback);
// Attack: host = "google.com; rm -rf /"

// SECURE: Use safe APIs and validation
const { spawn } = require('child_process');
const host = req.body.host;
if (!/^[a-zA-Z0-9.-]+$/.test(host)) {
  return res.status(400).json({ error: 'Invalid host' });
}
const ping = spawn('ping', ['-c', '4', host]);

Prevention Checklist

• [ ] Use parameterized queries or ORMs exclusively
• [ ] Validate all input against strict allow-lists
• [ ] Escape special characters for the specific interpreter
• [ ] Use LIMIT in SQL queries to minimize data exposure
• [ ] Implement least privilege for database accounts
• [ ] Use static analysis tools (SAST) to detect injection

A04: Insecure Design

Description: Missing or ineffective security controls in design phase.

Threat Modeling Examples

// INSECURE DESIGN: No rate limiting on sensitive endpoints
app.post('/api/login', async (req, res) => {
  const user = await authenticate(req.body);
  // Vulnerable to credential stuffing
});

// SECURE DESIGN: Rate limiting + CAPTCHA
const rateLimit = require('express-rate-limit');
const loginLimiter = rateLimit({
  windowMs: 15 * 60 * 1000, // 15 minutes
  max: 5, // 5 attempts
  skipSuccessfulRequests: true
});

app.post('/api/login', loginLimiter, async (req, res) => {
  if (req.session.failedAttempts >= 3) {
    const captchaValid = await verifyCaptcha(req.body.captcha);
    if (!captchaValid) {
      return res.status(400).json({ error: 'Invalid CAPTCHA' });
    }
  }
  const user = await authenticate(req.body);
});

// INSECURE DESIGN: No transaction limits
app.post('/api/transfer', authenticate, async (req, res) => {
  await transferFunds(req.user.id, req.body.to, req.body.amount);
});

// SECURE DESIGN: Transaction limits + verification
app.post('/api/transfer', authenticate, async (req, res) => {
  const { to, amount } = req.body;

  // Business logic validation
  if (amount > 10000) {
    const verified = await require2FA(req.user);
    if (!verified) {
      return res.status(403).json({ error: '2FA required for large transfers' });
    }
  }

  // Daily limit check
  const dailyTotal = await getDailyTransferTotal(req.user.id);
  if (dailyTotal + amount > 50000) {
    return res.status(403).json({ error: 'Daily limit exceeded' });
  }

  await transferFunds(req.user.id, to, amount);
});

Design Principles

• Establish secure development lifecycle (SDLC)
• Use threat modeling (STRIDE, PASTA, OCTAVE)
• Write security user stories and abuse cases
• Implement defense in depth (layered security)
• Separate tenants and layers by design
• Limit resource consumption per user/tenant

A08: Software and Data Integrity Failures

Description: Code and infrastructure that doesn't protect against integrity violations.

Focus: Insecure CI/CD, auto-updates, unsigned objects, insecure deserialization

Vulnerabilities

// VULNERABLE: Accepting unsigned packages
npm install untrusted-package

// SECURE: Verify package integrity
// Use npm audit, lock files (package-lock.json)
// Verify checksums and signatures

// VULNERABLE: Insecure deserialization
const userData = JSON.parse(req.cookies.user);
eval(userData.code); // Arbitrary code execution

// SECURE: Avoid deserialization of untrusted data
const userData = JSON.parse(req.cookies.user);
// Validate schema, never execute code from untrusted sources

Prevention

• Use digital signatures for software/data verification
• Verify integrity of downloads (checksums, GPG)
• Implement secure CI/CD pipelines with segregation
• Review code and configuration changes
• Use libraries that prevent deserialization attacks
• Use lock files for dependency versions (package-lock.json, yarn.lock)
• Implement Software Bill of Materials (SBOM)
• Verify artifacts before deployment
• Separate build, test, and production environments
• Use signed commits and tags in version control

A09: Security Logging and Monitoring Failures

Description: Insufficient logging and monitoring allowing breaches to go undetected.

Effective Logging

const winston = require('winston');

const logger = winston.createLogger({
  level: 'info',
  format: winston.format.json(),
  transports: [
    new winston.transports.File({ filename: 'security.log' })
  ]
});

// Log security events
app.post('/api/login', async (req, res) => {
  try {
    const user = await authenticate(req.body);
    logger.info('Login success', {
      userId: user.id,
      ip: req.ip,
      timestamp: new Date()
    });
  } catch (err) {
    logger.warn('Login failed', {
      username: req.body.username,
      ip: req.ip,
      timestamp: new Date()
    });
  }
});

Critical Events to Log

• Login/logout (success and failures)
• Access control failures (authorization denials)
• Input validation failures
• Authentication token anomalies
• Server-side exceptions and errors
• Administrative actions
• Privilege escalation attempts
• Data access and modifications
• Sensitive configuration changes

Prevention

• Ensure logs are tamper-proof (append-only)
• Implement centralized log management (SIEM)
• Establish effective monitoring and alerting
• Define incident response and recovery plan
• Use correlation IDs to track requests
• Set appropriate log retention policies
• Protect logs from unauthorized access
• Ensure log formats support automated analysis
• Alert on suspicious patterns in real-time
• Test logging and alerting regularly

Prevention Strategies

Defense in Depth

Layer multiple security controls so failure of one doesn't compromise the system:

1. Network layer - Firewalls, segmentation, IDS/IPS 2. Application layer - Input validation, output encoding, authentication 3. Data layer - Encryption, access control, backups 4. Monitoring layer - Logging, alerting, incident response

Secure by Default

• Deny all access by default, explicitly grant
• Fail securely (errors should not expose information)
• Minimize attack surface (disable unused features)
• Least privilege for all accounts and services
• No security through obscurity
• Complete mediation (check every access)
• Separation of duties

Input Validation Strategy

// Comprehensive validation approach
function validateInput(input, schema) {
  // 1. Type check
  if (typeof input !== schema.type) return false;

  // 2. Length/range check
  if (schema.maxLength && input.length > schema.maxLength) return false;

  // 3. Format validation (regex)
  if (schema.pattern && !schema.pattern.test(input)) return false;

  // 4. Allow-list validation
  if (schema.allowedValues && !schema.allowedValues.includes(input)) return false;

  return true;
}

// Example usage
const emailSchema = {
  type: 'string',
  maxLength: 254,
  pattern: /^[^\s@]+@[^\s@]+\.[^\s@]+$/
};

if (!validateInput(req.body.email, emailSchema)) {
  return res.status(400).json({ error: 'Invalid email format' });
}

Best Practices Summary

1. Access Control: Implement RBAC/ABAC, deny by default, verify on every request 2. Cryptography: Use strong algorithms (AES-256, RSA-2048+), never roll your own crypto 3. Injection Prevention: Parameterized queries, input validation, output encoding 4. Secure Design: Threat modeling, security requirements, defense in depth 5. Configuration: Hardened defaults, security headers, minimal attack surface 6. Dependencies: Regular updates, vulnerability scanning, SCA tools 7. Authentication: MFA, strong passwords, secure session management 8. Integrity: Code signing, integrity verification, secure CI/CD 9. Logging: Comprehensive security event logging, monitoring, alerting 10. SSRF Prevention: URL validation, network segmentation, allow-lists

Security Testing Checklist

• [ ] Static Application Security Testing (SAST)
• [ ] Dynamic Application Security Testing (DAST)
• [ ] Interactive Application Security Testing (IAST)
• [ ] Software Composition Analysis (SCA)
• [ ] Penetration testing (manual + automated)
• [ ] Security code review
• [ ] Threat modeling and risk assessment
• [ ] Dependency vulnerability scanning
• [ ] Configuration security audit
• [ ] Authentication and authorization testing
• [ ] Session management testing
• [ ] Input validation testing
• [ ] Error handling and logging review
• [ ] Cryptography implementation audit

A05: Security Misconfiguration

Description: Missing hardening, unnecessary features, default credentials, verbose errors.

Common Issues

// VULNERABLE: Verbose error messages
app.use((err, req, res, next) => {
  res.status(500).json({
    error: err.message,
    stack: err.stack // Exposes internal structure
  });
});

// SECURE: Generic error messages
app.use((err, req, res, next) => {
  console.error(err); // Log internally only
  res.status(500).json({
    error: 'Internal server error',
    requestId: req.id
  });
});

// VULNERABLE: Unnecessary features enabled
app.use(express.static('public', { dotfiles: 'allow' }));
// Exposes .env, .git files

// SECURE: Restrict access
app.use(express.static('public', {
  dotfiles: 'deny',
  index: false // Disable directory listing
}));

// VULNERABLE: Missing security headers
app.get('/', (req, res) => {
  res.send('<h1>Welcome</h1>');
});

// SECURE: Security headers
const helmet = require('helmet');
app.use(helmet({
  contentSecurityPolicy: {
    directives: {
      defaultSrc: ["'self'"],
      scriptSrc: ["'self'"],
      styleSrc: ["'self'", "'unsafe-inline'"],
      imgSrc: ["'self'", 'data:', 'https:'],
    }
  },
  hsts: {
    maxAge: 31536000,
    includeSubDomains: true,
    preload: true
  }
}));

Prevention Checklist

• [ ] Implement automated hardening processes
• [ ] Remove unused features, frameworks, dependencies
• [ ] Review and update configurations regularly
• [ ] Use security headers (CSP, HSTS, X-Frame-Options)
• [ ] Disable default accounts and change default passwords
• [ ] Segment application architecture (containers, cloud)
• [ ] Keep error messages generic, log details internally

A10: Server-Side Request Forgery (SSRF)

Description: Application fetches remote resources without validating user-supplied URLs.

Vulnerability

// VULNERABLE: Fetching user-supplied URLs
app.get('/fetch', async (req, res) => {
  const data = await fetch(req.query.url);
  res.send(await data.text());
  // Attack: /fetch?url=http://localhost:6379/
  // Access internal services (Redis, databases)
});

// SECURE: Validate and restrict URLs
const { URL } = require('url');
const ALLOWED_HOSTS = ['api.example.com', 'cdn.example.com'];

app.get('/fetch', async (req, res) => {
  try {
    const url = new URL(req.query.url);

    // Block internal IPs
    const hostname = url.hostname;
    if (hostname === 'localhost' ||
        hostname.startsWith('127.') ||
        hostname.startsWith('192.168.') ||
        hostname.startsWith('10.') ||
        hostname.startsWith('169.254.')) {
      return res.status(400).json({ error: 'Invalid URL' });
    }

    // Allow-list hostnames
    if (!ALLOWED_HOSTS.includes(hostname)) {
      return res.status(400).json({ error: 'Host not allowed' });
    }

    const data = await fetch(url.href);
    res.send(await data.text());
  } catch (err) {
    res.status(400).json({ error: 'Invalid URL' });
  }
});

Prevention

• Sanitize and validate all client-supplied input data
• Enforce URL schema, port, destination with allow-list
• Disable HTTP redirections
• Use network segmentation to separate critical services
• Implement deny-by-default firewall policies
• Use DNS resolution validation
• Implement response validation (content-type, size)
• Use separate network for outbound requests
• Monitor and log all outbound requests
• Implement timeout and size limits on responses

A06: Vulnerable and Outdated Components

Description: Using components with known vulnerabilities or outdated versions.

Detection

# Check for known vulnerabilities
npm audit
npm audit fix

# Use security scanning tools
npx snyk test
npx retire

# Check outdated packages
npm outdated

Prevention

• Remove unused dependencies
• Monitor CVE databases (NVD, Snyk, GitHub Security)
• Subscribe to security bulletins for components
• Use Software Composition Analysis (SCA) tools
• Obtain components from official, trusted sources only
• Prefer signed packages with active maintenance
• Automate dependency updates with tools like Dependabot
• Test updates in staging before production
• Maintain inventory of all components and versions
• Establish vulnerability disclosure process