Vulnerability Research Workflow

Research Starts With Scope

Good vulnerability research starts before opening a debugger, proxy, or source tree. I first define what is allowed, what is useful to test, and what evidence would prove impact without creating unnecessary risk. Scope changes the entire workflow because a bug that matters in one environment may be only a hardening note in another.

I look at product purpose, exposed attack surface, authentication model, user roles, dangerous features, file handling, request parsing, and integration points. This gives the research a map. It also prevents wasting time on behavior that is expected, intentionally restricted by scope, or impossible to explain as a security boundary.

Threat Modeling The Input

Most practical vulnerabilities start with attacker-controlled input crossing a trust boundary. That input can be an HTTP parameter, file upload, archive, template, serialized object, path, header, token, webhook, API field, plugin setting, or database value reused later in a privileged context.

The important question is not only whether input is accepted. The question is where that input is stored, transformed, trusted, rendered, executed, compared, or used in a permission decision. I follow the data until it reaches a sensitive operation or dies in validation.

I separate immediate sinks from delayed sinks. Immediate sinks happen in the same request, such as a file include, SQL query, command invocation, or template render. Delayed sinks happen later, often through background jobs, scheduled tasks, cache warmers, email generation, export features, webhooks, import processors, or administrative review panels. Delayed sinks are easy to miss because the original request can look harmless.

Code Paths Over Guessing

My preferred workflow is to map code paths instead of testing randomly. I look for authorization checks, capability checks, object ownership checks, file access, SQL builders, deserialization, command construction, template rendering, SSRF sinks, XML parsing, archive extraction, and unsafe trust in client-side state.

When source is available, I start with entry points and work inward. When only a black-box target is available, I use behavior to infer the same structure: which routes exist, which roles can reach them, which parameters affect server-side state, and which errors reveal backend decisions.

A useful audit pattern is to compare how the same object is accessed from different roles. If an administrator route checks ownership but an AJAX route only checks authentication, that difference is a signal. If a read path validates an object but an export path, delete path, or background action accepts only an identifier, that is another signal. Many real authorization bugs live in those inconsistent secondary paths.

Advanced Review Targets

I pay special attention to features that combine trust boundaries: file upload plus extraction, import plus background parsing, user-controlled URLs plus server-side fetch, templating plus stored content, low-privilege settings plus privileged rendering, and plugin systems that allow untrusted extension code or configuration.

Multi-step features are usually more interesting than single forms. A user may upload a file in one role, trigger processing in another context, then view output through an administrative panel. Each step can be secure alone but unsafe when chained. The research goal is to understand the full lifecycle, not only the first request.

Reproducibility Matters

A finding is only useful when another person can reproduce it. I keep notes on versions, configuration assumptions, user roles, permissions, request payloads, expected responses, and the exact condition that turns a bug into a vulnerability.

A strong report should let a triager repeat the issue without guessing. That means the proof should include the minimum setup, the request or action sequence, the security boundary being crossed, and the observable result. If the issue depends on a non-default configuration, that has to be clear.

Impact Before Noise

Not every bug is a vulnerability. I focus on impact: authentication bypass, authorization bypass, privilege escalation, sensitive data exposure, arbitrary file access, code execution, stored cross-site scripting with realistic privilege impact, SSRF that reaches internal services, and business logic abuse.

Weak findings become stronger when the report explains the attacker model and the realistic consequence. Strong findings become weaker when the evidence is noisy, exaggerated, or missing the security boundary. The goal is to make the impact obvious without overstating it.

Patch Thinking

I also think about how the issue should be fixed. A useful report does not need to write the patch, but it should identify the broken assumption. Is the problem missing authorization, unsafe parsing, weak normalization, trust in client data, or incomplete validation? That distinction matters because surface-level filters often leave the vulnerable design in place.

Good research improves a product. The final output should help defenders understand the root cause, reproduce the issue, and close the vulnerable path with confidence.

The best fixes usually move checks closer to the sensitive action. Input validation is useful, but authorization belongs at the object access point, path normalization belongs before file operations, and URL allowlisting belongs before network calls. A patch is strongest when the dangerous operation cannot be reached incorrectly, even if another route is added later.