Security and Reliability Checklist

Contents

• Input/Output Safety (XSS, injection, SSRF, path traversal, prototype pollution)
• AuthN/AuthZ
• JWT & Token Security
• Secrets and PII
• Supply Chain & Dependencies
• CORS & Headers
• Runtime Risks (unbounded ops, event loop blocking, resource exhaustion)
• Cryptography
• Race Conditions (shared state, TOCTOU, database concurrency, distributed)
• Data Integrity

Input/Output Safety

• XSS: Unsafe HTML injection, dangerouslySetInnerHTML, unescaped templates, innerHTML assignments
• Injection: SQL/NoSQL/command/GraphQL injection via string concatenation or template literals
• SSRF: User-controlled URLs reaching internal services without allowlist validation
• Path traversal: User input in file paths without sanitization (../ attacks)
• Prototype pollution: Unsafe object merging in JavaScript (Object.assign, spread with user input)

AuthN/AuthZ

• Missing tenant or ownership checks for read/write operations
• New endpoints without auth guards or RBAC enforcement
• Trusting client-provided roles/flags/IDs
• Broken access control (IDOR - Insecure Direct Object Reference)
• Session fixation or weak session management

JWT & Token Security

• Algorithm confusion attacks (accepting none or HS256 when expecting RS256)
• Weak or hardcoded secrets
• Missing expiration (exp) or not validating it
• Sensitive data in JWT payload (tokens are base64, not encrypted)
• Not validating iss (issuer) or aud (audience)

Secrets and PII

• API keys, tokens, or credentials in code/config/logs
• Secrets in git history or environment variables exposed to client
• Excessive logging of PII or sensitive payloads
• Missing data masking in error messages

Supply Chain & Dependencies

• Unpinned dependencies allowing malicious updates
• Dependency confusion (private package name collision)
• Importing from untrusted sources or CDNs without integrity checks
• Outdated dependencies with known CVEs

CORS & Headers

• Overly permissive CORS (Access-Control-Allow-Origin: * with credentials)
• Missing security headers (CSP, X-Frame-Options, X-Content-Type-Options)
• Exposed internal headers or stack traces

Runtime Risks

• Unbounded loops, recursive calls, or large in-memory buffers
• Missing timeouts, retries, or rate limiting on external calls
• Blocking operations on request path (sync I/O in async context)
• Resource exhaustion (file handles, connections, memory)
• ReDoS (Regular Expression Denial of Service)

Cryptography

• Weak algorithms (MD5, SHA1 for security purposes)
• Hardcoded IVs or salts
• Using encryption without authentication (ECB mode, no HMAC)
• Insufficient key length

Race Conditions

Race conditions are subtle bugs that cause intermittent failures and security vulnerabilities. Pay special attention to:

Shared State Access

• Multiple threads/goroutines/async tasks accessing shared variables without synchronization
• Global state or singletons modified concurrently
• Lazy initialization without proper locking (double-checked locking issues)
• Non-thread-safe collections used in concurrent context

Check-Then-Act (TOCTOU)

• if (exists) then use patterns without atomic operations
• if (authorized) then perform where authorization can change
• File existence check followed by file operation
• Balance check followed by deduction (financial operations)
• Inventory check followed by order placement

Database Concurrency

• Missing optimistic locking (version column, updated_at checks)
• Missing pessimistic locking (SELECT FOR UPDATE)
• Read-modify-write without transaction isolation
• Counter increments without atomic operations (UPDATE SET count = count + 1)
• Unique constraint violations in concurrent inserts

Distributed Systems

• Missing distributed locks for shared resources
• Leader election race conditions
• Cache invalidation races (stale reads after writes)
• Event ordering dependencies without proper sequencing
• Split-brain scenarios in cluster operations

Common Patterns to Flag

# Dangerous patterns:
if not exists(key):       # TOCTOU
    create(key)

value = get(key)          # Read-modify-write
value += 1
set(key, value)

if user.balance >= amount:  # Check-then-act
    user.balance -= amount

Questions to Ask

• "What happens if two requests hit this code simultaneously?"
• "Is this operation atomic or can it be interrupted?"
• "What shared state does this code access?"
• "How does this behave under high concurrency?"

Data Integrity

• Missing transactions, partial writes, or inconsistent state updates
• Weak validation before persistence (type coercion issues)
• Missing idempotency for retryable operations
• Lost updates due to concurrent modifications