BSCP common mistakes
BSCP · Understand the traps and how to avoid them.
Spending the first 30-40 minutes reading every lab and planning a global order instead of starting exploitation on the easiest objective, so time runs out with several achievable flags unclaimed.
Candidates treat the practical exam like a written test and try to triage everything before acting; the fixed time budget rewards throughput, and objectives vary widely in difficulty.
What to do instead
Do a 3-minute scan only: open each application, note the technology and obvious entry points, then immediately work the objective you already have a concrete hypothesis for. Return to harder targets only after banking easy flags.
Sending a payload once, seeing no visible change in the response, and abandoning that injection point, rather than varying encoding, context, and delivery method.
The reflected value may be transformed (HTML-encoded, JSON-escaped, truncated) or the effect may be blind; candidates judge by eyeballing the rendered page instead of the raw response.
What to do instead
For each input, test a benign marker in every context (HTML body, attribute, script string, URL, header), inspect raw responses in Repeater, then escalate encoding and use out-of-band or time-based confirmation when output is absent.
Treating Burp Scanner as the answer: running an audit, reading the issue list, and reporting findings without manually validating or exploiting them.
Scanner output looks authoritative and saves effort, but exam objectives require demonstrated exploitation and the scanner misses logic flaws and multi-step chains entirely.
What to do instead
Use Scanner only to generate hypotheses. For each reported issue, reproduce it manually in Repeater, prove impact with a concrete payload, and spend the remaining effort on manual testing of access control, business logic, and authentication flows.
Testing only the happy path of a feature and never attempting to reach objects or functions belonging to another user or role.
Candidates focus on injection-style bugs they can pattern-match and underweight broken access control, which typically requires mapping IDs, roles, and endpoints first.
What to do instead
Create two accounts at different privilege levels. Map every request that carries an object identifier or role decision, then replay each with the other account's session and with identifiers incremented or swapped, including direct requests to admin endpoints.
Failing to configure the browser-to-Burp proxy correctly, then testing through a partially intercepted setup where some traffic bypasses Burp.
Browser security features, certificate pinning, or leftover proxy exceptions silently exclude requests, so the candidate's mental model of the traffic is wrong.
What to do instead
Verify interception on every host in scope before testing: confirm the request appears in Proxy history and the TLS certificate is Burp's CA. Fix scope, install the CA in the correct store, and disable competing proxy extensions.
Leaving Burp at default settings so Repeater, Intruder, and history are cluttered with out-of-scope and static traffic, making it hard to revisit a promising request.
Defaults capture everything and no naming or commenting discipline is applied, so the candidate cannot reconstruct a multi-step exploit under time pressure.
What to do instead
Set target scope early and enable history filtering to in-scope items only. Rename and comment tabs for each hypothesis, and save promising requests to a dedicated project file or notes as you go.
Using Intruder with the default single-thread and large payload sets for brute force or fuzzing, burning the time budget on slow, noisy attacks.
Candidates default to brute force instead of reasoning about the vulnerability, and the Community edition's throttling makes naive attacks impractical.
What to do instead
Prefer targeted manual tests over volume. When automation is genuinely needed, use Turbo Intruder or a small, high-signal payload list, tune thread count, and add grep-match rules to surface anomalies automatically.
Reporting a vulnerability based on a suspicious response without confirming exploitability, or conversely failing to document a confirmed exploit with reproducible steps.
Candidates either over-claim from error messages and status codes, or complete the exploit but leave no clear evidence trail for scoring.
What to do instead
For every finding, capture the request, the payload, the response proving impact, and the exact reproduction steps. If impact cannot be demonstrated, downgrade the finding rather than reporting speculation.
Ignoring client-side controls as a security boundary, assuming that disabled fields, hidden inputs, or JavaScript validation prevent server-side manipulation.
The UI presents constraints that feel authoritative, and candidates test only through the browser rather than intercepting and modifying requests.
What to do instead
Intercept every state-changing request and modify all parameters, including hidden fields, price and quantity values, role flags, and headers. Assume the server trusts nothing and test whether it re-validates each value.
Chaining nothing: finding a low-impact issue such as an open redirect or information disclosure and stopping there instead of using it to escalate.
Candidates treat findings as isolated checklist items and do not think about how a minor flaw enables token theft, SSRF pivoting, or privilege escalation.
What to do instead
After each finding, ask what it unlocks next: can this redirect feed an OAuth flow, can this SSRF reach internal metadata, can this disclosure reveal credentials for another objective? Document the chain end to end.