The one rule
Security work without explicit authorization is, in most countries, a crime. It does not matter if your motives were good, if you didn't cause damage, or if the bug was obvious. If you accessed a system you were not authorized to access, including just running a scanner against it, you are on the wrong side of the law.
This is the boring, uncomfortable rule that beginners often resist and that careers depend on. Almost every painful prosecution of a curious researcher boils down to this one missing piece of paper.
What "authorization" means
Authorization is a written, specific agreement that names the systems you may touch, the techniques you may use, and the times you may do it. It is given by someone with the actual authority to give it, not just "a friend who works there".
Common forms:
- An employment contract, with a job description that covers security testing.
- A pen-test statement of work or rules of engagement.
- A bug bounty program's safe harbor language (read carefully, not all programs cover everything).
- A Capture-the-Flag or training environment where the operator has invited you in.
Things that are not authorization: "the login form is right there", "I'm only looking", "the data was public for a moment", or "they should have known better".
If you find a bug by accident
Stop, document what you saw, do not poke further, and contact the vendor through their security or disclosure address. Do not download, do not share, do not test the limits. That restraint is what separates a researcher from a defendant.
Responsible disclosure
When you discover a vulnerability in someone else's system, the broadly accepted practice is:
- Report it privately to the vendor through their security contact.
- Give them a reasonable window to fix it, 90 days is the modern norm.
- Coordinate a public disclosure date with them, once a fix is out.
- Publish the writeup so others can learn and so the fix lands everywhere.
Bug bounty programs codify this with reward structures. They also usually tell you exactly which systems are in scope and what is out of bounds (denial of service, social engineering of employees, etc.). Read the policy before testing anything.
Laws you should know exist
- CFAA (United States): the Computer Fraud and Abuse Act. Broadly criminalizes unauthorized access to a computer. Famous for being interpreted very expansively.
- Computer Misuse Act (United Kingdom): the UK's analogue.
- GDPR (European Union): focused on personal data. Affects what you collect, where you keep it, and how you respond to breaches.
- Local equivalents: nearly every jurisdiction has its own. If you are doing security work professionally, know the one you live in.
Practice with intent
You don't need real production targets to learn. Use:
- Capture-the-flag sites: PicoCTF, OverTheWire, CryptoHack.
- Intentionally vulnerable apps you run locally: DVWA, Juice Shop, WebGoat.
- Lab platforms: TryHackMe, Hack The Box.
- Public bug bounty programs that explicitly invite testing.
Those environments teach you the same techniques without the legal exposure.
One sentence to remember
"If I'm not certain I'm allowed to do this, I am almost certainly not allowed to do this."