Analyze Code for Security Vulnerabilities

Evaluates whether APIs, configurations, and interfaces resist developer misuse, identifying designs where the "easy path" leads to insecurity. Its core principle is "the pit of success": secure usage should be the path of least resistance, and if developers must read documentation carefully or remember special rules to stay safe, the API has already failed. It names six rationalizations to reject when reviewing pushback - "it's documented," "advanced users need flexibility," "it's the developer's responsibility," "nobody would do that," "it's just a config option," "we need backwards compatibility" - and maps each to a required fix.

It catalogs six sharp-edge categories with concrete examples: algorithm/mode-selection footguns (the JWT "alg": "none" bypass and the RS256-to-HS256 key-confusion pattern; PHP's generic hash($algorithm, ...) accepting crc32), dangerous defaults (an OTP-lifetime function where lifetime=0 ambiguously means "accept all" or "expire immediately"), primitive-vs-semantic APIs (raw-bytes libsodium calls that let nonces and keys be swapped, versus Halite's type-enforced wrapper; a timing-unsafe == comparison that looks identical to a constant-time one), configuration cliffs (a verify_ssl: fasle typo silently accepted as truthy; a bypass_auth_for_health_checks flag combined with health_check_path: "/"), silent failures (a verify_signature function that returns True when no key is provided), and stringly-typed security (comma-separated permission strings that make privilege escalation as easy as string concatenation).

// DANGEROUS: allows crc32, md5, sha1
password_hash($password, PASSWORD_DEFAULT); // Good - no choice
hash($algorithm, $password); // BAD: accepts "crc32"

Its four-phase analysis workflow runs surface identification (mapping security-relevant APIs and developer choice points), edge-case probing (zero/empty/null, negative values, type confusion, default security, error-path behavior), threat modeling against three adversaries - the Scoundrel who actively attacks via configuration, the Lazy Developer who copy-pastes without reading docs, and the Confused Developer who swaps parameters by accident - and finding validation (reproducing the misuse, verifying real exploitability, checking documentation, and testing whether the API can be used safely with reasonable effort). Findings are graded Critical/High/Medium/Low by how obvious and easy the misuse is.

Use it when reviewing API or library design decisions, auditing configuration schemas for dangerous options, evaluating cryptographic API ergonomics, or assessing authentication/authorization interfaces. Not a fit for implementation bugs (use standard code review), business-logic flaws (use domain-specific analysis), or performance optimization.

Input: an API, library, or configuration schema exposing security-relevant choices to developers. Output: a categorized list of sharp edges with severity ratings, reproduction code demonstrating each misuse, and required fixes - grounded in a quality checklist covering zero/empty/null edge cases, default security, algorithm/mode footguns, type confusion, all three adversary types, error-path behavior, and configuration validation.

Ships category-specific reference files (references/crypto-apis.md, references/config-patterns.md, references/auth-patterns.md, references/case-studies.md covering real-world incidents like OpenSSL and GMP) plus language-specific footgun guides for C/C++, Go, Rust, Swift, Java, Kotlin, C#, PHP, JavaScript/TypeScript, Python, and Ruby.

Security reviewers and API/library designers auditing whether an interface's easy path is also its secure path, rather than reviewing for implementation bugs.