Source Code Analysis and Web Application Reconnaissance
Map sources, sinks, and the path between them
Begin with the attack surface: enumerate routes from framework route files, .htaccess rewrites, servlet mappings, or the main dispatcher, then list every source - $_GET, $_POST, $_COOKIE, $_SERVER, JSON bodies, headers, uploaded files, and even database rows that are later rendered. Next locate sinks: system, exec, popen, eval, include, unserialize, string-concatenated SQL, template rendering, file_get_contents, and header setters. A vulnerability is the surviving path between the two.
Confirm flows with targeted grep rather than broad tool output: search the parameter name, follow every reassignment, decode, and validation step. Ask whether the sanitization matches the sink - htmlspecialchars does nothing for SQL or shell metacharacters, and addslashes does nothing for LDAP. Watch for second-order flows where input is stored in a fairly clean form and used much later in an admin page, a log viewer, or a cron job.
Framework awareness is reconnaissance: identify the stack from headers, cookie names, error pages, and directory layout, then read the routing and middleware code so you know which controller handles a URL and which guards (auth, CSRF, output escaping) actually execute. Auto-escaping differs per template engine and version.
Traps: assuming client-side validation is enforcement; trusting a custom sanitize() without reading it; overlooking sinks in error handlers, logging, and admin-only code; and ignoring parameters that are never echoed but are used in a query or a file path.
Rule of thumb: write a one-line source to transform to sink map for each candidate, and only call it exploitable when you can name a payload that survives every transform on that path.