The PortSwigger Burp Suite Certified Practitioner (BSCP) exam is not a theory test. It checks whether you can use Burp Suite well enough to find, confirm, and exploit web application issues under time pressure. That makes preparation different from a normal certification exam. Reading write-ups helps, but it is not enough on its own. You need a plan that builds tool fluency, pattern recognition, and calm decision-making. This guide is for learners who already know the basics of web security or have started working through PortSwigger Academy and want a practical 30-day roadmap. It covers what to know before you begin, how to divide your month, what to practice each week, and how to review mistakes without just memorizing answers.
Who should use this guide
This guide fits three common types of candidates.
- Junior appsec testers who know HTTP, requests, responses, cookies, and sessions, but need a structured exam plan.
- Bug bounty learners who can find issues in labs but want more consistent workflow and Burp discipline.
- Developers or defenders who understand web apps and common flaws, but are less confident with hands-on testing in Burp Suite.
If you are completely new to web security, this plan may feel too fast. In that case, spend extra time first on HTTP basics, same-origin policy, authentication, sessions, access control, and common input handling flaws. The exam rewards applied knowledge. If your foundation is weak, every task will take longer because you will be guessing instead of testing.
What the exam is really testing
The BSCP is best understood as a practical web testing exam using Burp Suite as your main working environment. The core goal is not to recall definitions. It is to move from observation to exploitation in a reliable way.
That means you need to do four things well:
- Read application behavior correctly. You should spot unusual parameters, hidden workflows, trust boundaries, and state changes.
- Use Burp efficiently. Proxy, Repeater, Intruder, Comparer, Decoder, Logger, site map, and issue-oriented workflow should feel natural.
- Map findings to likely vulnerability classes. For example, a state-changing request with weak object references should immediately make you think about IDOR and access control bypass.
- Verify impact cleanly. The exam is practical. You need to prove the issue, not just suspect it.
Most candidates do not fail because they know nothing. They fail because they waste time. They tunnel into one idea, miss easy signals, or use Burp slowly. A good study plan fixes that.
Prerequisite knowledge and tools
Before starting the 30-day plan, make sure you are comfortable with the following basics.
- HTTP fundamentals: methods, headers, cookies, redirects, caching, content types, and status codes.
- Sessions and authentication: login flow, CSRF tokens, session fixation, logout behavior, remember-me tokens.
- Common web vulnerabilities: SQL injection, XSS, SSRF, command injection, path traversal, access control issues, request smuggling concepts, deserialization basics, and business logic flaws.
- Burp Suite workflow: intercepting traffic, sending to Repeater, adjusting requests, following redirects, comparing responses, and organizing findings.
Your working setup should also be ready before day 1. That matters because setup friction wastes study time and breaks focus.
- Burp Suite installed and updated
- Browser configured with Burp proxy and certificate
- A notes system such as a simple text document, spreadsheet, or note app
- A vulnerability mapping table you will build during practice
- A personal testing checklist for repeatable coverage of each target
Your checklist and mapping table are important. They turn scattered practice into a reusable process. For example, if you see role-based functions, your checklist should remind you to test horizontal and vertical privilege controls. If you see file fetch features, your mapping table should point to SSRF, path traversal, and content-type trust issues.
30-day BSCP preparation plan
This plan assumes about 1.5 to 3 hours a day on weekdays and a longer session on weekends. If you have less time, keep the structure and reduce volume, not quality. Daily consistency matters more than occasional cramming.
Days 1 to 7: Build foundations and Burp speed
The first week is about tool fluency and disciplined workflow. Many candidates rush into advanced labs too early. That creates false confidence because they recognize some attack names but still work slowly.
Focus areas for week 1:
- Proxy and HTTP history review
- Repeater mastery for changing parameters, cookies, headers, methods, and body formats
- Intruder basics for controlled fuzzing and enumeration
- Site map and target mapping
- Manual testing discipline
Daily tasks:
- Take a simple app or lab and map all reachable functionality.
- Practice turning any interesting request into a Repeater-driven test case in under a minute.
- For each endpoint, ask: what input is trusted here, what changes state, and what identity assumptions does the server make?
- Start your checklist. Include authentication, session handling, access control, input handling, file operations, and business logic.
By the end of week 1, you should feel faster in Burp. Not perfect, just less hesitant. The reason this matters is simple: speed frees mental space. If routine actions are automatic, you can spend your attention on reasoning.
Days 8 to 16: Domain review and vulnerability mapping
This is the core learning block. Each day, pick one or two domains and practice them with intention. Do not just solve labs. Write down what made the vulnerability visible and what proof confirmed it.
Recommended domain sequence:
- Days 8 to 9: Access control and IDOR
- Days 10 to 11: Authentication, session flaws, and CSRF-related logic
- Days 12 to 13: Injection classes such as SQLi, command injection, SSTI, and path traversal
- Days 14 to 15: XSS, SSRF, and request manipulation patterns
- Day 16: Business logic flaws and multi-step workflow abuse
For each domain, build a small mapping table with three columns:
- Signal: what you observe in the app
- Likely issue: what class of bug it suggests
- Burp action: what exact test you run next
Example:
- Signal: account page loads another user record when the numeric ID changes
- Likely issue: horizontal privilege escalation / IDOR
- Burp action: replay request in Repeater with another user ID and compare response length, fields, and server messages
This table is useful because it turns vague intuition into repeatable method. That is one of the biggest differences between casual practice and exam-ready practice.
Practice with the relevant page only: https://securitypracticetest.com/portswigger-burp-suite-certified-practitioner-bscp-practice-test/
Days 17 to 23: Practice questions and timed simulations
Now shift from topic learning to exam behavior. The main skill here is triage. You need to decide what to test first, what to ignore for now, and when to switch direction.
Daily structure:
- 20 minutes: warm-up in Burp by replaying and modifying old requests
- 60 to 90 minutes: timed lab or scenario practice
- 30 minutes: review and note-taking
Rules for this phase:
- Work in timed blocks. Do not allow endless rabbit holes.
- Write your hypothesis before testing. Example: “This export endpoint may trust the file path parameter.”
- If a path looks cold after 15 to 20 minutes, mark it and move on.
- Always record the exact payload or request change that proved the issue.
At this stage, your checklist should be mature enough to guide your first pass through a target. A simple example first-pass order:
- Map roles, identity points, and state-changing requests
- Test parameter tampering and object references
- Review input reflection, encoding, and server-side processing
- Inspect file, URL fetch, redirect, and import/export features
- Check multi-step logic for skipped validation or trust assumptions
The point is not to be rigid. The point is to avoid forgetting easy wins under pressure.
Days 24 to 27: Weak-area repair
This phase should be driven by evidence, not preference. Most people enjoy practicing their strengths. That feels productive but often changes nothing. Instead, review your notes and find patterns in your misses.
Look for questions like these:
- Do you often suspect the right issue but fail to prove it?
- Do you miss access control bugs because you focus too much on injection?
- Are you slow when requests use JSON, multipart data, or unusual headers?
- Do you struggle with business logic because the flaw is not obvious in one request?
Then assign one day per weakness. Keep the scope narrow. For example, if your issue is proving access control, spend a full session only on role changes, resource IDs, hidden actions, and server-side trust boundaries. Use paired-user testing if possible. That is often the fastest way to expose authorization gaps.
This is also the right time to tighten your Burp habits:
- Use clear labels in tabs or notes
- Save promising requests
- Compare baseline and tampered responses carefully
- Check status codes, content length, hidden messages, and behavioral differences, not just visible page changes
Days 28 to 30: Final revision and readiness routine
The last three days are not for learning new categories. They are for reducing mistakes. At this point, your job is to become more reliable.
Day 28:
- Run one full simulation with strict timing
- Use only your checklist and notes, not broad searching
- After finishing, review where time was lost
Day 29:
- Review your mapping table and your top 10 recurring signals
- Re-practice a few representative cases from your weakest domains
- Check your setup, browser, Burp configuration, and note templates
Day 30:
- Do a light review only
- Read your checklist once from top to bottom
- Stop early enough to rest well
Candidates often damage performance by overloading the final day. Fatigue is real in practical exams. Clear thinking is worth more than one extra late-night lab.
How to review explanations without memorizing answers
This matters more than many people realize. If you memorize the solution path to a lab, you may feel progress without improving actual skill. The exam will not reward recognition alone.
Use this review method instead:
- First, identify the missed signal. What clue did you overlook? A predictable ID? A reflected parameter? A role-only function?
- Second, name the reasoning gap. Did you not think of the bug class, or did you think of it but fail to test it correctly?
- Third, record the proof step. What exact request change confirmed the issue?
- Fourth, generalize the lesson. Turn the case into a rule for your checklist.
For example, do not write, “Solution was change userID to 124.” Write, “When a state-changing endpoint uses direct object references, test cross-user values and compare authorization behavior, not just response text.” That kind of note transfers to new targets.
Final-week readiness routine
In the final week, use a simple routine before each study session. This trains exam-day behavior.
- Start with a target map. What features exist, what roles exist, and what requests matter?
- Run first-pass checklist coverage. Touch the main vulnerability families quickly.
- Pick the strongest lead. Follow the most evidence-backed path first.
- Time-box deeper work. If it stalls, park it and continue coverage.
- End with a short review. Note one thing you missed and one thing you did efficiently.
This routine builds consistency. Consistency is what keeps you from freezing when a target looks unfamiliar.
Simple web testing checklist for BSCP-style practice
This compact checklist is useful for daily drills and can also serve as a citation-friendly framework for appsec blogs discussing practical web testing workflow.
- Authentication: login flow, brute-force controls, password reset, remember-me behavior, MFA logic
- Session management: cookie flags, session rotation, logout invalidation, token predictability, session scope
- Access control: vertical role checks, horizontal object access, hidden endpoints, method-based bypass, parameter-based trust
- Input handling: reflection, storage, encoding, filtering, type confusion, backend parsing differences
- Server-side execution risks: SQLi, command injection, SSTI, deserialization patterns
- File and path operations: upload validation, traversal, file fetch, import/export, content-type trust
- Client-server trust boundaries: hidden fields, disabled controls, prices, roles, redirects, workflow state
- Business logic: step skipping, duplicate actions, race conditions, coupon abuse, quantity and pricing manipulation
FAQ
How many hours do I need to prepare for BSCP?
It depends on your starting point. If you already use Burp comfortably and know common web flaws, a focused 30 days can be enough. If your Burp workflow is slow or your web fundamentals are shaky, expect longer. What matters most is hands-on quality. Two serious hours with notes and review are better than five distracted hours.
Should I focus more on Burp features or vulnerability theory?
You need both, but practical Burp use should lead. Theory tells you what might be wrong. Burp helps you prove it. A common mistake is reading too much and testing too little. If you cannot quickly modify and replay requests, compare responses, and organize findings, theory alone will not carry you.
What is the best practice strategy in the last week?
Run timed simulations, review misses, and tighten your checklist. Do not chase new advanced topics unless your core coverage is already strong. The last week should improve judgment, pace, and accuracy.
How should I handle retakes if I do not pass?
Treat a failed attempt as data. Do not restart from zero. Write a short post-exam review while details are fresh. Where did time go? Which vulnerability classes felt slow? Did you miss easy coverage because your process broke down? Then rebuild your plan around those findings. Most second-attempt gains come from fixing workflow, not from consuming more theory.
Is it better to repeat the same labs or do new ones?
Both have value, but use them differently. Repeat old labs to improve speed and confirm that you now understand the signal and proof path. Use new labs to test transfer. If you can only solve familiar problems, you are memorizing, not learning.
What should I do on exam day?
Start calm. Map the target first. Use your checklist for quick coverage. Follow the strongest signals. Keep notes as you go. If one lead goes cold, move on and come back later. The exam rewards steady method more than dramatic insight.
A good BSCP preparation plan is not about touching every possible topic. It is about building a reliable way to test web applications with Burp Suite under pressure. If you spend the next 30 days improving speed, coverage, and review quality, you give yourself a much better chance of passing for the right reason: because you can actually do the work.
