Burp Suite Tutorial for Beginners

This Burp Suite tutorial is written for QA engineers and aspiring security-minded testers who need a practical start, not a certification dump. Burp Suite is an intercepting proxy and web testing platform. It sits between your browser and the application so you can see, pause, edit, replay, and compare HTTP and HTTPS traffic. Once you can do that reliably, many security and API questions become testable instead of mysterious.

In this guide you will set up Burp Suite proxy for QA work, intercept HTTP requests, learn Repeater and Intruder basics, understand Community vs Pro, and practice workflows useful for OWASP-style checks. You will also see common mistakes, a beginner lab checklist, and how Burp fits beside functional automation rather than replacing it.

Practice only on systems you are authorized to test. Prefer local labs and company staging. Never point aggressive scans at production without written approval.

Burp Suite Tutorial Basics: What the Tool Is (and Is Not)

Burp Suite is primarily:

• A proxy that captures browser or API client traffic.
• A set of manual testing tools for replaying and manipulating requests.
• A project workspace for notes, history, and findings.
• In Pro, an automated scanner and advanced productivity features.

Burp is not:

• A replacement for understanding HTTP.
• A magic "find all bugs" button.
• Safe to use carelessly on shared environments.
• The only tool you will ever need for API or mobile testing.

If you already know basics from an API testing tutorial, Burp will feel like a more powerful, security-oriented cousin of Postman for browser-driven flows.

Burp Community vs Pro

Area	Community (free)	Professional
Proxy, HTTP history	Yes	Yes
Repeater	Yes	Yes
Intruder	Yes, throttled	Faster, more efficient
Scanner	No full automated web vuln scanner	Yes
Target site map / crawl	Basic manual mapping	Stronger crawl and audit workflows
Reporting	Limited	Richer reports
Best for	Learning, manual QA security checks	Professional assessments, scale

For this Burp Suite tutorial, Community is enough. Learn manual method first. Pro becomes valuable when your job requires frequent automated audits or large site coverage.

Install and First Launch

High-level setup:

1. Download Burp Suite Community from PortSwigger's official site.
2. Install for your OS.
3. Launch and create a temporary project or a named project on disk.
4. Use default proxy settings unless your lab requires otherwise: usually 127.0.0.1:8080.
5. Open the Proxy tool and confirm the proxy listener is running.

Name projects by application and date when you test company staging regularly. History becomes evidence.

Burp Suite Proxy Setup for QA

There are two common beginner paths.

Path A: Burp's Built-in Browser

Newer Burp versions can launch a preconfigured browser. This is often the least painful path for first-time users because proxy and certificate issues are reduced.

1. In Proxy, find the option to open the browser.
2. Visit your staging app.
3. Perform a login or simple navigation.
4. Check Proxy > HTTP history for requests.

If history populates, your capture path works.

Path B: External Browser + System or Browser Proxy

1. Set browser or OS proxy to 127.0.0.1 port 8080.
2. Visit http://burpsuite or open a site and follow Burp's CA install guidance.
3. Import and trust the Burp Certificate Authority for HTTPS decryption.
4. Visit an HTTPS staging site.
5. Confirm you can see decrypted requests, not only CONNECT tunnels.

Certificate Trust in Plain Language

Without trusting Burp's CA, HTTPS pages may fail or show opaque tunnels. You are installing a lab certificate that lets Burp decrypt traffic to your machine so you can test. Remove or disable that trust when you are done if you use a shared machine profile, and do not casually proxy your daily banking session through a lab tool.

QA-Friendly Hygiene

• Keep a second browser profile that is not proxied for docs and chat.
• Scope Burp to target domains when possible.
• Turn Intercept off while you map the app casually.
• Clear or archive project files that contain session tokens before sharing.

How to Intercept HTTP Requests in Burp

Intercept is the pause button.

Basic intercept flow

1. Go to Proxy > Intercept.
2. Click Intercept is off so it becomes Intercept is on.
3. In the browser, submit a form or click a button.
4. Burp shows the outgoing request.
5. Inspect:
   • Request line: method and path
   • Host and path parameters
   • Cookies and Authorization headers
   • Body (form fields or JSON)
6. Optionally edit a value.
7. Click Forward to send it, or Drop to block it.
8. Turn intercept off when finished so the browser stops freezing.

When to use intercept

Use intercept when you need to:

• Change a hidden form field the UI does not expose.
• Tamper with a price, role id, or boolean flag before it leaves the client.
• Remove a security header or token to see server validation.
• Confirm whether the server trusts client-side-only checks.

When not to use intercept

Leave intercept off for ordinary browsing and mapping. Constant pausing is exhausting and easy to misread. Use HTTP history and Repeater for most analysis.

HTTP History: Your Real Home Screen

HTTP history is where beginners should live.

Useful habits:

• Sort or filter by domain.
• Find the request that corresponds to a UI action.
• Look at both request and response.
• Note status codes, redirects, and JSON error bodies.
• Send interesting requests to Repeater with right-click.

Example QA questions answered by history:

• Which API call loads the order details?
• Is the role sent only in a JWT, or also as a body parameter?
• Does the client send a price the server should ignore?
• After logout, do APIs still accept the old cookie?

Repeater Basics

Repeater is a manual request editor and replayer. It is the most important Burp tool for thoughtful QA security work.

Workflow

1. From HTTP history, right-click a request > Send to Repeater.
2. In Repeater, edit headers, cookies, path ids, or JSON fields.
3. Click Send.
4. Compare responses: status, body, timing, error text.
5. Keep notes on what changed.

High-value Repeater exercises for QA

Goal	What to change	What to observe
Broken access control	Object id belonging to another user	403/404 vs 200 with foreign data
Auth enforcement	Remove Authorization or session cookie	401/403 vs successful data
Mass assignment	Add "role":"admin" to JSON	Whether server ignores it
Injection probe	Append ' or a marker to a search field	Errors, reflection, anomalies
Cache or CDN oddities	Change headers like Accept	Unexpected content variants

Repeater teaches server truth. The UI may hide buttons, but the API may still answer.

Intruder Basics (Use Gently)

Intruder automates many similar requests with payload positions. In Community it is slower. That is fine for learning.

Simple Intruder use cases for QA

• Iterate order ids from 1000 to 1020 to spot insecure direct object references.
• Try a short list of roles or feature flags.
• Fuzz one parameter with a small safe payload set in staging.

Basic steps

1. Send a request to Intruder.
2. Clear default payload positions if needed, then mark one position with the payload markers.
3. Load a small payload list.
4. Start the attack.
5. Sort results by status code or response length.
6. Investigate outliers in Repeater.

Safety rules

• Tiny lists first.
• Staging only unless approved.
• Avoid account lockout endpoints with huge password lists.
• Stop if you cause data corruption or service degradation.

Intruder is optional for day-one QA. Master Proxy and Repeater first.

Decoder, Comparer, and Target Map

Decoder

Convert URL encoding, Base64, HTML entities, and more. Useful when tokens or parameters look opaque.

Comparer

Diff two responses. Great when a single character change should not alter authorization outcomes but does, or when two roles should differ and do not.

Target / site map

As you browse, Burp builds a map of visited hosts and paths. Use it to see unvisited links discovered in responses and to keep scope visible.

Using Burp to Test OWASP-Style Risks

Burp does not "do OWASP" by itself. You use it to execute tests.

1. Broken access control

1. Log in as user A, capture GET /api/invoices/55.
2. Send to Repeater.
3. Log in as user B in the browser (or swap B's cookie/token into the request carefully).
4. Request user A's invoice id as B.
5. Confirm denial.

See also authentication and authorization testing.

If your team prefers an open source scanner-first workflow, compare this manual proxy flow with the OWASP ZAP tutorial.

2. Injection and XSS reflection

1. Capture a search or profile update.
2. Insert a unique marker.
3. Check response reflection.
4. Escalate with safe payloads in staging.

Deep method: XSS testing guide.

3. Authentication flaws

1. Capture login and token refresh calls.
2. Replay expired tokens.
3. Try missing tokens on protected routes.
4. Check password reset tokens for predictability only in authorized labs.

More detail: API authentication testing.

4. Security misconfiguration signals

While browsing history, note:

• Stack traces in responses.
• Directory listings.
• Default credentials pages if in scope.
• Verbose debug headers.
• Missing HSTS on HTTPS apps (report as hardening, with context).

5. Business logic abuse

Burp shines here because logic bugs are hard for scanners:

• Apply a coupon twice by replaying the redeem request.
• Skip a step in a multi-step checkout by calling the final API early.
• Change quantity to negative or extreme values.
• Reuse a one-time token.

These are classic QA-plus-security wins.

Beginner Lab Workflow (End to End)

Use this sequence on a legal practice app (for example a local OWASP lab or company staging with permission).

1. Start Burp project named lab-date
2. Configure browser/proxy and confirm HTTPS history
3. Turn intercept off
4. Map the app: register, login, core features
5. Tag interesting API calls in history
6. Build a simple notes list: auth token location, object ids, admin routes
7. For each critical object endpoint, test horizontal access with a second user
8. For each rich input, test marker reflection and basic XSS probes
9. For each state-changing POST/PUT/DELETE, check authZ and replay behavior
10. Document findings with request/response evidence
11. Retest after fixes using saved Repeater tabs

Reading a Request Like a Tester

A captured request is a checklist:

POST /api/projects/12/members HTTP/1.1
Host: staging.example.com
Cookie: session=...
Authorization: Bearer ...
Content-Type: application/json

{"email":"user@example.com","role":"viewer"}

Questions:

• What happens if project 12 becomes 13 owned by someone else?
• What if role is owner?
• What if the session is omitted?
• What if email is an existing member?
• What if Content-Type is wrong but body is still parsed?
• Is there CSRF protection for cookie-based session flows?

Write those questions down. Burp only executes them.

Match Burp Work to Test Cases

Security testing still benefits from structure. Example cases:

ID	Title	Steps in Burp	Expected
SEC-IDOR-01	User cannot read another user's order	Repeater: swap order id with peer's id	403 or 404, no order payload
SEC-AUTH-02	Protected route rejects missing token	Repeater: delete Authorization	401
SEC-LOGIC-03	Coupon cannot be applied twice	Replay redeem request	Second call fails
SEC-XSS-04	Profile bio encodes HTML	Submit marker and payload via Proxy	No script execution

Store expected results in your test management tool the same way you would for functional tests.

Burp for SPA and API-Heavy Apps

Modern apps often look empty in page source. Burp history shows the real API surface.

Tips:

• Filter history by /api.
• Watch for GraphQL POST /graphql and inspect query bodies.
• Export a few requests as curl for automation engineers.
• Validate whether mobile WebViews or separate clients share the same APIs.

If your team already uses Postman collections, Burp still helps for browser cookie flows, subtle header differences, and quick tampering during exploratory sessions.

Performance, Scope, and Professionalism

Good Burp users are boring in the best way:

• They stay in scope.
• They avoid destructive payloads on shared data.
• They minimize scan noise.
• They redact secrets in screenshots.
• They file bugs with clear business impact, not only tool output.

If you are testing as QA, coordinate with security and platform teams so your sessions do not trigger alerts unnecessarily or violate policy.

Common Mistakes Beginners Make

1. Leaving intercept on all day

The browser feels broken, you lose patience, and you miss the forest for the trees. Use intercept sparingly.

2. Not installing the CA, then blaming the app

If HTTPS does not decrypt, fix the proxy trust path before testing the product.

3. Proxying everything, including personal browsing

Use a dedicated browser profile. Keep tokens and personal accounts out of lab projects.

4. Huge Intruder lists on login endpoints

You can lock accounts or look like an attacker to monitoring. Use tiny lists and test accounts.

5. Trusting the UI map only

Hidden admin JSON endpoints often matter more than visible buttons.

6. No second user for access control

Without user A and user B, you cannot prove horizontal privilege issues.

7. Filing "Burp found something" without impact

Engineers need reproduction, affected role, and risk. Tool screenshots help, but they are not the whole report.

8. Skipping retest

After a fix, replay the exact Repeater request that failed before. Confirm the specific issue, then nearby variants.

9. Confusing client validation with server validation

If Burp can bypass a UI limit, the server must still enforce the rule. That is a feature quality issue as much as a security issue.

10. Jumping to scanner output before learning manual basics

Manual Proxy and Repeater skills transfer to every tool. Scanner output without fundamentals creates noise.

Community Learning Path (Two Weeks)

Week 1

• Install, proxy, certificate, history.
• Map one app completely.
• Twenty Repeater experiments on auth and object ids.
• Write three formal findings or practice notes.

Week 2

• Add controlled Intruder id walks.
• Practice XSS reflection checks.
• Practice logout and session replay checks.
• Pair with a developer to review one fix.

Then deepen with specialized guides on XSS and access control linked above.

How Burp Fits With Automation and CI

Burp is usually interactive. Automation still matters:

• Regression unit tests for authorization helpers.
• API tests that assert 401/403 behavior.
• Smoke checks for security headers.
• Dedicated DAST in CI where licensed and scoped.

Use Burp to discover. Use automation to prevent recurrence. That combination is what strong QA teams build.

Soft Practice CTA

If you want structured challenges that build the same instincts Burp rewards (careful observation, edge cases, clear evidence), try a battle in QABattle or sign up and work through security and API tracks with feedback loops.

Final Takeaway

A solid Burp Suite tutorial result is not "I clicked all the tools." It is this skill loop:

1. Capture real traffic.
2. Understand what the client sends.
3. Change one thing at a time.
4. Observe the server's true behavior.
5. Document impact and retest fixes.

Start with proxy setup, HTTP history, and Repeater. Add Intruder only when you have a precise question. Stay authorized, stay scoped, and let Burp make the invisible HTTP conversation visible. Once you can see that conversation clearly, many "security mysteries" become ordinary, high-value test cases.