Scope, permission, and the honesty gate

Everything you have learned is a skill that is legitimate in one place and a crime in another, and the only thing that separates the two is permission. This lesson is the line: where you are allowed to test, how to read the rules, and the honesty gate that keeps your findings, and you, credible. Foundations introduced this; here it becomes a working discipline.

The three places you may test#

You are clearly allowed to test in exactly three situations, and it is worth being able to name them:

• Your own systems, and deliberately vulnerable labs built for practice, this Academy, and anything you own and run.
• A bug-bounty or vulnerability-disclosure program, but only the assets it lists as in scope, and only within its stated rules.
• A written engagement: a client who has signed a contract or authorisation letter that names the targets, the dates, and what you may do.

Outside those, you do not have permission, and "the bug was easy to find" or "I did not cause harm" is not a defence. The technical ability to reach a system is never the same as the authorisation to test it.

Reading a scope#

On a program, the scope is a document, and reading it correctly is a skill:

• In-scope assets: the exact domains, apps, IP ranges, or products you may test. *.example.com is not the same as example.com; a listed app is not a licence for the whole company. Test only what is listed.
• Out-of-scope assets: explicitly named things you must not touch, often third-party services, specific subdomains, or acquired companies. Respect these absolutely.
• Out-of-scope vulnerabilities: classes the program will not accept (self-XSS, missing headers alone, best-practice nags, findings requiring an unlikely precondition). Testing for these wastes your time and theirs.
• Rules of engagement: rate limits, whether automated scanning is allowed, whether you may test account takeover only against your own accounts, what data you may access, and how to report. Bans on heavy automation and on touching other users' data are near-universal.

When scope is ambiguous, ask before you test, and keep the answer. "I assumed it was in scope" is not where you want to be.

The techniques that most easily cross the line#

Some skills in this track are especially easy to take too far, and deserve a named caution:

• Brute force and automated scanning can lock out real users and overload services; many programs forbid them or require a tiny, careful sample.
• Injection and server-side payloads can corrupt data or execute commands, use the gentlest proof, never destructive ones.
• Accessing other users' data to "measure impact", do not. Prove cross-account access with two accounts you own; never trawl real strangers' records.
• Denial of service (billion-laughs, resource exhaustion) is almost always out of scope, do not demonstrate it.

The rule under all of these: prove the vulnerability with the minimum, benign action, and stop.

The honesty gate at every stage#

The honesty gate is the same rule you have met all along, now stated for the whole engagement: a finding is only what you actually reproduced, and its impact is only what you actually demonstrated.

• It is a finding if it reaches another user's data or a privileged action you should not have: proven on accounts you own. It is not a finding if it reaches your own data, public data, or nothing.
• The impact is what you showed, not what you imagine. "Bob read Alice's order, both my accounts" is honest. "Leaks all two million users", when you read one row and assumed the rest, is not; describe the scale from the id scheme, but claim only what you pulled.
• If you did not confirm it, say so: "running a version with a known RCE, not reproduced" is an honest, still-valuable finding. Claiming "RCE confirmed" without a shell is how you lose a triager's trust for every future report.

Overclaiming is the fastest way to get reports rejected and a reputation damaged. Underclaiming a real, proven bug is just leaving money on the table. Precision is the professional standard.

Your exercise#

This platform has a Programs section with real bug-bounty programs and their scopes. Open a few and practise reading them like a tester: what assets are in scope, what is explicitly out, what vulnerability classes are excluded, and what the rules say about automation and data access. Note, for one program, exactly what you would and would not be allowed to do. That reading skill is tested on every real engagement and every exam scenario that hands you a scope or an engagement letter.

Where this goes next#

You have found the bug, kept the evidence, and stayed in scope. Now it has to land: the next lesson is writing the report, the document that decides whether all of this work counts or gets closed as "could not reproduce".