How to Become a White-Hat Hacker [The Complete 2026 Roadmap]: Official-Faithful Certifications, Learning Order, and How to Build a Legal Practice Environment

Let me state the conclusion first. What separates a white-hat hacker from a black-hat hacker is not technical skill. It's "permission." With the same port scan, the same SQL-injection attempt, if the target is "your own asset" or "a target for which you obtained explicit written permission," it's legitimate security work, and otherwise it's a crime.

So this article changes the order from the "first install Kali Linux"-style roadmaps flooding the world. What you learn first is not attack techniques but the boundary line of law and ethics. Once that single line is in your body, you can immerse yourself in the technique with peace of mind.

"I want to become a white-hat hacker but don't know what to tackle first," "Do I need certifications, is self-study possible, how long does it take," "I'm anxious about whether it's illegal in the first place" — this article answers all of these end-to-end, from self-study to practice and projects, in a form faithful to each official document (EC-Council / OffSec / CompTIA / (ISC)² / IPA / OWASP / the National Police Agency). All the practice along the way is shown in legal real code you can copy and run.

The intended readers of this article: inexperienced-to-junior engineers about to learn security, those aiming to become white-hat hackers through self-study, and developers/managers who want to judge "should I hire a white-hat-type person for my own app / should I learn it myself."

0. ⚠️ Most important: what guarantees "white" is not technique but "permission"

Before technique, always grasp Japanese law first. Skip this and well-meaning learning becomes a crime in one shot.

0-1. The Unauthorized Computer Access Act — what is prohibited

The Act on the Prohibition of Unauthorized Computer Access (Act No. 128 of 1999) defines the "outer perimeter of the map" of a white-hat hacker. Based on the National Police Agency's explanation, roughly the following are prohibited.

The latest point as of 2026: with the Penal Code revision enforced in June 2025, the conventional "imprisonment with/without labor" was unified into 'imprisonment' (拘禁刑). Old articles write "up to 3 years' imprisonment with labor," but the current text is "imprisonment." Always check the latest version of the text on e-Gov Law Search.

The point is that "breaking / circumventing access control" itself is a crime, regardless of whether there's harm. "I didn't look at the data," "I thought it was harmless" hardly holds in Japan. Don't do more than peek at a login screen on an unauthorized target — this is the absolute rule.

0-2. The law on the side that makes tools — the Penal Code's virus offense

What's involved when you write attack tools or scripts is the Penal Code's offense related to unauthorized commands on electromagnetic records (Penal Code Articles 168-2 and 168-3, the so-called "virus offense"). The acts of creating, providing, acquiring, or storing malware "without a legitimate reason" become punishable.

White-hat hackers write assessment tools and PoCs (proof-of-concept code). This is legal because there's a context of "a legitimate reason" = permitted assessment, research, or education. Conversely, the moment that context is lost, the same code becomes illegal. Remember that the line is drawn not by "what you wrote" but by "why and where you use it."

0-3. The "three safe zones" you may freely practice in

So, where can you freely get hands-on? In principle, practice is permitted only in these 3.

1. Assets you manage — your own PC, a VPS you rented, an app you made. This article's hands-on is all done here.
2. Intentionally-vulnerable learning environments / CTFs — targets explicitly marked "you may attack," like OWASP Juice Shop, DVWA, picoCTF, Hack The Box, TryHackMe.
3. Targets of a formal bug bounty / vulnerability disclosure program (VDP) — a permitted scope a company has published as "you may investigate within this range" (detailed in Chapter 6).

As long as you don't go outside these 3 "fences," your activity is completely legal. Step even one foot outside the fence and it's a crime. Thoroughly enforcing this boundary line is the only condition that, more than technique, makes a white-hat hacker "white."

1. What a white-hat hacker is — organizing the adjacent roles

"White-hat hacker" is a general term close to a Japanese-coined English, and in the English-speaking world it's called an Ethical Hacker. In practice the roles are split more finely, and confusing this here blurs "which certification to get and what to learn."

If you aim from inexperienced, the royal road is to first build the foundation of "vulnerability assessor / security engineer," and from there branch off, according to your interest, into "penetration tester (offense)" or "audit/defense (defense)." Offense and defense are two sides of the same coin, and you can't defend without knowing "how it's broken," and can't do effective offense without knowing "how to defend."

The strict difference and cost sense of "vulnerability assessment," "penetration test," and "audit" are stepped into from a practical viewpoint in How to Do Web-App Vulnerability Assessment [2026 Edition]. This article is "until you become the person," that one is "the practical how-to" — that's the relation.

2. The overall roadmap — survey it in 4 phases

Before getting into the details, hold the overall picture on one sheet. It's the 4 phases of "foundation → attack technique → proof (certifications) → combat & monetization." Each phase isn't independent; you go around it many times in a spiral.

[Phase 1] Foundation skills   Network / Linux / Web / programming / crypto basics
      │                       (thin here, and the upper layers become rote and collapse)
      ▼
[Phase 2] Legal practice      Stand up a vulnerable app on your own PC and attack / CTF / get used to tools
      │                       (the only phase where "the amount you got hands-on" directly becomes ability)
      ▼
[Phase 3] Prove with certs    Entry certs (CC / Security+ / RISS) → combat certs (PenTest+ / CEH / OSCP+)
      │                       (convert self-taught ability into "trust" that reaches a third party)
      ▼
[Phase 4] Combat & monetize   Bug bounty / vulnerability reporting / employment, projects / continuous learning
                              (touch "real targets" inside the safe zones, and make it a career)

The guideline period is, from inexperienced to "an entry level that works in the field," seriously 1–2 years, and to "OSCP+ class" as a penetration tester, 2–4 years. It's not a question of talent but the accumulation of how much you got hands-on in the safe zones. Don't rush, but be sure to get hands-on every week — this is the shortest route.

3. Phase 1: Foundation skills — why learn them

Security is the work of "understanding the operating principles of an application one level deeper than the developer." So the foundation is, more than attack techniques themselves, in "how a computer works." Memorize each field as a set with "why it's needed by an attacker," and it doesn't become rote.

Here, being able to write programming becomes a differentiator especially in the AI era. Generative AI dramatically speeds up recon and code reading, but it's a human that judges "is this behavior a vulnerability, or the spec." Rather, code mass-produced by generative AI tends to have inherent holes, and its detection becomes the coming main battlefield (→ How to Assess the Vulnerabilities of AI-Generated Code).

And the world standard for what to look for is OWASP (Open Worldwide Application Security Project). In parallel with the foundation, put the latest OWASP Top 10:2025 into your head as a "map."

OWASP Top 10:2025 (the official version as of June 2026)

Let me grasp what's deemed the most important risk in the 2025 edition. A01 "Broken Access Control" is still #1, and this is also where a white-hat hacker earns.

4. Phase 2: Build a legal practice environment yourself (hands-on)

This is the core of this article. You absolutely won't acquire it by just reading. Stand up an "app you may attack" on your own PC and get hands-on inside Chapter 0's safe zone ①. All the code below completes only in your local environment.

4-1. Stand up a vulnerable learning app with Docker

The industry-standard teaching material is OWASP's official Juice Shop (an intentionally-vulnerable EC site). It stands up in one shot with Docker. The most important etiquette here is to bind the port only to 127.0.0.1 (localhost) and absolutely never expose it externally. Expose a vulnerable app to the internet and you could be used as a stepping stone and become a perpetrator.

# security-lab.yml — 学習用の“意図的に脆弱な”アプリ。絶対に公開しないこと。
# 127.0.0.1 にのみバインドし、外部から到達不能にする（これ自体が重要な作法）。
services:
  juice-shop:
    image: bkimminich/juice-shop:latest   # OWASP公式の意図的に脆弱なアプリ
    ports:
      - "127.0.0.1:3000:3000"             # ← localhost限定。"0.0.0.0" にして公開しない
    security_opt:
      - "no-new-privileges:true"          # コンテナ内での権限昇格を抑止（最小権限）
    restart: "no"

# 起動（自分のPCのブラウザから http://127.0.0.1:3000 で開ける）
docker compose -f security-lab.yml up

# 練習が終わったら必ず落とす（脆弱なアプリを放置しない）
docker compose -f security-lab.yml down

Once it's up, open the browser's dev tools and reproduce each item of the OWASP Top 10 with your own hands — put ' OR 1=1-- in the login form, put a script in the product search. Juice Shop is in a task format (a scoreboard), so "what to learn" is naturally guided.

4-2. Widen "the breadth of noticing" with a passive scan (DAST)

You miss things with manual alone. With OWASP's ZAP (Zed Attack Proxy), first run a passive scan (baseline). The baseline "just patrols normally and reports the range it noticed" and doesn't fire attack requests, so it's gentle on your own lab of course.

# ZAP baseline：受動スキャン。自分のlab（127.0.0.1:3000）にだけ実行する。
# Linux: --network host で localhost を共有。
docker run --rm --network host \
  ghcr.io/zaproxy/zaproxy:stable \
  zap-baseline.py -t http://127.0.0.1:3000 -I

# macOS / Windows の Docker Desktop は host ネットワークが異なるため、
# 対象URLを http://host.docker.internal:3000 に置き換える。

Super-important: ZAP also has an active scan (zap-full-scan.py), but this actually sends attack requests, so never point it at anything other than a verification environment you manage (local/staging). The moment you point it at someone else's service, it becomes a Chapter 0 problem of the Unauthorized Computer Access Act and the virus offense.

4-3. Bake "the boundary of permission" into the code — a safe self-assessment script

White-hat-ness shows, more than how you use a tool, in the posture of "embedding ethics into the design." The Python below is a self-assessment script that structurally binds the destination with an allowlist so it can only run against your own lab. Based on the OWASP Secure Headers Project, it confirms the presence of the minimum security headers that should exist. With zero external dependencies (standard library only), it runs as-is.

"""lab_header_check.py — 自分のローカル検証環境にだけ実行する安全確認スクリプト。

設計意図: 許可なき対象への実行を“構造的に”不可能にする。
宛先は 127.0.0.1 / localhost に限定し、外れたら処理を始める前に拒否する。
（"ホワイト"を担保するのは技術ではなく、この"許可の境界"そのもの。）
"""

from __future__ import annotations

import sys
from dataclasses import dataclass
from urllib.error import URLError
from urllib.parse import urlparse
from urllib.request import Request, urlopen

# 許可された検証先（＝自分の管理資産のみ）。ここを緩めることが“無許可テスト”への第一歩。
ALLOWED_HOSTS: frozenset[str] = frozenset({"127.0.0.1", "localhost", "::1"})

# OWASP Secure Headers Project に基づく、最低限あるべき応答ヘッダー。
REQUIRED_HEADERS: tuple[str, ...] = (
    "content-security-policy",
    "strict-transport-security",
    "x-content-type-options",
    "referrer-policy",
)


class UnauthorizedTargetError(RuntimeError):
    """検証先が許可リストにない＝実行してはならない、という不変条件の違反。"""


@dataclass(frozen=True, slots=True)
class CheckResult:
    url: str
    present: tuple[str, ...]
    missing: tuple[str, ...]

    @property
    def ok(self) -> bool:
        return not self.missing


def assert_authorized(url: str) -> None:
    """検証先が自分の管理資産であることを保証する。違えば即座に中断（ガード節）。"""
    host = urlparse(url).hostname or ""
    if host not in ALLOWED_HOSTS:
        raise UnauthorizedTargetError(
            f"拒否: {host!r} は許可された検証先ではありません。"
            " 無許可の対象へのスキャンは不正アクセス禁止法に抵触し得ます。"
        )


def check_headers(url: str, *, timeout: float = 5.0) -> CheckResult:
    assert_authorized(url)  # 何より先に“許可”を検証する
    request = Request(url, method="GET", headers={"User-Agent": "lab-self-check/1.0"})
    with urlopen(request, timeout=timeout) as response:  # 宛先はallowlistで束縛済み
        present_keys = {key.lower() for key in response.headers.keys()}
    present = tuple(h for h in REQUIRED_HEADERS if h in present_keys)
    missing = tuple(h for h in REQUIRED_HEADERS if h not in present_keys)
    return CheckResult(url=url, present=present, missing=missing)


def main(argv: list[str]) -> int:
    if len(argv) != 2:
        print("usage: python lab_header_check.py http://127.0.0.1:3000", file=sys.stderr)
        return 2
    try:
        result = check_headers(argv[1])
    except (URLError, UnauthorizedTargetError) as error:
        print(f"中断: {error}", file=sys.stderr)
        return 1
    for header in result.present:
        print(f"  ok   {header}")
    for header in result.missing:
        print(f"  MISS {header}")
    print("\n判定:", "合格" if result.ok else "要改善（不足ヘッダーあり）")
    return 0 if result.ok else 1


if __name__ == "__main__":
    raise SystemExit(main(sys.argv))

# 自分のlabに対してだけ実行できる。許可外を渡すと“処理を始める前に”拒否される。
python lab_header_check.py http://127.0.0.1:3000   # OK（自分の資産）
python lab_header_check.py https://example.com     # → 中断: 'example.com' は許可された検証先ではありません。

In these 30 lines, the philosophy of a white-hat hacker is condensed. "Hold the confirmation of permission not as human self-restraint but as a code invariant." The more you advance the automation of assessment, the more this "writing the boundary into the rules" takes effect.

4-4. Learn attack "as a puzzle" with CTF

The best place to hone attack techniques without attacking a real environment is CTF (Capture The Flag). It's completely legal, and you can compete with people worldwide. For a beginner's entrance, this order is recommended.

• picoCTF — for education. From the basics of basics. Free, always available.
• TryHackMe — abundant guided learning rooms. Hand-holding.
• Hack The Box — more practical. The standard preliminary to OSCP+.

CTF "puzzle-izes" attack. Inside safe zone ②, it's also optimal for finding the direction of your interest — Web, crypto, reverse engineering, forensics, etc.

5. Phase 3: Turn "self-taught ability" into trust with certifications

Here many people misunderstand. A certification is not "proof of ability" but "a common language to convey ability to others." A recruiter or orderer doesn't have time to closely read your GitHub. A certification takes effect as a shortcut to that trust. Think of it split into 2 layers by role.

5-1. "Entry certs" — systematize the basics and step onto the ring

For the inexperienced, I recommend first systematizing the basics "broadly and correctly" with ISC2 CC or CompTIA Security+. Both work worldwide and are standards named in job postings.

5-2. The "RISS" you can't skip to work in Japan (a national qualification)

Within Japan, the Registered Information Security Specialist (RISS) is the only national qualification in the cybersecurity field. Because it's "effective" for bid requirements, internal evaluation, and job changes, if you're domestically oriented it's worth aiming for as the top priority. Let me organize the official information accurately.

• The exam itself requires no work experience. Anyone can sit it (IPA official). Many climb the stairs of FE → AP → RISS.
• From FY2026 the exam is CBT-ized. There's no change to the scope, format (multiple choice + written), or exam time, with a Section A / Section B structure. The spring-equivalent is planned to be held as the "first exam (around November 2026)" and the autumn-equivalent as the "second exam (around February 2027)" (IPA exam info).
• After passing, you can call yourself "RISS" only after "registering." Registration accompanies an obligation of continuous learning, and this is what sets it apart from other certifications.

The obligations after registration (the official numbers)

That is, RISS is designed as a "qualification you keep learning," not "get it and done." Always check the source IPA "RISS courses" and About renewal for the latest.

5-3. "Combat certs" — prove the ability to attack

Once you've solidified the basics, advance to certifications that show attack ability. The difficulty and "weight" are roughly in the order CEH < PenTest+ < OSCP+.

OSCP+'s exam structure (the November 2024 new format, official)

The OSCP+, spoken of as the white-hat hacker's "gateway," is not a desk exam but a 24-hour-straight practical. The point allocation based on OffSec's official is this.

• 3 standalone machines = 60 points total (20 points per machine: initial intrusion 10 points + privilege escalation 10 points)
• Active Directory set (3 machines) = 40 points total (10 + 10 + 20 points. A username/password is given, assuming "post-compromise")
• Pass at 70 of 100 points total. In the new format from November 1, 2024, bonus points were abolished, and it's judged purely on the practical score.
• OSCP+ expires 3 years after issuance (the old OSCP remains permanent).

CEH is "broad coverage," OSCP+ is "narrow and deep, proof that you can actually break in." If you want to show "combat ability" to the market in the shortest time from inexperienced, the order Security+ → PenTest+ → OSCP+ is the royal road in the balance of cost and difficulty. And if you look toward the topmost management/consultant tier, the (ISC)² CISSP, which requires 5 years of work experience, awaits as the "ceiling."

5-4. So in what order should you get them (the shortest route by type)

Total beginner, domestic-job focused   FE exam → AP exam → RISS (+ Security+ for the global lingua franca)
Want to go into attack (pentest)       ISC2 CC / Security+ → CEH (knowledge) → PenTest+ → OSCP+ (combat)
Want to go into defense (audit)        Security+ → RISS → (future) CISSP
Student/junior, just "one thing"       Security+ (works worldwide, the most cost-effective foundation)

6. Phase 4: Combat and monetization — legally touch "real targets"

Once you've stacked certifications and practice, finally touch safe zone ③ — permitted real systems. This connects directly to income and career.

6-1. Bug bounty — investigate a permitted target, with a reward

A bug bounty is a system where a company publishes "you may investigate within this range (scope), and if you find one we'll pay a reward." Representative platforms are HackerOne and Bugcrowd. The flow is this (HackerOne official).

1. Closely read the scope — always observe the target domains, permitted test methods, and prohibitions (DoS, social engineering, whether automated scanning is allowed). Out of scope is not a safe zone = it can be a crime.
2. Discovery — look for vulnerabilities within scope.
3. Report — report safely via the platform, with reproduction steps attached.
4. Verification & fix — the company confirms and fixes.
5. Reward & disclosure — a reward according to severity. Disclose by agreement with the company (don't disclose without permission).

Beware of safe harbor: many programs explicitly state "we won't take legal action as long as you observe the scope and rules." An act without this sentence / out of scope doesn't receive the protection of the Unauthorized Computer Access Act. Confirming "am I observing the rules" before "I want the reward" is the minimum condition of white.

6-2. If you find a vulnerability in a "party with no reward program" in Japan

"I happened to find a vulnerability in a Japanese service I was using. But they don't do a bug bounty." At this time, you must not dig deeper or disclose on your own. Japan has a formal window.

• The Vulnerability-Related Information Reporting System (the Information Security Early Warning Partnership) — a formal route the state has set up where IPA receives reports and JPCERT/CC handles coordination with the developer. Both product vulnerabilities and website vulnerabilities can be reported here, even anonymously.
• Look for a company's security.txt — a file standardized in RFC 9116 that machine-readably indicates a vulnerability-reporting window. Check https://example.com/.well-known/security.txt and quietly report to the Contact: address.

If you turn to the "receiving side" as a white-hat hacker, placing this on your own site is the etiquette. Indicating the reporting window itself becomes a mechanism that protects well-meaning reporters and recovers vulnerabilities ahead of attackers.

# /.well-known/security.txt — RFC 9116。脆弱性の通報窓口を機械可読で明示する。
Contact: mailto:security@example.com
Expires: 2027-06-30T00:00:00.000Z
Preferred-Languages: ja, en
Canonical: https://example.com/.well-known/security.txt
Policy: https://example.com/security-policy

6-3. The form of a vulnerability report that gets through

As much as technical skill, "a report that gets through to the developer who fixes it" divides the evaluation. The reader is busy. Conclusion first, reproducible, without destroying. The following is a template you can use as-is.

## Summary
<!-- In 1-2 sentences, conclusion first: "what and how dangerous." e.g., The order API has an
     authorization flaw, and another person's order can be viewed just by altering the ID (IDOR / A01:2025). -->

## Severity
CVSS 4.0 vector: AV:N/AC:L/AT:N/PR:L/UI:N/...   (self-assessment. The final judgment is the vendor's)

## Steps to Reproduce
1. Log in as a general user
2. Change GET /api/orders/1001 to GET /api/orders/1000
3. Confirm that another person's order info is returned

## Impact
<!-- What the attacker can achieve. Concretely: information leakage / tampering / takeover, etc. -->

## Suggested Fix
<!-- Optional but welcomed. e.g., Always verify "the order's owner == the logged-in user" on the server side. -->

## Proof of Concept
<!-- Example request and screenshots. Actual data minimal and masked. No destructive operations. -->

The IDOR (A01:2025 Broken Access Control) dealt with here is what a white-hat hacker finds most, and is typical of what a tool can't see through automatically. Its reason and the detection mindset are summarized in detail in Detecting Broken Authorization / IDOR in Next.js × Supabase.

7. "Learn it yourself" or "leave it to a pro" — the project viewpoint

Having read this far, the reality should have come into view. A white-hat hacker's ability isn't acquired overnight. 1–2 years for the foundation, 2–4 years for combat ability. This is also the flip side of it being of very high value to learn.

On the other hand, depending on your standing, the answer changes. "I want my own SaaS looked at properly once before release" — for this purpose, rather than you taking several years to become a white-hat hacker, having a person who already has the ability look at it is faster, cheaper, and more certain. The decision axis is simple.

The last row — authorization, RLS, tenant isolation, business logic — is, no matter how many tools you run, a "vertical risk" whose correctness only a human who understands "the meaning of the business rules" can judge. This is the highest-value area of a white-hat hacker (especially audit), and at the same time an area where, if you need a guarantee in a hurry, it's rational to rely on the outside. That boundary line is drawn honestly in What a Security Audit Looks At.

8. Frequently Asked Questions (FAQ)

Q. Can a humanities-major, inexperienced person become a white-hat hacker? A. You can. What matters is, more than educational background, "the power to persist logically" and "the habit of continuing to get hands-on legally." ISC2 CC and Security+ are designed for the inexperienced and don't ask for work experience.

Q. Is it possible with self-study alone? A. It's possible. This article's safe zones (your own lab, CTF, a formal bug bounty) all complete with self-study. But getting the "correct order" and "the line of the law" wrong makes it a detour and dangerous, so put Chapter 0 into your body first.

Q. How long does it take? A. The guideline is, seriously 1–2 years to entry level, and 2–4 years to OSCP+-class combat ability. It's decided not by talent but by "the accumulated time you got hands-on in the safe zones."

Q. Should I get an overseas certification (CEH/OSCP) or the national qualification (RISS)? A. It depends on the purpose. If you value domestic employment, bids, and public evaluation, RISS; if you show attack combat ability globally, OSCP+. Doing both is normal and not contradictory.

Q. I'm anxious about accidentally committing an illegal act while learning. A. As long as you don't go outside the 3 of "your own asset, CTF, a permitted scope," it's legal. Conversely, outside these 3, it can be illegal even with no harm. When in doubt about the judgment, don't do it is always the correct answer.

Q. Won't my job be taken by AI? A. Quite the opposite. Generative AI speeds up recon and code reading, but it's a human that judges "is this a vulnerability or the spec" and "is it a permitted act." Detecting vulnerabilities in the code AI mass-produces is an area where demand will grow from here.

9. Summary — the next step

The road to a white-hat hacker doesn't start from flashy attack techniques. It starts from the single line of "permission."

• Put Chapter 0 (law and ethics) into your body first. The Unauthorized Computer Access Act, the virus offense, the 3 safe zones. Before technique.
• The amount you got hands-on is the ability itself. Stand up a vulnerable lab with Docker (don't expose it), puzzle-ize attack with CTF, and bake "the boundary of permission" into a self-assessment script.
• Certifications are a common language that turns ability into trust. Entry (CC / Security+ / RISS) → combat (CEH → PenTest+ → OSCP+). Pin them to the official latest specs.
• Monetization is in safe zone ③. Bug bounties (HackerOne / Bugcrowd) and Japan's vulnerability-reporting system (IPA / JPCERT). The exit of discovery is always "a fix and agreement," not "disclosure and bragging."

And finally, don't forget that the answer changes depending on your standing. Both becoming a white-hat hacker yourself and leaving it to a person who already is one are correct choices. If your app is heading for a production release, first sweep the "horizontal holes" for free with OSS, and pass only the "vertical risks" that only design can protect to an expert — that's the most cost-effective way to defend.

Reference (Official Primary Sources)

• Law: Act on the Prohibition of Unauthorized Computer Access (e-Gov) / National Police Agency, Cybercrime Countermeasures, Laws / Penal Code (virus offense, e-Gov)
• Standards: OWASP Top 10:2025 / OWASP Juice Shop / OWASP ZAP / RFC 9116 (security.txt)
• Certifications: EC-Council CEH v13 / OffSec PEN-200 (OSCP+) / CompTIA Security+ / PenTest+ / (ISC)² CC / CISSP / IPA Registered Information Security Specialist (RISS)
• Reporting: HackerOne / Bugcrowd / IPA Vulnerability-Related Information Reporting / JPCERT/CC