Rules of Engagement: Law, Ethics, and Authorization

CAP, ACID vs BASE, latency numbers, back-of-envelope estimation, single points of failure — the vocabulary every system designer thinks in.

Core Philosophy: Security is the one technical field where doing the exercise on the wrong target is not a bug — it is a crime. The exact same action — scanning a server, testing a login, exploiting a flaw — is either professional work or a criminal offense, and the only thing that decides which is authorization. This page is not a disclaimer. It is a core skill. Read it before you attack anything, ever.

Part 1: The Problem

Everything you learn after this page is, mechanically, an attack technique. The skills are genuinely dual-use: the person securing a company and the person breaking into it run the same tools and type the same commands.

What separates them is not skill. It is permission. A penetration tester scanning a client’s network and a criminal scanning the same network are doing something physically identical — and one has a contract while the other has a prison sentence waiting.

New learners get into trouble not because they’re malicious, but because they’re curious: “I’ll just run a quick scan on this site to practice.” That sentence has ended careers before they started. This page makes the rules concrete so curiosity never becomes a crime.

Part 2: The Core Concept — Authorization Is Binary

There is no grey area, no “a little bit allowed.” For any system, at any moment, you are in exactly one of two states:

   ┌────────────────────────┐   ┌────────────────────────┐
   │  AUTHORIZED             │   │  NOT AUTHORIZED         │
   │  You have explicit      │   │  You don't.             │
   │  permission to test     │   │                         │
   │  this system, in this   │   │  Any testing here is    │
   │  way, right now.        │   │  a criminal offense.    │
   │                         │   │                         │
   │  → Professional work    │   │  → A crime              │
   └────────────────────────┘   └────────────────────────┘

You are authorized only when one of these is true:

• You own the system (your own machine, your own VM lab).
• You have explicit written permission from the owner to test it.
• You are operating inside the published scope of a bug bounty program.
• You are using a training platform on the targets it provides for that purpose.

If none of those applies, you are not authorized. “It looked insecure,” “I didn’t break anything,” “I was only curious,” “the data was public anyway” — none of these is a defense. They will not help you.

Part 3: What the Law Actually Says

Nearly every country has a computer-misuse law, and they share a common core. The exact statute varies — in the US it’s the Computer Fraud and Abuse Act; the UK has the Computer Misuse Act; India has the Information Technology Act; the EU has its directive on attacks against information systems — but the principle is the same everywhere:

Accessing a computer system without authorization, or beyond the authorization you were given, is a criminal offense.

Three things follow that beginners routinely get wrong:

• No damage is still a crime. Unauthorized access is the offense. You don’t have to steal, break, or change anything. Merely getting in — or sometimes merely trying — is enough.
• “Exceeding authorization” counts. If you’re allowed to test System A and you wander onto System B, that’s an offense — even though you had some permission. Authorization is specific, not general.
• Intent doesn’t rescue you. “I meant to help” or “I was going to report it” does not make unauthorized access legal. Good intentions are not consent.

⚖️ This curriculum gives you a general, practical understanding — not legal advice. Laws differ by country and change over time. If you ever plan professional security work, understand the specific laws of your jurisdiction and your client’s.

Part 4: Scope — The Contract That Defines “Allowed”

When testing is authorized, the permission is never unlimited. It is bounded by a scope: an explicit definition of what you may test and how.

A scope typically specifies:

• In-scope targets — the exact domains, IP ranges, or applications you may test.
• Out-of-scope targets — things explicitly forbidden, even if related to the same company.
• Allowed techniques — and forbidden ones (e.g. denial-of-service is almost always banned; social-engineering staff is often banned).
• Timing and limits — when you may test, and how aggressively.

        THE COMPANY
   ┌───────────────────────────┐
   │  ┌─────────────────────┐  │
   │  │  IN SCOPE           │  │ ← test ONLY here
   │  │  app.example.com    │  │
   │  │  api.example.com    │  │
   │  └─────────────────────┘  │
   │   mail.example.com        │ ← OUT of scope:
   │   blog.example.com        │   off-limits, even
   │   corp laptops            │   though same company
   └───────────────────────────┘

Scope is a contract. Stepping outside it is unauthorized access — even on the same company, even if you found something interesting. The professional discipline is: find something juicy out of scope, do not touch it, and report that it exists through the proper channel.

Part 5: Responsible Disclosure

Suppose you legitimately find a real vulnerability — in an authorized test, or in a bug bounty program. What you do next is itself an ethical skill called responsible disclosure (or coordinated disclosure).

The principle: give the people who can fix it a fair chance to fix it before the world — including attackers — learns the details.

The normal flow:

1. Report privately to the organization (via their bug bounty platform, a security.txt contact, or a security email).
2. Provide enough detail to reproduce and understand it — clear steps, impact.
3. Give them reasonable time to fix it before any public discussion.
4. Do not exploit it further. Prove it exists; don’t pillage. Don’t read more data than needed to demonstrate the bug. Don’t pivot deeper.
5. Coordinate any public write-up with the organization.

What responsible disclosure is not: it is not posting the exploit publicly for clout, not extorting the company (“pay me or I’ll release this” is a crime — that’s extortion), and not quietly using the bug yourself.

This is also how bug bounty income works: companies pay precisely because you found it, proved it carefully, and disclosed it responsibly instead of abusing it.

Part 6: Where It’s Always Safe to Practice

Set against all those rules, here is the reassuring part — there is an enormous amount of legal practice space. You never need an illegal target.

Every hands-on lab in this entire curriculum is built around these. The rule is simple and freeing: if you ever can’t clearly answer “what specifically authorizes me to attack this?”, the answer is to stop and use a target from this table instead.

📓 Key Terms

🧪 Hands-On Lab

This page’s “lab” is reflection and reading — the most important kind here.

Task 1 — Read a real bug bounty scope. Find any public bug bounty program (the major platforms list them openly). Read its program page. Identify: the in-scope targets, the out-of-scope targets, and the forbidden techniques. Notice how specific it is. This is what authorization looks like in writing.

Task 2 — Find a security.txt. Many organizations publish a security.txt file (often at /.well-known/security.txt) telling researchers how to report issues. Find one on a large company’s site. This is the front door for responsible disclosure.

Task 3 — Look up your own country’s computer-misuse law. Search for the main computer-misuse statute where you live. Read a plain-language summary. You don’t need legal mastery — you need to know the law exists and roughly what it forbids.

Task 4 — Write your personal rule. In your Notion, write one sentence you commit to, e.g.: “I attack only my own lab, sanctioned training platforms, and in-scope bug bounty targets — nothing else, ever.” Pin it. It’s the most valuable note in your whole vault.

Task 5 — Run the decision drill. For each, decide authorized or not, and why:

• Scanning your own Kali-and-victim lab. → Authorized — you own it.
• “Quickly testing” a login form on a random site you found. → Not authorized — a crime.
• Testing app.example.com when the program lists only api.example.com. → Not authorized — out of scope.
• Attacking a deliberately vulnerable VM you downloaded. → Authorized — built for it.
• Finding a bug, then reading other users’ data “to see how bad it is.” → Not authorized — exceeds scope; stop and report.

⚠️ Common Mistakes

• “Just a quick scan.” A scan is access. Against a system you’re not authorized to test, it is an offense. There is no harmless unauthorized scan.
• Assuming a bug bounty allows everything. It authorizes in-scope targets with allowed techniques only. Out of scope = unauthorized.
• Over-exploiting to “show impact.” Once you’ve proven a bug exists, stop. Reading extra data or going deeper turns a clean finding into a crime.
• Practicing on a friend’s or employer’s systems without written permission. Verbal “sure, go ahead” is not protection. Get it in writing, with a defined scope.
• Treating this page as a formality. Every other page assumes you’ve internalized this one. It is the foundation the rest of your career sits on.

✅ Recap & What’s Next

• Security skills are dual-use; authorization — and nothing else — separates professional work from a crime.
• Authorization is binary and specific: no damage is still a crime, and exceeding the permission you were given is also a crime. Scope is the contract that defines what’s allowed.
• There is abundant legal practice space — your lab, vulnerable apps, training platforms, CTFs, in-scope bounties — so you never need an illegal target.

Next (1.1): With the rules locked in, we define the thing itself — what “secure” actually means, and why perfect security is neither possible nor the goal.