The golden rule: only touch what you're allowed to

If you forget everything else in Path 01, remember this. Everything you'll learn is genuinely powerful, and power pointed at the wrong target causes real harm and real legal trouble. Read this slowly, twice.

The rule

Never test, scan, or hack any system unless you own it, or you have clear, explicit permission.

That's the whole thing. It sounds simple — and it is — but people get into trouble by inventing exceptions. There are none.

The excuses that will not save you in court:

• "I only looked" — still unauthorised access.
• "I was just curious" — not a defence in any court.
• "I didn't change anything" — doesn't matter.
• "I wasn't going to abuse it" — irrelevant.
• "The site was insecure — they were asking for it" — laughable, and illegal.

In most countries, simply accessing a computer system without permission is a crime, even if you cause no damage at all.

Why the law is this strict

Imagine someone walking down your street at night, quietly trying every front-door handle to see which are unlocked. Even if they never step inside, you'd feel violated, and the police would take it seriously. Networks work the same way. "Just checking whether the door is open" on a computer you don't own is treated as an attempt to break in — because the owner can't read your mind to know your intentions were harmless.

The laws worth knowing

Different countries have different laws, but nearly every developed country has one that criminalises unauthorised computer access:

You don't need to memorise these. Just know that the laws exist everywhere, and they are strict.

Teenagers who "just wanted to learn" have been arrested, charged, and — in some cases — jailed. A criminal record follows you for life and, ironically, shuts you out of the very security career you were trying to build. It is never worth it.

The good news: endless legal ground to practise on

You will never need to touch a system you don't own, because the community has built an enormous amount of legal, safe, and often free places designed specifically for practice.

[Where you're allowed to hack]

1. Your own lab

In Path 03 you'll build a safe practice computer inside your own machine (a "virtual machine"). You own it, so attack it all you like. This is the professional's setup.

2. Training platforms

• TryHackMe — guided, beginner-friendly, browser-based labs. Excellent free tier.
• Hack The Box — more advanced, with an "Academy" for structured learning and a "Labs" area for CTF-style machines.
• PortSwigger Web Security Academy — the gold standard for web hacking, entirely free. You'll live here in Path 11.
• OverTheWire — classic Linux and networking wargames.

3. Official practice targets

Some tool authors deliberately provide targets:

• scanme.nmap.org — the Nmap team runs this specifically so you can practise scanning.
• testphp.vulnweb.com — Acunetix's deliberately vulnerable web app.
• http://testfire.net — IBM's altoro mutual test site.

4. Bug bounty programs

Real companies publicly invite hackers to test their sites — and even pay rewards. But you must stay strictly inside the scope (the published list of what you're allowed to touch) and the rules. Path 15 covers this in depth.

What "permission" actually looks like in professional work

Once you move from practice platforms into real, paid engagements (covered in depth in Path 14), permission isn't a casual verbal agreement — it's a formal document called Rules of Engagement (RoE), signed by both the tester and the client, spelling out exactly: which systems are in scope, which testing techniques are and aren't allowed (some clients exclude denial-of-service style tests, for instance), the exact time window testing is authorized for, and emergency contact information if something unexpected happens mid-test. This document is often informally called a "get out of jail free card" — it's the tester's actual legal proof of authorization if anything is ever questioned, and no professional engagement should ever begin without one, fully signed, in hand.

Even from someone who genuinely owns the system and genuinely means it, spoken permission ("yeah sure, go ahead and test it") offers you essentially no protection if a dispute arises later — memories differ, and there's no proof. Always get authorization in writing, even for a favor for a friend, and even more so for any professional work.

A simple test before you ever act

Before running any tool at anything, ask yourself one question:

"Do I own this, or has someone clearly given me permission to test it?"

If the answer isn't a confident yes, stop. Don't touch it. When in doubt, practise on your lab or a training platform. This one habit will protect you for your entire career.

Responsible disclosure — what to do if you spot a flaw accidentally

Occasionally you'll stumble across a genuine flaw in the ordinary course of using a website — not while intentionally testing it. Responsible disclosure (sometimes called coordinated disclosure) is the accepted, ethical process for handling this: privately notify the organization (via a security.txt file, a bug bounty program, or a direct security contact) with enough detail for them to understand and reproduce the issue, give them a reasonable amount of time to actually fix it (commonly 90 days is treated as an industry-standard norm) before any public discussion, and never demand payment as a condition of reporting — that crosses from disclosure into something closer to extortion, a serious legal distinction. This process protects both you (documented good-faith conduct) and the organization's users (the flaw gets fixed before attackers learn about it).

Special cases that people get wrong

Beginners get tripped up by these — here are the answers:

• "But it's my old school's website." No. Not yours.
• "But my friend said I could test his server." Get it in writing. Verbal permission evaporates when things go wrong.
• "But this company doesn't seem to have a bug bounty." No bounty = no permission. Don't test.
• "But I found a login page publicly accessible." Public accessibility isn't permission. Don't try passwords.
• "But the flaw is so obvious!" Doesn't matter. Don't confirm it. Report suspicion to the company via their security contact (if any) and move on.

You find a website with an obvious-looking flaw. You're sure you could confirm it in seconds and you'd never cause harm. It's not yours and you have no permission. What do you do?

Key terms

• Authorisation / permission — explicit approval to test a system.
• Scope — the exact list of assets a program allows you to test.
• Unauthorised access — touching a system without permission; a crime in most places.
• security.txt — a standard file (/.well-known/security.txt) where sites publish how to report security issues responsibly.

Recap

• Only ever test what you own or have explicit permission to test. No exceptions.
• Unauthorised access is a crime in most countries, even with no damage or bad intent.
• There's endless legal ground: your lab, TryHackMe, Hack The Box, PortSwigger, scanme.nmap.org, in-scope bug bounties.
• Before acting, always ask: "Do I own this or have clear permission?" If not, stop.

References

• CFAA — Wikipedia — the main US computer crime law.
• Computer Misuse Act 1990 — UK gov — the UK equivalent.
• security.txt spec (RFC 9116) — how to find a site's security contact.
• Disclose.io — a directory of companies with responsible-disclosure policies.
• scanme.nmap.org — Nmap's own note about their legal practice target.

Next up → Cybersecurity laws & ethics, beyond the golden rule