Cybersecurity & Information Security

Burp Suite for Beginners: Proxy, Repeater, and Intruder in the Lab

6 min readPublished: August 5, 2026

Professional visual illustration on Burp Suite for beginners in Web and API PT

Quick answer

Burp Suite for beginners should only be tested in a lab or an authorized system. Review Request/Response, server behavior, Roles, State, and impact, using minimal tests that do not compromise data.

Web and API security testing should examine the boundaries of trust, permissions, input, state, and business logic. Every test in this article is intended for a lab, CTF, or a system for which explicit authorization has been given. This article focuses on Burp Suite for beginners and is intended for Web PT students. The goal is to provide a working methodology that can be applied in practice, in a professional interview, and in a work environment, without settling for a dictionary definition.

The main challenge is that data is almost always incomplete. Proxy, HTTP history, and Repeater can point to a direction, but their meaning depends on time, asset, user, and expected activity. Therefore, we will build the test around an investigative question, required evidence, and a clear criterion for completion.

The practical scenario in the article is: modifying a Request to a lab application and comparing Responses. All examples are lab data or descriptions of processes. When dealing with Penetration Testing, Web or Cloud, one must only work with explicit authorization, a defined Scope, and the ability to stop the test.

Installation and Browser Configuration

Proper implementation starts with requirements, not defaults. Define which Use Cases are supported, what is the data volume, who manages the configuration, and what is the rollback mechanism. In Burp Suite for beginners, separate settings that generate Telemetry from settings that filter or enrich it.

After configuration, run a controlled test with expected data, verify that the event was recorded, that the main fields exist, and that the change did not create overload or a blind spot. Every change is saved in a version, with date, owner, reason, and test result.

Target scope and Proxy history

The Burp Suite for beginners process is built in stages with stopping points. Define a goal, Scope, sources, permitted actions, required evidence, roles, and a completion criterion. In offensive environments, add Stop conditions and an emergency channel.

Each stage must have a clear Output: asset map, Timeline, Finding, Rule, Playbook, or report. Moving to the next stage only occurs when the Output is sufficient and reliable; this prevents random work or scope creep without authorization.

Repeater

The 'Repeater' topic is a central part of working with Burp Suite for beginners. It is recommended to break it down into three questions: what is the input, what decision do you want to make, and what evidence is sufficient to justify it. These questions prevent automatic tool use without understanding the goal.

In practice, record Proxy, HTTP history, Repeater, Intruder, Comparer, compare to expected behavior, and define at least one Pivot. The result should be verifiable by another analyst, including limitations and next steps.

Controlled Intruder

The 'Controlled Intruder' topic is a central part of working with Burp Suite for beginners. It is recommended to break it down into three questions: what is the input, what decision do you want to make, and what evidence is sufficient to justify it. These questions prevent automatic tool use without understanding the goal.

Saving Evidence and Project

The 'Saving Evidence and Project' topic is a central part of working with Burp Suite for beginners. It is recommended to break it down into three questions: what is the input, what decision do you want to make, and what evidence is sufficient to justify it. These questions prevent automatic tool use without understanding the goal.

Unique Testing Focus Areas

For this topic, it is recommended to build a focused evidence map in advance. The main testing focus areas are: Proxy, HTTP history, Repeater, Intruder, Comparer, scope controls. The list is not an automatic Checklist; each item is chosen because it can link an entity, action, and time or explain legitimate behavior.

Proxy: Define the expected value, what would be considered an anomaly, and what additional source would confirm the finding.
HTTP history: Define the expected value, what would be considered an anomaly, and what additional source would confirm the finding.
Repeater: Define the expected value, what would be considered an anomaly, and what additional source would confirm the finding.
Intruder: Define the expected value, what would be considered an anomaly, and what additional source would confirm the finding.
Comparer: Define the expected value, what would be considered an anomaly, and what additional source would confirm the finding.
scope controls: Define the expected value, what would be considered an anomaly, and what additional source would confirm the finding.

When one of the focus areas is unavailable, document the gap and choose an alternative. For example, if the Process identifier is unstable, you can use time, Host, User, and Parent; if the Payload is encrypted, use Metadata, volume, frequency, and TLS/DNS context.

Recommended Workflow

Define a Scope and one working question regarding Burp Suite for beginners.
Record the data sources and required evidence: Proxy, HTTP history, Repeater, Intruder.
Create a short Baseline of normal behavior or expected outcome.
Perform the minimal test in a lab environment and save time, input, and output.
Build a Timeline or comparison table and separate fact from interpretation.
Pivot to an additional source to confirm or refute the initial explanation.
Summarize the decision, limitations, recommended action, and Retest criterion.

Practical Scenario

The chosen scenario is modifying a Request to a lab application and comparing Responses. The purpose of the exercise is not to prove attack capability, but to practice collecting, comparing, and documenting safely. Before starting work, define mock data, a time window, and an expected outcome.

At the end of the exercise, a deliverable should be submitted that another analyst or tester can review: a screenshot or Export of the evidence, a short Timeline, an initial hypothesis, corroborating evidence, a limitation, and a recommendation. When there is insufficient evidence, the correct conclusion is that the scenario was not proven.

Stage	What to perform	Deliverable
Preparation	Define Scope, time, and goal. Note which fields or evidence from Proxy, HTTP history, Repeater are expected to appear.	Short test plan
Data Creation	Perform a safe, simulated action related to Burp Suite for beginners, without real information or impact on a production system.	Controlled event/Request/Flow
Collection	Collect the raw evidence and context from another source. Ensure Time zone, identifiers, and integrity.	Two linked pieces of evidence
Analysis	Write what each piece of evidence proves, what it does not prove, and what is the legitimate possible explanation.	Interim conclusion
Completion	Choose closure, escalation, Finding, or Tuning; add recommendation and Retest.	Documented deliverable

Practical Checklist

Check and document: Role and session.
Check and document: Endpoint and method.
Check and document: Request/Response.
Check and document: Object identifier.
Check and document: Server-side effect.
Check and document: Control expected and remediation.
Note Time zone, tool version, and collection time.
Save the raw data before filtering or modification.
Write what the finding proves and what is still unknown.
Define owner and next action with a deadline.

Common Mistakes

Checking only Status code.
Relying on Client-side changes.
Using a dangerous Payload.
Not checking different Roles.
Ignoring business logic.
Reporting without clean Request/Response.

Summary and CTA

Burp Suite for beginners: Proxy, Repeater, and Intruder in the lab is a topic that connects technical knowledge with work discipline. Start with a question, collect only relevant evidence, maintain context and time, and choose an action that can be justified and re-tested.

In HPI's Cybersecurity & AI program, these principles are practiced through systems, logs, and labs. A natural next step is to move on to the linked articles, perform the lab exercise, and save the output as part of a professional portfolio.

FAQ

Is it allowed to test Burp Suite for beginners on a public website?

Not without explicit authorization from the system owner. Even a seemingly simple test can change data, trigger defense mechanisms, or be considered unauthorized access.

What to do when some data is missing?

Document the missing data, check for an alternative source, and reduce the level of confidence. Do not fill in fields with assumptions or present Unknown as valid.

How long should evidence be kept?

The time depends on policy, regulation, cost, and the type of event. It is important to define Retention, Legal hold, and the ability to export evidence in a verifiable format in advance.

How to practice without risking a real system?

Use virtual machines, mock data, CTF, or a dedicated lab. In authorized tests, define Scope, Stop conditions, and backup before starting work.