security-analysis

Topics in the source

• Security analysis
• 1. Map trust boundaries first
• 2. Trace source to sink
• 3. Check the categories that get missed
• 4. Rank by exploitability, not by category name
• 5. Report with the attack path and the fix
• Honesty rules

A finding is only real if you can describe the attacker, what they control, and what they get. "This could be unsafe" is not a finding — it is an unfinished one. The discipline here is identical to debugging: trace from a source you can influence to a sink that does something dangerous, and prove the path is unbroken. Scope: this is for reviewing code you or the user are authorized to work on — your own projects, your employer's, or an engagement you have permission for. It finds and fixes defects. It does not produce working exploits against systems you do not control. You cannot assess code without knowing where untrusted data enters. Identify: Sources: HTTP request bodies, query params, headers, cookies, uploaded files, webhook payloads, message queues, third-party API responses, filenames, environment in multi-tenant contexts, and anything read from the database that a user once wrote Sinks: SQL, shell, filesystem paths, HTTP requests made by the server, template rendering, deserializers, eval-alikes, redirects, log statements that feed a parser The boundary: where a request stops being anonymous and becomes a principal with rights That last one, written down explicitly, is whe

This is an excerpt. Refer to the complete source and its current requirements.