The Law and Ethics of Ethical Hacking

In the previous course you learned to find and understand web vulnerabilities. This course turns those skills into a profession: a structured, documented, legal penetration test. Before touching a single tool, we start where every real engagement starts: with the law, with a contract, and with a promise to behave responsibly.

This first lesson is the most important one of the whole course. A penetration tester and a criminal can use exactly the same commands. What separates them is not the tool, the skill or even the intention. It is permission, written down, signed, and limited to a clear scope.

What "ethical hacking" really means

An ethical hacker, also called a penetration tester or "white hat", is a person who is hired or authorised to attack a system in order to find weaknesses before real attackers do. The goal is not to break things. The goal is to produce knowledge: which weaknesses exist, how serious they are, and how to fix them.

A useful analogy is the locksmith. A locksmith who is called by a homeowner to test the front door is doing a job. The same locksmith picking the same lock at night, without being asked, is committing a burglary. The skill is identical; the legal and moral situation is opposite.

You will often hear about "hats":

• White hat: works with permission, to improve security.
• Black hat: attacks without permission, for profit, damage or curiosity that crosses the line.
• Grey hat: finds weaknesses without permission but without malicious intent. This is still legally risky, because good intentions are not an authorisation.

This vocabulary is a simplification, but it carries a useful lesson: only the white hat position is safe, for you and for the people you protect.

The legal framework in France

In France, attacks on information systems are covered by the Penal Code, in the articles on "atteintes aux systèmes de traitement automatisé de données" (STAD), articles 323-1 to 323-3-1. In plain English, they cover:

• Article 323-1: fraudulently accessing or remaining in all or part of an automated data processing system. Simply getting in without permission can be an offence, even if you change nothing. Aggravating circumstances apply if data is deleted or altered, or if the system's operation is affected.
• Article 323-2: hindering or distorting the operation of such a system (for example by overloading it).
• Article 323-3: fraudulently introducing, extracting, copying, altering or deleting data.
• Article 323-3-1: importing, holding, offering or making available equipment, tools or programs designed or adapted to commit these offences, without legitimate reason. That phrase "legitimate reason" is what protects professional security research and teaching, and it is another reason to keep clear records of why you hold your tools.

The penalties include prison sentences and substantial fines, and they can be higher when the target is a state system or when the offence is committed by an organised group. You can read the official texts on Légifrance. This course is not legal advice: if you plan to work in the field, talk to a lawyer who knows digital law.

Most countries have comparable laws. The United Kingdom has the Computer Misuse Act, the United States has the Computer Fraud and Abuse Act, and European countries implement common directives on attacks against information systems. The details differ, but the principle is universal: access without authorisation is an offence.

What turns an attack into a test

Three ingredients make a penetration test legal. If one is missing, you do not have a test.

1. A contract between the tester (or the company employing them) and the client. It defines the mission, the price, the confidentiality terms and the liability of each party.
2. A written authorisation signed by someone who has the right to authorise tests on those systems. We will write one in lesson 1.3.
3. A scope: the exact list of systems, networks, applications and dates that are covered. Anything not on the list is out of scope.

Notice the phrase "someone who has the right to authorise". A junior manager who says "go ahead, try our website" may not be able to authorise tests on servers hosted by a third party. We will come back to this below.

Third parties and hosted systems

Modern systems rarely belong to one person. A company website may run on a cloud provider, use a payment service, load scripts from external suppliers and send mail through a hosted platform. Your client can authorise tests on what it owns or controls. It generally cannot authorise you to attack the infrastructure of its provider.

Cloud and hosting providers usually publish their own testing rules. Some allow certain tests on your own tenant without prior notice, and forbid others. A professional tester reads those rules before the engagement and writes in the scope which third-party components are excluded, or for which the client has obtained the provider's agreement.

Personal data and confidentiality

During a test you will probably see data that is not yours: customer records, employee names, internal documents. In Europe, this data is protected by the GDPR. As a professional you commit to:

• Minimise: access the least data needed to prove a weakness. Proving that you can read a customer table does not require downloading it.
• Protect: store evidence encrypted, on an encrypted disk, and delete it at the end of the retention period agreed in the contract.
• Stay silent: findings are confidential. You never discuss a client's weaknesses publicly, on social media or with friends.

Cybersecurity authorities provide helpful public resources. In France, the ANSSI publishes guides and a qualification scheme for audit providers (PASSI), and cybermalveillance.gouv.fr helps victims and raises public awareness. Internationally, the OWASP project and the MITRE ATT&CK knowledge base give the community a shared language.

A code of conduct you can adopt today

Professional bodies have codes of ethics, but you can start with five simple rules and apply them from this very course:

1. No authorisation, no test.
2. Stay inside the scope, even when something tempting appears just outside it.
3. Do no harm: avoid actions that could crash a system or destroy data unless the contract explicitly allows them.
4. Protect everything you learn.
5. Report honestly, including your own mistakes.

Your fil rouge: Project Lighthouse

Throughout this course you will run a complete penetration test of a small fictional company called Lighthouse Labs. The company does not exist. Its "network" is made of virtual machines in your own lab: a Kali Linux machine that you will attack from, and one or more deliberately vulnerable machines (from a training platform or downloaded as a lab image) that play the role of the client's servers. Because you own all of it, you are your own client, and you will still write the paperwork as if it were real. That habit is what makes a professional.

Your turn: legal or not?

For each situation, decide whether the action is covered by a valid authorisation, and why. Write your answers in a notebook.

1. A friend runs a small online shop and says: "Feel free to see if you can break in." You have nothing in writing.
2. You scan a virtual machine you installed yourself in VirtualBox on your laptop.
3. You find a login page on a company website and try a few common passwords "just to see".
4. You are hired by a company with a signed contract and scope, and you notice an unlisted server on the same network that looks vulnerable.
5. You attack a machine on a platform such as TryHackMe, inside the rules of that platform.

See a solution

1. Not safe. A verbal "feel free" is not a written authorisation, does not define a scope, and the shop's hosting provider has not agreed. Ask for a written note, and check the hosting rules.
2. Legal. You own the system. Keep the lab network isolated from the internet so that nothing leaks out.
3. Illegal. Trying passwords on a system you have no permission to test is an attempt at fraudulent access, even if you never "get in" and even if you are curious rather than malicious.
4. Out of scope. Stay away from it, and report it to your contact so that the scope can be formally extended if the client wishes.
5. Legal within the rules. These platforms are built for training and invite you to attack their machines, but you must follow their terms and never attack other users or the platform infrastructure.

In the next lesson, you will see how the amount of information given to the tester changes the nature of a test: black, grey and white box.