Hunting Angles
Injected into every Phase 2 prompt. Think like an attacker, not a code reviewer — read the code at depth and try to break the defenses, not just confirm they exist.
Bugs live in the gaps between layers. Follow the data from entry point through validation, transformation, storage, retrieval and output.
The happy path is defended. Error handlers, fallbacks, catch blocks, timeouts, retries, cleanup — are failures handled with the same rigor as success?
Empty, maximum-length, null vs undefined vs missing, zero, negatives, unicode, first and last item, one over the max, exactly at the rate limit, the moment a token expires.
Does the DB layer assume the API validated? Does the renderer assume content was sanitized on write? Find where trust is implicit and test whether it's justified.
Call step 3 before step 1. Delete during create. Hit the confirmation endpoint without starting the flow. Replay a completed flow.
Two requests to the same resource. Modify while reading. Delete while iterating. Two users claiming the same unique resource.
Accepted by the schema but rejected by the DB. URL parsed differently by the router vs the app. Filename extension vs MIME type vs magic bytes.
Store then retrieve — same value? Does encoding change, escaping double-up, a relative path resolve differently on read vs write, serialization lose type info?
What happens when config is missing or default? Can an env var override a security control? Does a feature flag disable validation? What's the posture during first-run setup?
For every state change, ask: who authorized this? Trace back to the permission check. Is it the right permission, on the right resource? Any parallel path that checks differently — or not at all?
Error messages revealing internal paths. Stack traces in production. Timing that reveals whether a record exists. Response-size differences. Version-disclosing headers. Debug endpoints that survived.
Where a default is safe but a user-supplied parameter changes it. Find every input that overrides a security-relevant default and check the override is gated by the right permission.
Anywhere self-declared identity, capability, or metadata influences an access or trust decision without independent verification.
// Validation rules — before reporting ANY finding
- Construct a concrete attack: exact inputs, requests, or action sequence.
- The attack must achieve meaningful impact — not "learn field names" or "cause an error".
- Check if another layer already prevents exploitation. If so, it's a hardening note.
- If the baseline comparable has the same pattern, note whether it's been exploited there.
- If the exploit depends on parser/runtime behavior, verify against the spec — don't reason from intuition.
- Return ONLY confirmed findings, or an honest "No exploitable vulnerabilities found".