The right tool.
For the right task.

Check data-source terms and confirm scope before active follow-up.

Choose passive or active methods deliberately; review each discovery module.

Use approved names and record the resolver and observation time.

Review the selected mode before enabling active enumeration.

Search results may be stale; confirm ownership before direct testing.

Use the current Platform rather than the older Legacy Search interface.

Review transform data sources, terms and handling of client information.

Review modules, recursion and scope expansion before starting a scan.

Review module dependencies and API credentials; retain source dates.

Review licence terms, scripts, timing and the exact target list.

Limit targets and scan rate; validate results with a protocol-specific check.

Review batch size, timeouts and automatic follow-up settings.

High traffic is possible; use explicit scope and agreed packet limits.

Packet captures can contain credentials and personal data; restrict access.

Keep TLS verification enabled and avoid putting secrets in command history.

Scanner features vary by edition; define scope and authenticated test roles.

Passive review and active scanning have different effects; select the correct mode.

Check project boundaries, plugins and storage before loading client traffic.

This is ProjectDiscovery httpx; do not confuse it with the Python library.

Bound the crawl by host, path and depth; avoid unintended state changes.

Set a suitable wordlist and request rate; check false-positive filters.

Limit depth, threads and scope before testing production applications.

Select the relevant mode and confirm request volume with the client.

Use a narrow approved test; avoid data extraction or write actions by default.

Expect active requests and validate every reported issue manually.

Use approved schemas and test data; generated requests may change state.

Review synchronisation and shared workspaces before storing client tokens or requests.

Pin templates; review request behaviour, code execution and out-of-band interactions.

Check edition limits, policy settings and whether scan authentication succeeded.

Record feed freshness and configuration; review results rather than copying raw ratings.

Review scan templates, credentials, asset boundaries and storage requirements.

Match results to the correct hostname, service and client security baseline.

Record negotiation results and verify certificate and hostname context.

Explain which observed settings are weak and how they affect the service.

Use the correct SNI hostname and explicitly check verification results.

Review module effects and payload settings; record and remove all test changes.

Credential use and remote execution need explicit scope and attempt limits.

Use approved collectors; protect directory data and validate graph assumptions.

Select each tool deliberately; many actions authenticate or execute remotely.

Certificate requests and authentication tests require specific client approval.

Keep identity enumeration within the approved systems and account permissions.

Review script behaviour and collected data before execution on a client host.

Approve each destination and remove tunnels and agents during cleanup.

Agree routing, authentication and boundaries; log and remove every temporary tunnel.

Agree acquisition and retention; recovered passwords are sensitive client data.

Use only authorised hash sets and protect both hashes and recovered values.

Choose a relevant subset rather than sending every list to every target.

A cloud review needs defined accounts, roles and permissions beyond an external test.

Use an agreed audit identity and protect configuration exports.

Record scanner and database versions; findings still need applicability checks.

Confirm the source-review scope and validate reported data flows.

Redact results and arrange rotation; a match alone does not prove a live secret.

Review live verification behaviour and obtain approval for external service calls.

Use approved application builds and isolate potentially unsafe files.

Use authorised devices and builds; record any changes to the test environment.

Restrict access and review import deduplication and evidence handling.

Check which features belong to Community or commercial editions.

Apply client separation, access control and a documented retention policy.

Foundational guidance; combine it with current technology-specific documentation.

Use lifecycle principles and check technical examples against current vendor guidance.

Record the release and versioned test-case identifiers in assessment evidence.

Agree the version, scope and verification level before claiming coverage.

Use it alongside a full test plan; a Top 10 list is not an exhaustive methodology.

Use the applicable mobile requirements and test cases for the agreed platform.

Use technique mappings where useful; ATT&CK is not a complete pentest checklist.

Map the root cause carefully rather than selecting the broadest matching category.

Explain business impact separately; a score alone is not the complete risk.

Record the date and probability; this is not proof of exploitation on your target.

Treat inclusion as prioritisation context and verify applicability to the client asset.

Check the affected product and vendor advisory; database entries may change.

Keep lab exercises separate from client systems and production data.

Run it in an isolated environment rather than exposing it to the internet.

Training access and paid plans vary; follow the platform’s target boundaries.

Use only the systems and activity permitted by each exercise.

Package availability does not establish suitability for an engagement.