Chapter 1 · Foundations· Beginner· ~10 min

Ethics & Law

The same techniques can defend a company or destroy a life. Where the line sits, and how to stay on the safe side of it.

You will learn

  • The difference between curiosity, research, and a crime
  • What "authorization" really means in security work
  • What responsible disclosure looks like in practice
  • A few legal touch-points (CFAA, GDPR) you should be aware of

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:

  1. Report it privately to the vendor through their security contact.
  2. Give them a reasonable window to fix it, 90 days is the modern norm.
  3. Coordinate a public disclosure date with them, once a fix is out.
  4. 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."

Take the quiz