ToolkitReconnaissance

Practical documentation · Authorized use only

Arjun

Arjun helps discover HTTP parameters that may be relevant to an approved application’s input surface. Use a local or staging application, a small candidate set, conservative rate limits, and server-side logging to validate behavior.

WebFuzzerParameter DiscoveryPython

Start safely and get useful results

Best for

  • • Approved input inventory
  • • API parameter review

Not for

  • • Authentication bypass
  • • High-volume production probing

Before you run anything

  • • Document the authorized target, time window, success criteria, data-handling rules, and a named stop contact before you begin.
  • • Confirm the installed version with the tool’s version or help command, then compare its documented behavior with the linked upstream project before relying on any option.

Practical workflows

Beginner

Inspect a local endpoint for GET parameters

Scenario: A training API endpoint needs a documented input inventory.

arjun -u http://localhost:8080/search -m GET -oT arjun.txt

Test the local endpoint and save text output for review.

Expected use: Candidates may be reflected or accepted parameters; validate semantics in application logs or source.

Intermediate

Use a bounded parameter list

Scenario: The service owner supplied known naming conventions.

arjun -u https://staging.example.invalid/api/search -m GET -w ./approved-params.txt -oJ arjun.json

Use an approved candidate list and structured output against the staging endpoint.

Expected use: Review for unexpected parameters, then validate authorization and input handling separately.

Interpret results like an analyst

  • • A parameter accepted by the server may be ignored downstream; verify it changes intended behavior before treating it as exposed functionality.
  • • Avoid interpreting response timing alone as proof of a hidden parameter.

Common mistakes and operating tips

Avoid

  • • Testing POST or authenticated routes without explicit scope and test credentials.
  • • Using a discovery result as evidence of injection or authorization weakness.

Operational discipline

  • • Treat command output as evidence, not a conclusion: retain the command, version, scope, timestamp, and a redacted result in the engagement record.
  • • Start with the smallest safe scope, validate expected behavior in a lab or pilot, then expand only when the authorization and monitoring plan support it.

Verify against the current upstream

Tool behavior and release syntax can change. Treat this guide as practical operating context, then verify version-specific details against the upstream project before an assessment.

Open authoritative upstream documentation