In a Burp Suite interview, avoid sounding like you only know button names. Explain the request path, the tested parameter, the authorization boundary, the evidence, and the safe remediation.
Fundamentals and safe test framing (5)
Define Burp, scope, HTTPS interception and the legal boundary clearly.
L11. What is Burp Suite and why do penetration testers use it?
Direct answer: Burp Suite is a web application security testing platform used to intercept, inspect, modify, replay and analyze HTTP, HTTPS and WebSocket traffic during authorized testing.
Why it matters in production: It gives the tester evidence from the real request and response path instead of relying only on screenshots or scanner output.
Evidence to mention:
- authorized scope and Rules of Engagement
- captured request and response
- affected parameter or endpoint
- business impact
- retest evidence after fix
Weak answer / common trap: A weak answer says only 'Burp is a hacking tool' and does not explain the testing workflow.
Strong answer framing: Say: I use Burp to capture the request, understand the application flow, test one change at a time, prove impact, and report reproducible evidence.
L12. How do you configure Burp to intercept HTTPS traffic?
Direct answer: Set the browser proxy to Burp's listener, normally 127.0.0.1:8080, then install and trust Burp's CA certificate in the test browser or device.
Why it matters in production: Without the trusted CA, HTTPS interception fails or the browser blocks traffic, so the tester cannot inspect application requests properly.
Evidence to mention:
- browser proxy setting
- Burp listener status
- Burp CA certificate installed
- HTTPS request visible in Proxy HTTP history
- scope set to the authorized target
Weak answer / common trap: Do not disable all browser security permanently or test production apps outside scope just because interception works.
Strong answer framing: In the interview, mention proxy, CA certificate, target scope, and a quick smoke test by loading one authorized HTTPS page.
L13. What is the difference between Proxy, Repeater and Intruder?
Direct answer: Proxy captures and intercepts traffic, Repeater manually modifies and resends selected requests, and Intruder automates payload-based testing across chosen positions.
Why it matters in production: These tools map to three different jobs: observe the flow, prove a hypothesis manually, then scale a controlled test only where authorization allows.
Evidence to mention:
- Proxy HTTP history
- Repeater tab with changed parameter
- Intruder positions and payload list
- response code, length and timing differences
- rate limits agreed in scope
Weak answer / common trap: The common mistake is sending every request to Intruder without understanding what parameter matters.
Strong answer framing: Say: I capture in Proxy, prove manually in Repeater, then use Intruder only for a narrow authorized test with safe rate limits.
L24. What should you confirm before starting any penetration test?
Direct answer: Confirm written authorization, scope, test windows, allowed techniques, excluded targets, rate limits, contact points, data-handling rules and stop conditions.
Why it matters in production: Penetration testing without clear authorization and boundaries can create legal risk, downtime or data exposure.
Evidence to mention:
- signed scope or SOW
- target URLs/IP ranges
- allowed tools and test types
- emergency contact
- evidence-handling and reporting rules
Weak answer / common trap: A weak answer jumps straight to tools before checking whether the test is legal and safe.
Strong answer framing: Start every methodology answer with scope and authorization, then move to recon, testing, validation, reporting and retest.
L35. Give a crisp L3 answer for a Burp Suite web pentest workflow.
Direct answer: I confirm scope, capture normal traffic in Proxy, map the application, test key flows in Repeater, use Intruder only for controlled payload testing, validate scanner leads manually, check blind issues with Collaborator, then report reproducible business impact.
Why it matters in production: That answer is senior because it is legal, ordered, evidence-led and production-safe.
Evidence to mention:
- scope and authorization
- site map and user journeys
- manual Repeater proof
- controlled Intruder results
- validated report and retest
Weak answer / common trap: A weak senior answer lists tools without connecting them to scope, evidence, impact and remediation.
Strong answer framing: Close with: My final deliverable is not a tool output; it is a verified risk story with request/response proof and a fix the client can implement.
Burp tools and request workflow (5)
Trace how Proxy, Target, Repeater, Intruder, Scanner and support tools work together.
L26. How do Target and Site map help during a web application test?
Direct answer: Target and Site map organize discovered hosts, paths, parameters and responses so the tester can understand application structure and avoid testing random traffic.
Why it matters in production: A clean map improves coverage, avoids noise, and helps identify unauthenticated pages, authenticated flows, hidden endpoints and duplicate requests.
Evidence to mention:
- target scope rules
- site map tree
- interesting parameters
- login and role-specific paths
- out-of-scope traffic excluded
Weak answer / common trap: Do not treat the site map as complete automatically; dynamic applications often need manual navigation and authenticated crawling.
Strong answer framing: Explain that you build the map from normal user journeys, then test key endpoints by role and function.
L27. How do you use Repeater to test an authorization issue?
Direct answer: Send the captured request to Repeater, change one object identifier, role-dependent parameter or session context at a time, and compare the server response.
Why it matters in production: Authorization bugs like IDOR are proven by showing that one user can access or modify another user's data without permission.
Evidence to mention:
- original user request
- modified object ID or account ID
- second-user comparison
- response body and status
- business impact of exposed data/action
Weak answer / common trap: Do not call it IDOR only because the URL has an ID; prove the missing authorization check.
Strong answer framing: A strong answer says: I compare User A and User B, change only the object reference, and prove whether the server enforces ownership.
L28. When would you use Intruder, and which attack type would you choose?
Direct answer: Use Intruder for controlled payload testing, such as fuzzing one parameter, pairing related values, or testing combinations under explicit authorization.
Why it matters in production: The attack type controls how payloads are placed: Sniper for one-position fuzzing, Battering ram for same payload in multiple places, Pitchfork for related lists, and Cluster bomb for combinations.
Evidence to mention:
- defined payload positions
- payload list source
- attack type
- throttle/rate limit
- interesting response differences
Weak answer / common trap: Do not use Intruder for uncontrolled brute force or high-volume production testing without explicit approval.
Strong answer framing: Say the use case first, then pick the smallest attack type that proves the hypothesis safely.
L29. How is Burp Scanner different from manual testing?
Direct answer: Burp Scanner automates crawling and vulnerability checks, while manual testing validates context, business logic, chained impact and authorization details.
Why it matters in production: Scanners are useful for coverage and repeatable checks, but many high-impact findings require human reasoning and proof.
Evidence to mention:
- scanner issue detail
- manual Repeater validation
- false-positive review
- business logic test case
- final reproduction steps
Weak answer / common trap: A weak answer trusts scanner severity without verifying exploitability and impact.
Strong answer framing: Frame Scanner as an assistant: it finds leads, then the tester validates, prioritizes and explains the risk.
L210. What are Decoder, Comparer, Logger and Inspector used for?
Direct answer: Decoder handles encoding and decoding, Comparer shows differences between messages, Logger records Burp-generated traffic, and Inspector helps analyze and edit structured request/response data.
Why it matters in production: These tools improve accuracy when parameters are encoded, responses look similar, or the tester needs to trace exactly what changed.
Evidence to mention:
- Base64, URL or HTML encoding
- before/after response diff
- Logger filter
- headers, cookies and body parameters
- notes on the tested request
Weak answer / common trap: Do not manually guess encoded values when Burp can show or transform the data safely.
Strong answer framing: Say: I use support tools to reduce mistakes; Decoder for transformations, Comparer for deltas, Logger for traceability, and Inspector for structured editing.
Web pentest scenarios and controls (5)
Answer authorization, session, upload, rate-limit and blind-testing questions with production evidence.
L211. How do you handle authentication and session testing in Burp?
Direct answer: Capture login, session cookies, CSRF tokens and role-specific requests, then test whether sessions expire, tokens rotate, logout works, and roles are enforced server-side.
Why it matters in production: Session flaws can expose accounts even when the login page itself looks secure.
Evidence to mention:
- Set-Cookie attributes
- session timeout behavior
- logout invalidation
- CSRF token validation
- role-based request comparison
Weak answer / common trap: Do not only check whether a cookie exists; check how the server validates and invalidates the session.
Strong answer framing: Answer with a sequence: login capture, token review, role comparison, timeout/logout test, and evidence from repeated requests.
L212. How would you test access control and IDOR with Burp?
Direct answer: Create or use two authorized test accounts, capture the same function for both roles, swap object references in Repeater, and verify whether the server blocks unauthorized access.
Why it matters in production: Access control is one of the highest-impact web risks because it directly affects customer data and privileged actions.
Evidence to mention:
- two test accounts
- role and ownership matrix
- object IDs or UUIDs
- server-side deny evidence
- screenshot or response showing impact
Weak answer / common trap: Do not assume a hidden button or disabled UI is access control; the server must enforce it.
Strong answer framing: Say: I test horizontal access, vertical access and function-level access control using direct requests, not only the browser UI.
L213. How do you test file upload safely?
Direct answer: Test file extension, MIME type, content validation, size limits, storage path, download permissions and whether uploaded content can execute, always inside the agreed scope.
Why it matters in production: File upload flaws can lead to malware storage, data leakage, stored XSS or server-side code execution depending on the stack.
Evidence to mention:
- allowed file policy
- server response and stored URL
- content-type handling
- access permissions
- safe non-destructive proof file
Weak answer / common trap: Do not upload live malware or destructive payloads; use harmless proof files and agreed test strings.
Strong answer framing: Explain the control points: client validation, server validation, storage, execution prevention, access control and cleanup.
L214. How do you test rate limiting or brute-force protection responsibly?
Direct answer: Use a small approved test set, throttle requests, monitor lockout and error behavior, and stop at the agreed threshold.
Why it matters in production: Rate-limit testing can affect accounts and infrastructure, so it must be scoped and measured carefully.
Evidence to mention:
- approved test account
- request count and rate
- lockout or delay behavior
- error message differences
- evidence of per-user/IP/session controls
Weak answer / common trap: Do not run uncontrolled credential attacks or use real user passwords.
Strong answer framing: Say: I test the control, not the users; the goal is to prove lockout, throttling, enumeration resistance and monitoring.
L315. What is Burp Collaborator and when would you use it?
Direct answer: Burp Collaborator is used to detect out-of-band interactions, such as DNS or HTTP callbacks, when the vulnerable behavior is not visible in the immediate response.
Why it matters in production: It is useful for blind SSRF, blind XXE, blind command injection and similar issues where the application interacts with an external service.
Evidence to mention:
- unique Collaborator payload
- injected request location
- DNS or HTTP interaction
- timestamp correlation
- business impact and safe proof
Weak answer / common trap: Do not claim a blind issue without correlating the callback to the exact payload and request.
Strong answer framing: Frame it as evidence: I inject a unique payload, poll for interaction, then tie the callback to the tested parameter and explain the impact.
Troubleshooting, validation and reporting (5)
Show how to fix setup issues, remove false positives, test safely and write a useful report.
L216. Burp is not intercepting traffic. How do you troubleshoot?
Direct answer: Check browser proxy settings, Burp listener status, HTTPS certificate trust, browser proxy bypass rules, VPN/security agent interference, and whether intercept is on or traffic is only in HTTP history.
Why it matters in production: Most Burp setup failures are environment issues, not application issues.
Evidence to mention:
- Proxy listener running
- browser proxy host and port
- CA certificate trust
- HTTP history entries
- scope and intercept toggle
Weak answer / common trap: Do not start changing application payloads before confirming the traffic path reaches Burp.
Strong answer framing: Give an ordered answer: listener, browser proxy, certificate, network bypass, then one authorized HTTPS smoke test.
L317. How do you reduce false positives in a Burp finding?
Direct answer: Reproduce the issue manually, remove unnecessary payload noise, verify the vulnerable parameter, check required privileges, and prove business impact with the smallest safe request.
Why it matters in production: A report is useful only when the client can reproduce and prioritize the finding confidently.
Evidence to mention:
- manual Repeater proof
- exact affected endpoint
- required role/auth state
- before/after response evidence
- clear impact statement
Weak answer / common trap: Do not paste a scanner issue into the report without confirming it in the application context.
Strong answer framing: Say: Scanner output is a lead; the final finding needs manual validation, impact, steps, evidence and remediation.
L218. What makes a good penetration-test report?
Direct answer: A good report has a clear title, severity, affected asset, business impact, reproduction steps, evidence, root cause, remediation and retest status.
Why it matters in production: Clients need actionable risk, not just a long list of technical observations.
Evidence to mention:
- endpoint and parameter
- role or account used
- step-by-step reproduction
- screenshots or request/response evidence
- fix guidance and retest result
Weak answer / common trap: A weak report says 'SQL injection found' without showing where, how, impact and fix.
Strong answer framing: Use the pattern: what is wrong, why it matters, how to reproduce, how to fix, and how to verify closure.
L219. How would you test SQL injection and XSS with Burp?
Direct answer: Identify input points, send one request to Repeater, change one parameter at a time, observe errors or behavior changes, and validate safely without damaging data or users.
Why it matters in production: SQL injection and XSS are common interview topics, but the strong answer focuses on method, safety and proof rather than payload memorization.
Evidence to mention:
- affected parameter
- baseline response
- controlled test input
- error/behavior delta
- safe proof and remediation suggestion
Weak answer / common trap: Do not dump data, bypass real accounts or run destructive payloads in an interview answer.
Strong answer framing: Say: I prove the class safely, capture request/response evidence, explain impact, and recommend parameterized queries for SQLi and output encoding/contextual sanitization for XSS.
L220. How do you test APIs and WebSockets using Burp?
Direct answer: Capture API or WebSocket messages, understand authentication and object model, replay messages in Repeater, test role/object changes, and compare server responses.
Why it matters in production: Modern applications often move critical logic into APIs and real-time channels, so the browser UI may not show the full attack surface.
Evidence to mention:
- API endpoint and method
- JSON body or GraphQL query
- authorization header or cookie
- WebSocket message payload
- role/object comparison
Weak answer / common trap: Do not assume an API is safe because it is called by a trusted frontend.
Strong answer framing: Frame the answer around server-side enforcement: auth, object ownership, input validation, rate limiting and clear error handling.
20-minute drill: Answer five questions out loud: Proxy setup, Repeater proof, Intruder attack type, Collaborator blind test, and report format. Keep every answer tied to authorized scope.