Security

This skill provides guidance on writing secure code and identifying security vulnerabilities during code review.

Core Principles

• Defense in Depth: Layer multiple security controls; don't rely on a single defense
• Least Privilege: Grant minimum permissions necessary for functionality
• Don't Trust Input: Validate and sanitize all external input
• Keep It Simple: Complex code is harder to secure
• Fail Secure: When errors occur, fail closed rather than open

OWASP Top 10 (2025)

The OWASP Top 10 represents the most critical web application security risks.

A01: Broken Access Control

Failures in enforcing what authenticated users are allowed to do.

Vulnerabilities:

• Missing access control checks on sensitive operations
• Insecure Direct Object References (IDOR) — accessing resources by ID without authorization checks
• Privilege escalation — users accessing admin functionality
• CORS misconfiguration allowing unauthorized API access
• Bypassing access control by modifying URLs, parameters, or JWT tokens

Prevention:

• Deny by default; explicitly grant access
• Implement access control checks server-side, not client-side
• Use consistent access control mechanisms throughout the application
• Log access control failures and alert on repeated failures
• Invalidate sessions on logout and set appropriate timeouts

A02: Security Misconfiguration

Insecure default configurations, incomplete setups, or misconfigured security settings.

Vulnerabilities:

• Default credentials left unchanged
• Unnecessary features enabled (ports, services, pages, accounts)
• Error messages exposing sensitive information (stack traces, database errors)
• Missing security headers
• Outdated or vulnerable software configurations

Prevention:

• Automate secure configuration deployment
• Remove unused features and dependencies
• Review cloud storage permissions (S3 buckets, etc.)
• Send security directives via headers (CSP, X-Content-Type-Options, etc.)
• Use different credentials across environments

A03: Software Supply Chain Failures

Vulnerabilities introduced through dependencies, build systems, or distribution infrastructure.

Vulnerabilities:

• Using components with known vulnerabilities
• Outdated or unmaintained dependencies
• Not verifying package integrity
• Typosquatting attacks (malicious packages with similar names)
• Compromised build pipelines

Prevention:

• Maintain inventory of all dependencies and their versions
• Continuously monitor for vulnerabilities (Dependabot, Snyk, etc.)
• Only obtain packages from official sources
• Verify package signatures and checksums
• Review dependency changes in pull requests
• Use lock files to pin dependency versions

A04: Cryptographic Failures

Failures related to cryptography that expose sensitive data.

Vulnerabilities:

• Transmitting data in cleartext (HTTP, FTP, SMTP)
• Using weak or deprecated algorithms (MD5, SHA1, DES)
• Weak or default cryptographic keys
• Not enforcing encryption (missing TLS, weak TLS configuration)
• Improper key management (hardcoded keys, keys in source control)

Prevention:

• Encrypt all sensitive data in transit and at rest
• Use strong, current algorithms (AES-256, RSA-2048+, SHA-256+)
• Generate keys using cryptographically secure random generators
• Store keys securely, separate from encrypted data
• Use TLS 1.2+ with strong cipher suites
• Never implement custom cryptography

A05: Injection

Untrusted data sent to an interpreter as part of a command or query.

Vulnerabilities:

• SQL Injection — malicious SQL in user input
• NoSQL Injection — malicious queries in document databases
• OS Command Injection — shell commands in user input
• LDAP Injection — malicious LDAP queries
• Cross-Site Scripting (XSS) — malicious scripts in web pages

Prevention:

• Use parameterized queries or prepared statements (never string concatenation)
• Use ORM frameworks correctly
• Validate and sanitize all input (allowlist preferred over denylist)
• Escape output appropriate to context (HTML, JavaScript, SQL, etc.)
• Use Content Security Policy (CSP) headers
• Apply least privilege to database accounts

A06: Insecure Design

Security flaws from missing or ineffective security controls in the design phase.

Vulnerabilities:

• Missing threat modeling
• No rate limiting on expensive operations
• Missing input validation requirements
• Inadequate segregation of duties
• Business logic flaws

Prevention:

• Establish secure development lifecycle
• Use threat modeling for critical features
• Define security requirements and acceptance criteria
• Use secure design patterns and reference architectures
• Integrate security testing into CI/CD

A07: Authentication Failures

Failures in authentication mechanisms.

Vulnerabilities:

• Credential stuffing (using breached username/password lists)
• Brute force attacks (no rate limiting)
• Permitting weak passwords
• Missing or ineffective multi-factor authentication
• Session fixation or improper session invalidation
• Exposing session IDs in URLs

Prevention:

• Delegate authentication to trusted 3rd parties
• Implement multi-factor authentication
• Enforce strong password policies
• Rate limit and lock out after failed attempts
• Use secure session management (regenerate IDs on login)
• Never ship with default credentials
• Use secure (slow) password hashing (bcrypt, Argon2, scrypt)

A08: Data Integrity Failures

Failures to protect data and code from unauthorized modification.

Vulnerabilities:

• Insecure deserialization — untrusted data deserialized without validation
• Missing integrity checks on software updates
• Unsigned or unverified CI/CD pipelines
• Trusting serialized objects from untrusted sources

Prevention:

• Use digital signatures to verify integrity
• Validate all serialized data from untrusted sources
• Implement integrity checks in CI/CD pipelines
• Review code and configuration changes
• Avoid serializing sensitive data

A09: Security Logging and Alerting Failures

Insufficient logging, monitoring, and alerting.

Vulnerabilities:

• Not logging security-relevant events
• Logs not containing enough detail for forensics
• No monitoring or alerting on suspicious activity
• Logs stored only locally, vulnerable to tampering
• Missing audit trails for sensitive operations

Prevention:

• Log all authentication attempts (success and failure)
• Log all access control failures
• Log all input validation failures
• Include context: who, what, when, where
• Store logs centrally, append-only
• Implement real-time alerting for critical events

A10: Mishandling of Exceptional Conditions

Improper error handling that leads to security vulnerabilities.

Vulnerabilities:

• Failing open instead of closed
• Exposing sensitive information in error messages
• Resource exhaustion from unhandled exceptions
• Logic errors from unexpected states
• Race conditions and time-of-check/time-of-use (TOCTOU) bugs

Prevention:

• Catch and handle all exceptions appropriately
• Fail secure — deny access on error
• Use generic error messages for users; log details server-side
• Test error handling paths explicitly
• Use timeouts and circuit breakers

Language-Specific Guidelines

Ruby / Rails

• Use strong_parameters to whitelist permitted attributes
• Use parameterized queries (ActiveRecord does this by default, but beware of raw SQL)
• Enable CSRF protection (on by default in Rails)
• Use html_safe sparingly and never on user input
• Use SecureRandom for tokens, not rand
• Set config.force_ssl = true in production
• Use Brakeman for static security analysis

JavaScript / Node.js

• Avoid eval() and Function() constructor with user input
• Use parameterized queries with database drivers
• Sanitize HTML with libraries like DOMPurify
• Use helmet middleware for security headers
• Validate JSON schemas for API input
• Use npm audit or yarn audit regularly
• Be cautious with dangerouslySetInnerHTML in React

Bash

• Quote all variables: "$var" not $var
• Never use eval with user input
• Avoid command substitution with untrusted data
• Use -- to separate options from arguments
• Validate and sanitize all input before use
• Use arrays for command arguments to avoid injection

Security Review Checklist

When reviewing code for security:

• Are all inputs validated and sanitized?
• Are parameterized queries used for database access?
• Is output properly escaped for its context?
• Are authentication and authorization checks in place?
• Is sensitive data encrypted in transit and at rest?
• Are errors handled without exposing sensitive information?
• Are dependencies up to date and free of known vulnerabilities?
• Is logging sufficient for security monitoring?
• Are security headers configured correctly?
• Is rate limiting in place for sensitive operations?