The difference between a lead and a finding is evidence. A useful report can explain the affected boundary, reproduce the behavior under the authorized conditions, and state only the impact the evidence supports.

Reconnaissance can produce a large technical surface: hostnames, JavaScript bundles, routes, parameters, API schemas, response patterns, and notes from earlier sessions. That material becomes useful only when it leads to a bounded question that can be tested against the real application.

From reconnaissance to a testable question

Preserve the research context

Keep the source, time, system, role, and reason an observation matters. A route or parameter may be ordinary; a relationship between an identifier, role check, and state transition can be worth testing.

Source and workflow review

Candidate sinks, trust-boundary changes, role checks, state transitions, and references to hidden endpoints are leads, not findings. The researcher still has to trace the real data flow and test the deployed behavior.

Hypothesis generation and prioritization

Turn each observation into a question: Does this identifier cross tenants? Is the mobile endpoint older than the web endpoint? Does the file preview change content type? Which role should own this object? A useful research queue does not invent the answers.

Documentation

Once the behavior is confirmed, structure the timeline, compare request and response evidence, identify missing reproduction details, and keep the wording tied to what was actually observed.

What is never delegated

  • Authorization and scope: the researcher determines what is permitted before testing.
  • Manual reproduction: the behavior is repeated using controlled steps and identities.
  • Exploit validation: the report distinguishes a suspicious response from an unauthorized outcome.
  • Impact: demonstrated impact is separated from plausible but untested escalation.
  • Severity: business context and prerequisites are reviewed by a person.
  • Final reporting: every request, screenshot, statement, and remediation recommendation receives human review.

The GK Data validation workflow

  1. Confirm authorization. Record the program rules, target scope, prohibited techniques, rate limits, and data-handling requirements.
  2. Collect deliberately. Gather only the reconnaissance needed for the target and keep provenance for important observations.
  3. Separate leads from findings. Retain context without labeling speculation as a vulnerability.
  4. Test manually. Use controlled accounts and the minimum data necessary to confirm an unauthorized action or security boundary failure.
  5. Preserve evidence. Save the relevant requests, responses, roles, timestamps, screenshots, and environmental conditions.
  6. Write to the proof. Describe exactly what happened, what did not happen, and what would require additional testing.
  7. Review before delivery. Reproduce the chain from the report and remove unsupported severity language, invented context, and unnecessary sensitive data.

The public model leaves out the machinery on purpose

The sequence above explains the control points, not a private research playbook. It does not publish target records, payload collections, or operational detail. Those details are less important to a customer than the safeguards around the result.

Several principles are useful to explain publicly:

  • Model the application before expanding tests. Identities, roles, sessions, objects, workflows, endpoints, and trust boundaries are connected before a suspicious parameter or code pattern is treated as meaningful.
  • Prefer decisive comparisons. A useful test compares expected and observed behavior across distinct roles, states, versions, or parsers. Positive and negative controls help separate a security failure from caching, configuration, or ordinary application behavior.
  • Keep competing explanations visible. Negative results and contradictory evidence are retained so a later researcher does not repeat the same branch or mistake an unresolved lead for proof.
  • Separate discovery from verification. A hypothesis does not confirm itself. Important conclusions require fresh reproduction and an independent check of the evidence.
  • Bound the proof. When a final impact step would exceed authorization or create an unnecessary side effect, the branch stays limited and its missing discriminator is recorded. Safety changes how proof is gathered, not whether the hypothesis is considered.
  • Preserve what should happen next. Reports record prerequisites, limitations, residual questions, and retest conditions so the work remains useful after the immediate finding is closed.

The GK Data review process explains how those standards translate into a client engagement, from the agreed scope through reporting and follow-up.

Confidentiality comes before convenience

Private program data, credentials, session material, customer records, source code, and internal hostnames require deliberate handling. The correct decision depends on the program rules, contract, data classification, retention controls, and approved processing environment.

Contractual restrictions, access control, and retention rules govern the research material. Scope, authorization, and data handling are settled before work begins.

What a credible report contains

  • a clearly identified asset and affected feature;
  • prerequisites, roles, and test conditions;
  • steps another person can reproduce;
  • the relevant request and response evidence;
  • a demonstrated security boundary failure;
  • impact limited to what the evidence supports; and
  • remediation aimed at the root cause rather than a payload string.

Two public examples show that standard in practice: the blind stored XSS file-upload case study and the NASA GLOBE Observer stored XSS case study. In each, reconnaissance and documentation supported the work; manual reproduction established the finding.

The standard is accountability

Disciplined security research avoids low-quality automated reporting by holding the result to an evidence standard. The researcher must be able to explain the data flow, reproduce the issue, defend the impact statement, and answer for every sentence delivered to the program or client.

That same standard guides GK Data’s research approach and Application Security Review. To discuss an authorized application security review, contact GK Data.