ParamAngler: A Piped Approach to Web Parameter Injection Testing

Hook

While security teams spend hours configuring complex scanners, bug bounty hunters are piping thousands of URLs through lightweight tools that do one thing exceptionally well—and cashing in on the results.

Context

Web application security testing has historically been dominated by monolithic tools like Burp Suite and OWASP ZAP. These are powerful platforms, but they come with a significant problem: they're designed for deep, interactive testing of a handful of applications. Bug bounty hunters and penetration testers face a different challenge entirely. They need to test hundreds or thousands of endpoints quickly, looking for low-hanging fruit like reflected XSS, SQL injection error messages, or local file inclusion vulnerabilities. The traditional approach doesn't scale.

This gap created demand for a new generation of tools that embrace Unix philosophy: do one thing well, work with stdin/stdout, and compose easily with other tools. ParamAngler fills this niche specifically for parameter injection testing. Rather than being a comprehensive scanner, it's a focused utility that reads URLs, injects payloads into query parameters, and filters results based on response characteristics. It's the kind of tool you chain with subfinder, httpx, and other reconnaissance utilities in a pipeline that processes entire domains in minutes.

Technical Insight

ParamAngler's architecture is deceptively simple, but its simplicity is precisely what makes it effective. At its core, it's a concurrent HTTP client that parses query parameters and performs systematic payload injection. Let's examine how it achieves this.

The tool reads URLs from stdin line by line, parsing each one to extract query parameters. For a URL like https://example.com/search?q=test&category=books, ParamAngler identifies two injection points: q and category. It then creates multiple requests, injecting your payload into each parameter individually. If you provide the payload <script>alert(1)</script>, it generates requests like:

# Replace mode (default)
https://example.com/search?q=<script>alert(1)</script>&category=books
https://example.com/search?q=test&category=<script>alert(1)</script>

# Append mode (-a flag)
https://example.com/search?q=test<script>alert(1)</script>&category=books
https://example.com/search?q=test&category=books<script>alert(1)</script>

The concurrency model is where Go's goroutines shine. ParamAngler uses a worker pool pattern controlled by the -t flag (threads). Here's how you might use it in practice:

# Find subdomains, probe for live hosts, extract URLs with parameters,
# then test for XSS with 50 concurrent workers
subfinder -d example.com | \
  httpx -silent | \
  waybackurls | \
  grep '?' | \
  paramAngler -p '<svg/onload=alert(1)>' -t 50 -mc 200 -ms '<svg'

This pipeline processes potentially thousands of URLs, and the worker pool ensures you're not overwhelming either your network or the target. Each worker pulls URLs from a channel, performs the injection testing, and writes results that match your filters.

The filtering mechanism is where ParamAngler becomes practical rather than just noisy. The -mc flag filters by HTTP status code (useful for finding inputs that trigger errors like 500 Internal Server Error, often indicating SQL injection vulnerabilities), while -ms searches response bodies for specific strings. For SQL injection testing, you might look for database error messages:

cat urls.txt | paramAngler -p "'" -mc 500 -ms 'SQL syntax'

The append mode (-a) is particularly clever for certain attack patterns. When testing for SQL injection, appending a single quote to existing parameter values often reveals vulnerabilities better than replacing the entire value. Consider a URL like https://example.com/product?id=123. Replace mode would send id=', losing the numeric context that might be required. Append mode sends id=123', which is more likely to trigger a meaningful error in a vulnerable SQL query.

The proxy support (-x) integrates ParamAngler into professional workflows. You can route all requests through Burp Suite for detailed inspection:

cat targets.txt | paramAngler -p 'payload' -x http://127.0.0.1:8080

This lets you use ParamAngler for rapid discovery while capturing interesting requests in Burp for deeper analysis, combining the speed of CLI tools with the power of GUI inspection.

One architectural decision worth noting is the lack of built-in rate limiting. ParamAngler expects you to control this externally, either by limiting input speed or using the -t flag conservatively. This is consistent with Unix tool philosophy—composability over built-in features. If you need rate limiting, pipe through a tool like pv to control line throughput.

Gotcha

ParamAngler's focused design comes with clear boundaries you'll hit quickly in real-world testing. The most significant limitation is its exclusive focus on GET query parameters. Modern web applications increasingly use POST requests, JSON APIs, and complex header-based authentication. ParamAngler can't touch any of these. If you're testing a REST API that accepts JSON bodies, or you need to inject payloads into HTTP headers like User-Agent or Referer, you'll need a different tool entirely.

Authentication is another major gap. Most interesting vulnerabilities exist behind login walls, but ParamAngler has no cookie handling or session management. You can't pass authentication tokens or maintain session state across requests. This limits you to testing public-facing endpoints or forces you to manually extract session cookies and construct URLs that include them as parameters—a fragile workaround at best.

The TODO list in the repository mentions missing encoding options, and this is a real limitation. Modern WAFs and input filters often block basic payloads but fail against encoded variants. Without built-in support for URL encoding variations, HTML entity encoding, or base64 encoding, your payloads are more likely to be blocked. You'll need to pre-encode payloads yourself or pipe through additional tools, adding complexity to your pipeline.

Error handling is minimal. Network timeouts, rate limiting responses, and connection failures aren't handled gracefully. In high-volume testing scenarios, you'll lose results to transient failures with no retry mechanism. The tool also provides no progress indication when processing large input sets, leaving you uncertain whether it's working through a massive list or hung on a slow endpoint.

Verdict

Use ParamAngler if you're doing reconnaissance-phase testing across many domains, hunting for quick wins in bug bounty programs, or building automated pipelines that process large URL lists. It's ideal when you have a curated set of URLs with query parameters and need to rapidly test basic injection vectors like XSS or SQL error messages. The tool shines when chained with other Unix-style security utilities in a scripted workflow where speed matters more than depth.

Skip ParamAngler if you're testing modern single-page applications with JSON APIs, need to test authenticated endpoints with complex session handling, or require comprehensive vulnerability validation rather than just initial detection. Skip it when you need POST parameter testing, custom header injection, or sophisticated payload encoding to bypass WAFs. For those scenarios, invest time in configuring Burp Suite's Intruder or use more feature-complete tools like ffuf. ParamAngler is a scalpel for a specific job—trying to use it as a Swiss Army knife will only frustrate you.