What Is Ethical Hacking and Why Does It Matter in 2026?

THE ONE RULE THAT MAKES HACKING ETHICAL

Authorised  = written permission from the system owner
            + agreed scope (which systems, which tests)
            + agreed time window
            + agreed way to report findings

Without all of these, accessing or testing someone
else's system can be a criminal offence, even if you
"only looked" or "meant well".

In India, unauthorised access and related acts are
addressed under the Information Technology Act, 2000.
Other countries have similar computer misuse laws.

If in doubt: do not test. Ask, and get it in writing.

WHITE HAT
  Works with permission to improve security.
  Example: an authorised penetration tester.

BLACK HAT
  Breaks in without permission for gain or damage.
  This is criminal activity.

GREY HAT
  Tests without permission but may report issues.
  Still unauthorised, and still legally risky.
  Good intentions do not make it legal.

Career advice: the only path that leads to a stable
security job is white hat — authorised work only.

RULES OF ENGAGEMENT — SUMMARY (example structure)

Client contact     : name, phone (24x7 during test)
Tester contact     : name, phone
In scope           : app.example-client.test
                     10.10.20.0/24 (staging only)
Out of scope       : production database, payment gateway,
                     third-party services, staff phishing
Window             : agreed dates, 10:00-18:00 IST
Allowed            : scanning, authenticated web testing
Not allowed        : denial of service, data deletion,
                     accessing real customer data
Stop condition     : any sign of instability -> pause, call
Data handling      : evidence encrypted, deleted after report
Signed by          : client authority + testing lead

# Practise ONLY on machines you own, in an isolated lab.
# Example: a deliberately vulnerable VM on a host-only
# network at 192.168.56.0/24 inside VirtualBox.

# Which hosts are up on MY lab network?
nmap -sn 192.168.56.0/24

# Which common ports and service versions on MY lab VM?
nmap -sV --top-ports 100 192.168.56.101

# Save results for your practice report
nmap -sV -oN lab-scan.txt 192.168.56.101

# Never point scanners at public IPs or websites you do
# not own or have written permission to test.

# Defensive example: avoid SQL injection in Python
import sqlite3

conn = sqlite3.connect("shop.db")

def find_user(email: str):
    # UNSAFE pattern (do not do this):
    #   conn.execute(f"SELECT * FROM users WHERE email = '{email}'")
    # User input becomes part of the SQL text.

    # SAFE: parameterised query, input is passed as data
    cur = conn.execute(
        "SELECT id, name FROM users WHERE email = ?", (email,))
    return cur.fetchone()

# The same idea applies in every language and database
# driver: never build SQL by joining strings with input.

# Defensive example: common HTTP security headers (nginx)
server {
    listen 443 ssl;
    server_name app.example.test;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-Frame-Options "DENY" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;
    add_header Content-Security-Policy "default-src 'self'" always;

    server_tokens off;   # hide nginx version in responses
}

# Check your own site's headers:
#   curl -sI https://app.example.test

BEFORE ANY TEST — AUTHORISATION CHECKLIST

[ ] I own the system, OR
[ ] I have WRITTEN permission from someone with authority
[ ] Scope lists exact hosts, URLs or IP ranges
[ ] Out-of-scope systems are listed
[ ] Testing dates and hours are agreed
[ ] Allowed and forbidden activities are clear
[ ] Emergency contact is available during testing
[ ] I know how to store and delete evidence securely
[ ] For bug bounties: I have read the programme rules

Any box unticked?  ->  Do not start.

FINDING WRITE-UP (practice format)

Title        : Missing security headers on login page
Affected     : https://lab-app.local/login (my lab)
Risk rating  : Low / Medium / High / Critical
Description  : Plain-English explanation of the weakness
Impact       : What could happen if it were abused
Evidence     : Screenshot or command output (no real
               personal data)
Steps to verify (safe, non-destructive):
  1. ...
  2. ...
Recommendation: Exact fix, e.g. add CSP and HSTS headers
References   : OWASP guidance link
Retest result: Fixed / Not fixed (date)

HOME LAB PLAN (all on your own laptop)

1. Install VirtualBox or VMware Workstation Player
2. Create a HOST-ONLY network (no internet exposure)
3. Attacker VM : Kali Linux or Parrot OS
4. Target VMs  : deliberately vulnerable apps such as
                 OWASP Juice Shop or Metasploitable
                 (run them only on the host-only network)
5. Snapshot every VM before practising -> easy reset
6. Keep a lab notebook: date, goal, what you tried,
   what you learned, how it would be fixed
7. Write one finding report per week using the
   template above

Needed: at least 16 GB RAM recommended for several VMs