Source: Bug Bounty Bootcamp by Vickie Li
Source code review is one of the most effective ways to find vulnerabilities. Even partial access to source code (leaked repos, JS files, open-source components) dramatically increases your attack surface visibility.
Start by grepping for functions known to introduce vulnerabilities. Their presence doesn't confirm a bug – trace the input to determine if attacker-controlled data reaches them.
| Language | Function | Vulnerability |
|---|---|---|
| PHP | eval(), assert() | Code injection |
| PHP | system(), exec(), shell_exec(), passthru(), popen(), backticks | RCE / command injection |
| PHP | include(), require() | RFI / LFI |
| PHP | unserialize() | Insecure deserialization |
| Python | eval(), exec(), os.system() | Code injection / RCE |
| Python | pickle.loads(), yaml.load() | Insecure deserialization |
| JavaScript | document.write(), document.writeln() | XSS |
| JavaScript | document.location.href | Open redirect |
| Ruby | system(), exec(), %x(), backticks | RCE / command injection |
| Ruby | Marshal.load(), yaml.load() | Insecure deserialization |
Grep for keywords that indicate hardcoded credentials or weak algorithms:
grep -rn "key\|secret\|password\|encrypt\|API\|login\|token" .
GitHub personal access tokens follow the pattern [a-f0-9]{40}. Use TruffleHog for entropy-based secret scanning across git history:
trufflehog filesystem --directory=.
Weak/broken cryptographic algorithms to flag:
Grep for import and dependency statements:
grep -rn "import\|require" . | grep -v "node_modules" cat package.json cat requirements.txt cat pom.xml
Cross-reference library versions against:
dependency-check –scan .Developers leave notes that reveal internal details, removed features, and security TODOs:
grep -rn "TODO\|FIXME\|HACK\|completed\|config\|setup\|removed\|password\|secret" .
Look for comments like:
TODO: add auth check
* removed rate limiting for now admin key: …''
===== Debug Endpoints and Config Files =====
Debug routes left in production:
<code>
grep -rn “debug\|test\|dev\|admin\|internal” . | grep -i “route\|path\|url\|endpoint”
grep -rn “HTTP\|HTTPS\|FTP” . | grep -i “dev\|internal\|staging”
</code>
Config file extensions to look for:
<code>
find . -name “*.conf” -o -name “*.env” -o -name “*.cnf” -o -name “*.cfg” -o -name “*.cf” -o -name “*.ini” -o -name “*.sys” -o -name “*.plist”
</code>
===== Detailed Code Review Approach =====
==== Step 1: Identify Important Functions ====
Focus on high-impact areas first:
* Authentication logic (login, session creation, token validation)
* Password reset flows (token generation, expiry checks, delivery)
* State-changing operations (transfers, purchases, account changes)
* Sensitive data reads (profile info, payment data, admin queries)
==== Step 2: Trace User Input ====
Follow attacker-controlled data from entry point to sink. Example – login endpoint:
<code>
username = request.get(“username”) # entry point
query = “SELECT * FROM users WHERE username='” + username + “'” # SQL sink → SQLi
</code>
Example – file download endpoint revealing multiple issues:
<code>
url = request.get(“url”) # attacker controls url
# open redirect if url is external domain
# command injection if url passed to shell
# XSS if url reflected into HTML response
os.system(“wget ” + url) # command injection sink
</code>
Trace every parameter through the call chain. Look for points where sanitization is skipped, bypassed, or applied after use.
===== 5-Step Checklist =====
- Grep for dangerous functions (eval/system/unserialize/pickle.loads etc.) and trace their inputs to determine if attacker-controlled.
- Grep for secrets (key/secret/password/token) and scan git history with TruffleHog for entropy-based leaks.
- Audit dependencies against CVE databases; flag outdated packages.
- Grep for developer comments and debug endpoints that reveal hidden functionality or removed security controls.
- For each important function (auth, password reset, state-changing actions), trace user input from entry to sink and identify missing or bypassable sanitization.