What are you allowed to test?

You can now read a request, change it, and find a real bug. This last lesson is the most important one on the path, and it is not about a technique. It is about the single question that separates a security researcher from someone in serious trouble: am I allowed to test this?

Everything you learned here works on any website in the world. That is exactly the problem. The skills do not know or care whether you have permission, so you have to. Testing a site you were not invited to test is not "just looking", and it is not a grey area. In most countries it is a crime, the same way trying the locks on a stranger's house is, even if you never go in. So before you point any of this at a real target, learn where the line is. It is simple, and staying on the right side of it is easy once you know it.

The one rule#

Only test what you have been given permission to test.

That is the whole thing. Everything below is just what "permission" looks like in practice. There are three places you clearly have it, and everywhere else you do not.

Where you are allowed#

1. Your own machine. The labs on this site run on an instance that is yours: you pressed Start, it belongs to your session, and nothing you do to it touches anyone else. You can also install deliberately vulnerable apps on your own computer and attack them all day. This is the safest place to practise, and there is a lot of it. You will never run out of things to break that are yours to break.

2. A bug bounty or vulnerability disclosure program. Many companies publish an open invitation: "here is what you may test, here is what you may not, and here is how to tell us what you find." Platforms like HackerOne, Bugcrowd and Intigriti list thousands of them, and this site's own Programs section collects them too. When a company runs a program, they are giving permission in advance, in writing, to anyone who follows their rules. That written invitation is called the scope, and reading it is the first thing you do, every time.

3. A client who hired you, in writing. Professional penetration testers get a signed contract that says exactly what they may test and when. That contract is their permission. You are not there yet, but that is the shape it takes: permission is always explicit, always written down, never assumed.

Notice what these have in common. In every case, someone with the authority to say yes has said yes, out loud, before you started. If nobody has said yes, the answer is no.

What "scope" means, and why you read it first#

When a company runs a bug bounty program, the scope is the list of what is in and what is out. It looks roughly like this:

• In scope: app.example.com, api.example.com, the iOS app.
• Out of scope: blog.example.com, anything on example-partner.com, the corporate email system.
• Not allowed: denial-of-service attacks, automated scanners at high speed, testing with real customer accounts, social engineering the staff.

The scope is the exact edge of your permission. A target that is in scope is one you may test. A target that is out of scope is one you may not, even though it belongs to the same company and sits one subdomain away. "It was basically the same company" is not a defence; the scope drew the line and you crossed it.

So the habit, from your very first day: find the scope, read the whole scope, and stay inside it. Every program has one. If you cannot find a scope, there is no program, and there is no permission.

The honesty gate, one more time#

You met this in the last lesson, and it belongs here too, because it is part of testing responsibly. When you do find something, be honest about what it actually is:

• It is a finding if it reaches another person's data or lets you do something you should not be able to do.
• It is not a finding if it only reaches your own data, or something already public to everyone, however clever the trick was.

Reporting things that are not real bugs wastes the time of the people reading your reports and quietly ruins your reputation with them. Claim exactly what you proved, no more. A small, true finding is worth more than a big, exaggerated one.

Testing gently, even where you are allowed#

Permission to test is not permission to do damage. Even inside a program's scope, the rules of good behaviour are:

• Do not break the thing for other people. No flooding a site with traffic, no deleting data you did not create, no filling a database with junk. You are looking for problems, not causing them.
• Do not go further than you need to prove it. Once you have shown you can read another user's record, stop. You do not need to read a thousand of them to make the point, and doing so turns a clean finding into real harm.
• Use test accounts, not real people's. The two-account method you learned uses two accounts you created. Never poke at a stranger's live account to prove a bug.
• Tell them, and give them time to fix it. When you find something real, report it through the channel the program gives you, and let them fix it before you talk about it publicly. This is called responsible disclosure, and it is what keeps the whole system working.

None of this is complicated. It is the difference between someone a company thanks and rewards, and someone a company reports to the police. The skills are identical; only the permission and the manners differ.

What to take away#

• Only test what you have permission to test. If nobody has clearly said yes, the answer is no.
• You clearly have permission in three places: your own machine (these labs included), a bug bounty program that invited you, and a client who hired you in writing.
• A program's scope is the exact edge of your permission. Find it, read all of it, stay inside it. Out of scope is off limits, even next door.
• Be honest about what you found, test gently even where allowed, use your own test accounts, and report what is real through the proper channel.

Your exercise, and where to go next#

There is no lab to break this time; the point of this lesson is to not break things you were not asked to. Instead, do this: open this site's Programs section, pick any program, and read its scope. Notice what is in, what is out, and what is forbidden. Get used to the shape of it, because reading the scope is the first thing you will do on every real target for the rest of your career.

That is the end of Web Security Foundations. You can read and send HTTP, you know the browser is not a boundary, you understand how identity travels, you have found your first access-control bug, and you know where you are allowed to use all of it. The Academy's Access & identity shelf is your next step: the same ideas you learned here, on harder and more realistic targets, all of them yours to test because we built them for exactly that. Go, and welcome.