"Hacker" first meant someone who loved taking systems apart to see how they work. Today the word covers people who protect systems, people who attack them and many in between. The security world sorts them with a simple idea borrowed from old westerns, where the hero wore a white hat and the villain a black one.
What separates them is permission and intent, more than skill. The same technique can be a paid security test or a crime, depending on whether the owner agreed to it.
White hat hackers
White hats, also called ethical hackers, test systems with the owner's written permission. They agree on a scope first: which sites, apps or networks they may test, which methods are allowed and when. They report everything they find to the owner and help fix it. Penetration testers, security auditors and most bug bounty researchers work this way.
Black hat hackers
Black hats break in without permission, for money, data, disruption or a cause. They run ransomware, steal card details and passwords, sell access to company networks and rent out the networks of hijacked devices used in DDoS attacks. Most of their attacks are automated and aimed at whatever is easiest to break, which is why small businesses get hit as often as large ones.
Grey hat hackers
Grey hats test systems without permission, usually without meaning harm. A typical case: someone probes a website, finds a flaw and then tells the owner, sometimes asking for a reward.
The intent may be good, but unauthorised access is a crime in most countries. In the EU, Directive 2013/40/EU requires every member state to make illegal access to information systems a criminal offence. A friendly report afterwards does not undo the access, and an unexpected demand for payment can look a lot like extortion. If you want to test, find a programme that invites you.
You will also see other colours online, such as green hats for beginners and red hats for vigilantes. These labels are informal and used inconsistently, so they are best left out of anything serious.
Red, blue and purple teams
Inside companies, the colours describe roles rather than ethics. Everyone involved is authorised.
- The red team plays the attacker. It runs agreed, realistic exercises, from phishing staff to breaking into a test network, to show how a real attack would unfold.
- The blue team defends. It watches logs and alerts, hardens systems, and responds when something happens, whether the attack is real or an exercise.
- Purple teaming joins the two. The red team explains each step while the blue team checks whether it was spotted, and both improve together.
Bug bounty programmes
A bug bounty programme invites outside researchers to look for security flaws and rewards valid reports, usually with money. The rules set out what is in scope, what is off limits (often denial of service, social engineering and physical access), how to report and how rewards are decided.
- Public programmes are open to anyone who accepts the rules.
- Private programmes invite or approve researchers one by one.
Many companies run their programmes through platforms such as HackerOne, Bugcrowd, Intigriti or YesWeHack, which handle reports and payments. Others run their own.
Internetivo runs a private, approval-gated bug bounty. Researchers apply first and test only within the scope we grant them in writing. Its rules are at internetivo.com/security.
Responsible disclosure
Responsible disclosure, now usually called coordinated vulnerability disclosure, is the etiquette for reporting a flaw. The finder tells the owner privately, gives them reasonable time to fix it, and only then publishes the details. Deadlines vary. Google's Project Zero, for example, gives vendors 90 days by default.
If you stumble on a flaw by accident, even without any programme:
- Stop. Do not look further, download data or try to confirm it by testing more.
- Write down what you saw, when, and how you came across it.
- Report it privately through the organisation's security contact or disclosure page.
- Do not share it publicly or with others until it has been fixed.
For site owners: make reporting easy
Researchers can only report to you if they can find you. Publish a short disclosure policy and a security.txt file, the standard described in RFC 9116. It lives at /.well-known/security.txt on your domain. Contact and Expires are required; the rest is optional:
Contact: mailto:[email protected]
Expires: 2027-10-31T00:00:00.000Z
Policy: https://example.com/security#disclosure
Preferred-Languages: en, el
Canonical: https://example.com/.well-known/security.txt
Then answer reports quickly, thank the reporter and keep them updated. For developers, our security checklist for web developers covers the flaws researchers find most often.
Common questions
- Is ethical hacking legal?
- Yes, when the owner has given clear permission and you stay inside the agreed scope. Without permission, the same tests can be a criminal offence.
- Can I test a site to see if it is secure?
- Only your own, or one whose owner invites testing through a published programme. Read the rules first and follow them exactly.
- Do bug bounty hunters get paid for every report?
- No. Most programmes pay only for valid, in-scope findings that nobody reported earlier. Duplicates and out-of-scope issues usually earn nothing.
- How do I start a career as a white hat?
- Learn networking and web basics, practise on legal training labs, and work on public programmes that welcome newcomers. Many testers also earn certifications along the way.
Security is part of every good project. Your first project on Internetivo shows how to describe the work you need and approve the result.