What is ethical hacking?

Overview

Ethical hacking means looking for security weaknesses with explicit permission, so they can be fixed before a real attacker finds them. The word that separates an ethical hacker from a criminal is not a tool or a technique — it is authorization.

You do not need any prerequisites for this lesson; it is the front door to the whole security track. What you learn here — authorization, scope, and lab-only practice — is the rule every later lesson depends on. The next lesson, Rules of engagement, turns "get permission" into a concrete document.

In plain terms: the same command that is professional security work on a system you are paid to test is a computer-crime on a system you are not. The system cannot tell the difference — only the paperwork can.

Why it matters

Running a scanner or an exploit against a system you do not own or have written permission to test is unauthorized access, which is a criminal offence in most countries (for example the UK Computer Misuse Act, the US Computer Fraud and Abuse Act, and the EU Convention on Cybercrime). People have been prosecuted for "just looking."

Getting this right is also what makes you employable: real engagements — penetration tests, bug-bounty programs, internal red teams — all begin with a signed scope and end with a report a defender can act on. The skill that pays is not breaking in; it is finding, explaining, and helping fix weaknesses responsibly.

Core concepts

1. Authorization is the whole game

Definition. Authorization is written, specific permission from the owner of a system to test it in defined ways, during a defined time.

Without it, the activity is illegal regardless of intent. "I was only going to report it" is not a defence. Authorization must exist before the first packet.

Pitfall: verbal "sure, go ahead" is not authorization. Get it in writing, signed, with a date and a scope.

2. What you are protecting: the CIA triad

Every security decision serves one of three goals:

A finding matters because it threatens one or more of these. Naming which one sharpens your report.

3. Threat vs vulnerability vs risk

These three words are often muddled. They are different:

• Vulnerability — a weakness (e.g. input that is never validated).
• Threat — an actor or event that could exploit it (e.g. an untrusted user).
• Risk — the combination: likelihood × impact. High risk needs a threat, a vulnerability, and something worth protecting.

A vulnerability with no realistic threat, or no valuable asset behind it, is low risk. This is why we never label every finding "critical."

4. Where the lines are: a simple trust model

   Untrusted input / user
            |
            v   <-- trust boundary: validate + authorize HERE
   Your application logic
            |
            v   <-- trust boundary: least privilege HERE
   Data store / OS / network

A trust boundary is any point where data crosses from a less-trusted zone to a more-trusted one. Most vulnerabilities live at a boundary where the code trusted something it should have checked.

Knowledge check:

1. In your own words, what single thing turns "security testing" into "a crime"?
2. A page leaks other users' order history. Which part of the CIA triad failed?
3. You find unvalidated input, but the field is only reachable by a fully-authenticated admin on an internal tool. Is that automatically "critical"? Why or why not?

Syntax notes

This course has no "attack syntax" to memorize. The one thing to internalize is the authorization checklist you run before every lab or engagement:

Before testing:
[ ] I own the system, or I have written, signed permission to test it
[ ] The target(s) are clearly and specifically defined (scope)
[ ] The allowed testing methods are defined
[ ] The testing time window is approved
[ ] Data-handling rules are understood (what I may see, keep, and must delete)
[ ] Emergency contact + stop procedure are known
[ ] Destructive testing is prohibited unless explicitly approved in writing

If any box is unchecked, you do not proceed.

Lesson

What ethical hacking is

Ethical hacking is testing systems you are explicitly authorised to test, in order to find weaknesses before adversaries do.

It is always bounded by written authorisation that describes the scope and the rules.

Why authorisation matters

Running the same tools without that authorisation is unauthorised access. In most jurisdictions this is illegal, for example:

• The UK Computer Misuse Act.
• The US Computer Fraud and Abuse Act (CFAA).
• The EU Cybercrime Convention.

What this course teaches

This course teaches patterns and defensive engineering. You will write code that detects attacks against your own test fixtures. You will never write code that attacks other people's systems.

Code examples

A concrete, lab-safe way to make "local-only" real: run your practice target in a container that has no network at all, then prove it cannot reach the outside world.

# Start a throwaway lab container with networking fully disabled.
# --network none removes every interface except loopback.
docker run --rm -it --network none debian:stable-slim bash

# Inside the container, confirm it is isolated (this should FAIL):
#   getent hosts example.com   -> no result
#   (there is no route off the box, so nothing can be attacked by accident)

What it does. --network none gives the container only a loopback interface, so code you run inside literally has no path to any other machine. --rm deletes the container on exit so there is nothing to clean up. This is the safety property the whole course relies on: even a mistake stays inside a box you own.

Expected result. Any attempt to resolve or reach an external host fails, because there is no network. That "failure" is the point.

Line by line

Walking through the authorization checklist the way you would on a real engagement:

Notice the flow is paperwork first, tools last. Every box is about staying inside the authorized boundary.

Common mistakes

Mistake 1 — "It's fine, I'll just report it." Wrong: scanning a live third-party site because you spotted something. Why wrong: unauthorized access is the offence; your good intentions do not change the law. Fix: if you find something on a system you were not authorized to test, stop and use the vendor's responsible-disclosure channel — do not probe further.

Mistake 2 — treating a verbal OK as authorization. Wrong: a colleague says "yeah, test the staging box." Why wrong: no scope, no signature, no record — and they may not own it. Fix: get written scope + sign-off from someone who can actually grant it.

Mistake 3 — labeling everything "critical." Wrong: every finding rated the same, top severity. Why wrong: it destroys trust and buries the findings that truly matter. Fix: rate by realistic risk (likelihood × impact), which you'll learn in the reporting lessons.

How to recognize the trap: if you cannot point to the signed document that authorizes exactly what you are about to do, you are about to make a mistake.

Debugging tips

"Debugging" an ethics question means resolving ambiguity before acting:

• Unsure if something is in scope? Treat it as out of scope until confirmed in writing. Ask; don't assume.
• Found something outside the agreed targets? Stop, document what you already saw (minimally), and report it through the agreed channel.
• A test might affect availability? Confirm it is explicitly allowed; otherwise skip it.
• Not sure you can keep some data you saw? Default to not keeping it; follow the data-handling rules.

Questions to ask yourself when unsure: Who owns this? Do I have that in writing? Is this specific action listed as allowed? What is the worst thing that could happen, and is it reversible?

Memory safety

Security & safety — handling what you find. Ethical practice continues after you find a weakness:

• Collect the minimum evidence needed to prove a finding — a screenshot or a request/response, not a full data dump.
• Never exfiltrate, keep, or expose real user data. If a proof-of-concept would expose personal data, describe it instead of extracting it.
• Log what you did (timestamps, targets, actions) so your work is auditable — but never log secrets, passwords, tokens, or the sensitive data itself.
• Store notes and reports securely; delete engagement data per the agreed rules when the work ends.

The defensive mindset: your job is to reduce risk for the owner, not to accumulate their secrets.

Real-world uses

Ethical hacking, done under authorization, shows up as:

• Penetration tests — a scoped, time-boxed assessment of an app, network, or product.
• Bug-bounty programs — a company publishes rules and pays for responsibly-disclosed findings within those rules.
• Internal red teams — staff who test their own organization with standing authorization.
• Secure code review — reading code (like the labs here) to find weaknesses before they ship.

Professional habits (start here): always work from written scope; keep detailed, honest notes; report clearly and reproducibly; prefer prevention and detection over flashy exploitation. Advanced habits: threat-model before testing; deconflict with the blue team; measure findings by business risk, not novelty.

Practice tasks

Beginner 1 — Spot the boundary. Objective: given three short scenarios (a friend's website, your own laptop VM, a company you were hired to test with a signed contract), label each authorized or not, and name the one fact that decides it. Concepts: authorization, scope.

Beginner 2 — Build your checklist. Objective: write out the 7-line authorization checklist from memory and add one sentence explaining why each line protects you. Constraints: no tools involved. Concepts: authorization, data handling.

Intermediate 1 — Classify by CIA. Objective: for five one-line findings (e.g. "user emails exposed", "attacker can change an order total", "service crashes on a long input"), tag each with the CIA goal it breaks and a rough risk (low/medium/high) with a one-line justification. Concepts: CIA triad, risk.

Intermediate 2 — Isolate a lab. Objective: start a container with --network none, then demonstrate (in writing, with the commands and their output described) that it cannot reach any external host. Concepts: lab isolation, verification. Hint: try to resolve/reach a host and show that it fails.

Challenge — Draft a mini scope. Objective: for a fictional "toy web app on localhost:8080", write a one-page authorization note: in-scope targets, out-of-scope items, allowed methods, time window, data rules, and a stop procedure. Requirements: it must be specific enough that a reader knows exactly what is and isn't allowed. Do not test anything real. Concepts: everything in this lesson; sets up the next lesson on rules of engagement.

Summary

• Authorization — written, specific, signed, before you start — is what makes hacking ethical and legal.
• Every finding protects confidentiality, integrity, or availability; naming which sharpens your work.
• Risk = likelihood × impact; a vulnerability with no realistic threat or valuable asset is not automatically critical.
• Run the 7-point authorization checklist every time; if any box is unchecked, stop.
• All practice here is local-only (e.g. docker run --network none), so a mistake can never reach someone else's systems.
• Handle findings defensively: minimal evidence, no real user data kept, auditable logs without secrets.

Next: Rules of engagement — how to turn "get permission" into a concrete, signed document.

Practice with these exercises

• Are you authorized to test?
• Is the action ethical?
• Validate a password against a policy
• HTML-escape user-provided text
• Prevent CSV injection by prefixing risky cells