Free Tool
Bug Bounty Scope Checker
The scope page is the law of a bug bounty programme: it says exactly what you may test and what you must not touch. This trainer gives you a fictional scope page and asks you to mark each target and technique as in scope or out of scope. Get it wrong in real life and testing outside scope is still illegal, even if you report the bug afterwards — so learn it here, where mistakes cost nothing.
Fictional scope, real rule. The programme, company and targets on this page are invented for teaching. The rule is not: never test a system you do not own without written permission, and never test anything a scope page excludes.
What this tool does
A bug bounty programme invites security researchers to test a company's systems and report what they find, usually for a reward. But the invitation is limited: the scope page lists which domains, apps and features are in bounds, which are out of bounds, and which kinds of testing are forbidden. Testing outside the scope — even with good intentions, even if you report what you find — can still be illegal, because the permission that makes the testing lawful only covers what the scope allows.
This trainer teaches you to read a scope page the way an experienced researcher does. You are shown a fictional programme for a made-up company, with a scope table covering eight targets and techniques: some clearly in scope, some clearly out, and some that look tempting but are excluded for good reasons. For each one you mark it in or out, then check your answers and read why each decision is what it is. The explanations cover the reasons companies exclude things — customer data, third-party services, production systems, other people's accounts — because understanding the reason is what stops you making the same mistake on a real programme.
The trainer is for complete beginners who want to start in bug bounties or security research the legal way. It assumes no prior knowledge: the only thing you need to bring is the willingness to read the rules before you touch anything. The guide linked below walks through a real public vulnerability disclosure programme's scope page with the same method, step by step.
Try it
Fictional programme: Northwind Shop — an online shop that runs a bug bounty programme. Read the scope, then mark each item. All names are fictional.
Scope summary: in scope — shop.example.com website, the mobile app (version 3+), and the public API at api.shop.example.com. Out of scope — customer accounts, payment processing, any third-party service, and the company's office network. Forbidden techniques — denial-of-service testing, social engineering of staff or customers, and automated scanning that sends large volumes of requests.
Tick the items you believe are IN scope. Leave the rest unticked.
Waiting. Tick the in-scope items, then check your answers.
How it works
Reading a scope page is a skill with a method. First, read the in-scope list and the out-of-scope list separately — do not assume that anything not listed as out of scope is automatically allowed. Second, read the forbidden techniques, because some methods are banned even against in-scope targets: denial-of-service testing, social engineering and automated scanning are the usual three. Third, look for the details that change the answer: a mobile app may be in scope only from a certain version, an API may be in scope only at a specific address, and a target may be in scope only for certain kinds of testing.
The trickiest items in this trainer are the ones that look reasonable but are excluded. A customer's account is out of scope even with that customer's written permission, because the permission that matters is the company's, not the customer's — the account lives on the company's system, and the company has not authorised you to test it. The payment provider's checkout page belongs to a third party, so the shop's programme cannot authorise testing it. The office network is a corporate system, not a product, and testing it is a different kind of permission entirely. These are the mistakes beginners make most often, and they are exactly the ones that get researchers banned or reported.
When you are unsure on a real programme, the correct action is to ask the programme before you test, not to test and hope. Programmes expect questions about scope, and a researcher who asks first is trusted far more than one who apologises afterwards. Keep the scope page open while you work, test only what it lists, and stop the moment you step outside it.
Limitations
This trainer uses a fictional scope page. Real scope pages are longer, more detailed and sometimes ambiguous, and programmes differ enormously: some welcome broad testing, others allow only a single domain. Nothing here is legal advice, and this page cannot tell you whether a real programme's scope covers a specific target — only that programme's own page, and its team if you ask, can do that.
- The trainer covers scope reading only. It does not teach how to find vulnerabilities, which is a separate skill learned in labs, not on live systems.
- Scope pages change. Always read the current version before you start work on a programme, even one you have tested before.
- Testing outside scope can have legal consequences even when you report the finding. This is the single most important rule in bug bounty hunting, and it is repeated on every research page on this site for a reason.
Examples
Example 1 — the obvious in-scope target. The main website, shop.example.com, is listed as in scope with no conditions. Testing it — within the allowed techniques, without denial-of-service or automated flooding — is what the programme invites. The answer is in scope, and the reason is that the programme says so plainly.
Example 2 — the tempting exclusion. A customer's account, offered with the customer's written permission, feels allowed: you have permission, after all. It is not in scope. The permission that counts is the company's, and the company has excluded customer accounts because testing them risks real people's data. The customer's permission does not override the programme's scope.
Example 3 — the forbidden technique. A denial-of-service test against the shop, even though the shop itself is in scope. The target is allowed but the technique is forbidden, because it would take the shop offline for real customers. Scope has two dimensions — what you may test, and how you may test it — and both must allow what you are doing.
Frequently asked questions
What is a bug bounty scope page?
It is the list that defines a bug bounty programme: which systems you may test, which are off limits, and which techniques are forbidden. It is the permission that makes your testing lawful, and it covers only what it lists.
Is testing outside scope really illegal?
It can be. Testing a system without the owner's permission can break computer-misuse laws, and reporting the bug afterwards does not fix that. The scope page is where the permission lives — outside it, you have none.
What if a scope page is unclear about a target?
Ask the programme before you test. Programmes expect scope questions, and asking first is the mark of a careful researcher. Never test first and hope the scope covered it.
Can a customer give me permission to test their account?
Not for a bug bounty programme. The account lives on the company's system, so only the company's scope can authorise testing it — and most programmes explicitly exclude customer accounts to protect people's data.
Where should a beginner practise testing?
In labs built for learning — intentionally vulnerable applications and training platforms — never on live systems. Our bug bounty guide lists the safe starting points, in order, with the exit criteria for each stage.