The risks you can't see

Act as a hostile security reviewer who has just been handed this codebase with no prior context. Before assessing any vulnerabilities, map the attack surface: list every point where untrusted data enters the system — HTTP endpoints, query/path/header params, request bodies, file uploads, websocket messages, environment variables, third-party API responses, deserialised data. For each entry point, trace where that data flows and what it eventually touches: database, filesystem, shell, template renderer, another service. Output a table of entry point → sink. Do not suggest fixes yet. Flag anything where you can't determine the destination — unknown flows are where I want to concentrate.

For each entry-point-to-sink flow you identified, act as an attacker trying to break it. For every flow, construct a concrete exploit: the specific malicious input, what it would do, and the line(s) that make it possible. Cover at minimum injection (SQL, command, template, LDAP), broken access control (can I reach this without authorisation, or reach another user's resource by changing an ID?), authentication and session weaknesses, SSRF, path traversal, insecure deserialisation, and secrets or sensitive data exposed in code, logs or responses. For each finding give me severity, the exact payload, and the precise location. If you cannot build a working exploit for a suspected issue, say so explicitly — I want real findings, not a checklist of theoretical worries.

Now review your own previous analysis as a sceptical second auditor whose job is to catch what the first reviewer missed. What did you assume was safe without checking? Which framework or library defaults did you trust that might not actually be enabled or configured? Did you check the auth logic itself, or only assume it works? Did you look at error-handling and failure paths, where security controls commonly get bypassed? Did you consider what happens when two requests race? List every assumption your first pass made, then test the three most dangerous ones. The goal is to break your own earlier conclusions.

Consolidate everything into a prioritised remediation plan. Rank findings by real-world risk — likelihood of exploitation × blast radius if exploited — not raw CVSS. For the top items, give me the specific code fix with before/after, and name the root-cause pattern so I can find other instances of the same mistake elsewhere. Separately, flag anything that needs a human security professional rather than a generated fix: auth architecture, cryptography choices, anything where a wrong fix creates false confidence. Be explicit about what this review cannot catch — business-logic flaws specific to my domain, vulnerabilities in dependencies, and anything requiring runtime or infrastructure context you can't see from the code.

From the vulnerabilities and flows you've identified, write a test plan that proves each fix works and stays fixed. For every finding, give me a test that confirms the exploit is now blocked (the malicious input fails safely) and a test that confirms legitimate input still works (so the fix didn't break the feature). Cover the boundaries — empty, oversized, malformed, wrong-type and edge-case inputs — and the auth matrix: each protected action tried as the right user, the wrong user, and no user. Mark which tests can be automated in my existing framework versus which need manual verification, and flag any flow you can't test without runtime or infrastructure I haven't shown you.