White hackers and the law [2026 keeper edition]: the Unauthorized Access Act, active cyber defense, and the right way to report vulnerabilities

The first thing someone aiming to be a white hacker should learn is not attack techniques. It's the law.

Because what separates a white hacker from a black hacker is not technical skill but "authorization." The same port scan, the same SQL-injection attempt — if the target is "your own asset" or "an authorized target," it's legitimate work; otherwise, it's a crime. Get hands-on without internalizing this line, and well-intentioned learning instantly becomes a criminal record.

This article is a "keeper edition" summarizing the laws needed to act as a white hacker in Japan, faithful to official primary sources (e-Gov Law Search / National Police Agency / Cabinet Secretariat / IPA / JPCERT/CC). Beyond quoting articles, it concretely shows, with implementation code, "so, how exactly do you act legally."

This is a spoke that independently deepens the law part of how to become a white hacker (complete roadmap).

1. The Unauthorized Access Act — the "outer perimeter" of a white hacker's map

The Act on Prohibition of Unauthorized Computer Access (Act No. 128 of 1999, commonly the "Unauthorized Access Act") defines the outer perimeter of your activity. Based on the National Police Agency's explanation, let me accurately organize the prohibited acts and penalties.

The most important point: "breaking access control itself" is a crime

The core of this law is that it doesn't ask whether damage occurred. Even if you didn't look at the data or alter anything, the moment you "accessed a normally-restricted computer by bypassing access control," the offense is complete.

• "I thought it was harmless" / "I meant it as a behavior check" — they don't work.
• "Just the login screen was shown" — displaying a screen is lawful, but stepping further (auth bypass, brute force, vulnerability exploitation) is illegal.

In Japan, this line is operated strictly. Don't do more than normally viewing the public range against an unauthorized target — this is the absolute rule.

The latest point as of 2026: with the June 2025 Penal Code amendment, the former "imprisonment with/without labor" was unified into "confinement." Old explanatory articles write "imprisonment up to 3 years," but the current article is "confinement." Always confirm the latest version of the article in e-Gov Law Search.

2. The law for those who make tools — the Penal Code's virus offense

White hackers write diagnostic scripts and PoC (proof-of-concept code). What comes into play here is the Penal Code's offense concerning unauthorized commands and electronic records (Penal Code 168-2 and 168-3, commonly the "virus offense").

The point is the article's phrase "without a legitimate reason." Creating, providing, acquiring, or storing malware or attack code without a legitimate reason is subject to punishment.

同じ「攻撃コード」でも……
  ┌─ 許可された診断・教育・研究の文脈で書く  → 正当な理由あり → 合法
  └─ 文脈を欠いて作成・配布・保管する         → 正当な理由なし → ウイルス罪のリスク

In other words, what separates illegal/legal is not "what you wrote (the code)" but "why and where you use it (the context)." A diagnostic tool is legal because there's a context of using it against an authorized target. The moment that context is lost, the same code becomes illegal. Don't carelessly publish your own tools to the general public — this is both technical ethics and legal-risk management.

3. The "three safe zones" for acting legally

So where can you get hands-on freely? Practice and research are allowed, in principle, in only these three. As long as you don't go outside this "fence," your activity is completely legal.

1. Assets you manage — your own PC, a VPS you rented, an app you built. (→ for the environment, see the self-study roadmap: building a legal lab at home)
2. Learning environments / CTFs intentionally made vulnerable — targets explicitly stated as "OK to attack" like OWASP Juice Shop, DVWA, picoCTF, Hack The Box, TryHackMe.
3. The authorized scope of a formal bug bounty / vulnerability-disclosure program (VDP) — a target a company has published "you may investigate within this range" and provided safe harbor for. (→ how to start a bug bounty)

The "safe harbor" of safe zone ③ is being standardized in frameworks like disclose.io. It's the company's promise that "as long as you follow the rules and scope, we won't take legal action." Conversely, an act without this promise / outside the scope receives no protection from the Unauthorized Access Act at all.

4. Latest trend: active cyber defense (promulgated 2025, effective 2026)

In 2025, Japan's cybersecurity legislation moved greatly. A new law to realize "active cyber defense," commonly the Cyber Response Capability Enhancement Act (official name: Act on the Prevention of Damage from Unauthorized Acts against Important Computers), etc., was promulgated on May 23, 2025 and takes effect in stages during 2026 (primary sources: Cabinet Secretariat Cyber Security, Cybersecurity Strategy (Reiwa 7)).

It has three pillars.

• Strengthening public-private cooperation — information sharing and reporting obligations for critical-infrastructure operators.
• Use of communication information — mechanical, limited selection of information to catch attack signs (operated strictly so as not to infringe the constitutional "secrecy of communications").
• Neutralization of attack servers — the state (police, Self-Defense Forces) can neutralize attack infrastructure under certain procedures.

Implications for white hackers

"The state can neutralize attack infrastructure" means, conversely, that society as a whole has shifted from 'passive' to 'active' against cyberattacks. In this current,

• The risk of an individual's unauthorized hacking rather rises. The net of monitoring and investigation is tightening.
• On the other hand, demand for legitimate security talent will certainly grow. Both companies and the state need people who can defend.

In other words, rightly aiming to be a white hacker now means being in a tailwind. The value of "talent on the legal side with solid skill" is being pushed up institutionally.

5. If you discover a vulnerability — there are only three right "exits"

In the course of learning or using services, you may notice a real vulnerability. Your action here determines whether you're white. There are three exits.

発見した脆弱性は誰のもの？
  ├─ 自社/自分の資産          → 直す（必要なら本記事のコードで通報窓口も整える）
  ├─ 他社：バグバウンティ対象  → プラットフォーム経由で報告（HackerOne / Bugcrowd）
  └─ 他社：報奨制度なし        → 日本の「脆弱性届出制度」へ（IPA受付・JPCERT/CC調整）

What you absolutely must not do is "dig deeper without permission," "expose it on social media," or "directly press the party with 'you have a vulnerability, give me a reward.'" The last can be taken as extortion.

Japan's formal route: the vulnerability-information reporting system

If you find a vulnerability in a Japanese service/product with no reward program, there's a formal route the state has set up: the Information Security Early Warning Partnership.

• IPA receives the report, and JPCERT/CC handles coordination with the developer (coordinated disclosure).
• You can report both software-product and website vulnerabilities here.
• This is "reporting," not "attacking." It presupposes that the discovery's circumstances were within a safe zone (the range of normal use). Don't do deep-dive verification without permission.

6. [Implementation] Become the side receiving reports — placing security.txt correctly

As you mature as a white hacker, you also come to the side of setting up the "report channel" for your own service. The global standard for that is security.txt defined in RFC 9116. Placing it at https://example.com/.well-known/security.txt lets well-intentioned reporters find "where to contact" in a machine-readable way.

Stating the report channel itself becomes a mechanism to collect vulnerabilities before attackers. Below is a production-quality implementation that serves security.txt type-safely, cacheably, with the expiry auto-calculated in a Next.js (App Router) Route Handler.

// app/.well-known/security.txt/route.ts
// RFC 9116 準拠の security.txt を配信する Route Handler。
// 設計: 単一の真実源（CONTACT 等）を定数化し、Expires は配信時に未来日付へ自動更新する。
import { NextResponse } from "next/server";

// 連絡先などの“真実源”。環境ごとに変わる値は env 経由で注入し、ハードコードを避ける。
const SECURITY_CONTACT = process.env.SECURITY_CONTACT_URL ?? "mailto:security@example.com";
const CANONICAL = "https://example.com/.well-known/security.txt";
const POLICY = "https://example.com/security-policy";
const PREFERRED_LANGUAGES = "ja, en";

// RFC 9116: Expires は必須。1年以内が推奨。配信時刻から1年後を機械的に算出する。
const oneYearFromNow = (): string => {
  const expires = new Date();
  expires.setUTCFullYear(expires.getUTCFullYear() + 1);
  return expires.toISOString();
};

const buildSecurityTxt = (): string =>
  [
    `Contact: ${SECURITY_CONTACT}`,
    `Expires: ${oneYearFromNow()}`,
    `Preferred-Languages: ${PREFERRED_LANGUAGES}`,
    `Canonical: ${CANONICAL}`,
    `Policy: ${POLICY}`,
    "", // 末尾改行
  ].join("\n");

export function GET(): NextResponse {
  return new NextResponse(buildSecurityTxt(), {
    status: 200,
    headers: {
      "Content-Type": "text/plain; charset=utf-8",
      // 1日キャッシュ＋再検証。配信のたびに Expires が動くが、内容は安定するため安全。
      "Cache-Control": "public, max-age=86400, must-revalidate",
    },
  });
}

The crux of this implementation is that Expires is auto-updated to a future date at serve time. security.txt requires Expires, and once it expires it becomes invalid. A hand-written fixed date breeds the typical operational incident of "leaving it expired," so it's designed so that the machine always returns a future date (idempotent, resilient, easy to operate).

7. Common misconceptions (FAQ)

Q. Is it legal to try SQL injection against my own data with my own account? A. If the target is an app you manage / a local environment, it's legal. For another company's production service, breaking server-side access control is potentially illegal even within your own account. When unsure, reproduce it in safe zone ① (your own lab) first, then think.

Q. What about "viewing" a public website? A. Normal viewing (display in a browser, using a public API per its spec) is lawful. It becomes illegal from the moment you step into bypassing access control, breaking authentication, or exploiting a vulnerability.

Q. If the server is overseas, does Japanese law not apply? A. A dangerous misconception. If done from within Japan, Japanese law can apply, and you also touch the other country's law. "Whoever, wherever it belongs to, don't do it without permission" is the only safe guideline.

Q. Within a bug bounty's scope, can I do anything? A. No. Even within scope, DoS, social engineering, exfiltrating other users' data, etc., are prohibited in many programs. Safe harbor takes effect only by following both the scope and the rules.

8. Summary — the law is not a "constraint" but a "license"

As long as you see the law as a "bothersome constraint," you can't become a white hacker. Knowing exactly the boundary line of law and ethics is the "license" to immerse yourself in technology with confidence.

• Breaking access control itself is a crime (regardless of damage; the Unauthorized Access Act).
• The line for tools is the context (the virus offense, "legitimate reason").
• Limit activity to the three safe zones (your assets / CTF / authorized scope).
• The exit for discovery is "fix and agreement" (bug bounty / Japan's reporting system / security.txt). Don't disclose without permission.

Once you internalize these four, the rest is honing your skill with peace of mind. For how to build the hands-on environment, go to the self-study roadmap; for the formal route to earn rewards, how to start a bug bounty.

For companies: in the era of active cyber defense, if you want to confirm "is our app OK," the safest is to get ahead with a formal vulnerability assessment/audit rather than waiting for unauthorized testing. Confirming authorization, RLS, and tenant separation before production release can only be judged by an expert who understands the design.

References (official primary sources)

• Act on Prohibition of Unauthorized Computer Access (e-Gov) / National Police Agency, Cybercrime Countermeasures, Laws
• Penal Code (virus offense, 168-2/3, e-Gov)
• Cabinet Secretariat Cyber Security (active cyber defense) / National center of Incident readiness and Strategy for Cybersecurity (NISC / cyber.go.jp)
• IPA Vulnerability-Information Reporting / JPCERT/CC / disclose.io / RFC 9116 (security.txt)