⚖️ Authorisation, Ethics & Disclosure

Authorisation, Ethics and Disclosure

Authorisation is the whole difference

A port scan is a port scan. Nothing in the packets distinguishes a paid penetration test from an intrusion — the technique, the tooling and the traffic are identical. The only difference is whether somebody with the authority to grant it said yes, in advance, in writing, for those specific systems.

The usual rationalisations do not work. "I was only looking." "The system was insecure anyway." "I meant to report it." "It was publicly reachable." None of these is a defence in most legal systems, and none changes what the target's logs show: an unknown party probing their infrastructure. Good intentions are invisible from the other side of the connection.

The general legal shape

Nearly every country has an unauthorised-access statute. A non-exhaustive, illustrative sample:

Common threads, stated carefully: access without authorisation is the core offence; intent and damage usually affect severity rather than whether an offence occurred; and possession or distribution of tooling is treated differently in different countries, which is why the same software can be routine in one place and legally awkward in another. Courts also keep reinterpreting what phrases like "without authorisation" cover, so what was true five years ago may not be true now, or in the next country over.

Criminal law is not the only exposure. Terms of service, civil claims, your employer's acceptable-use policy and data-protection law can all apply to activity no prosecutor would ever look at. Breaking the specific terms of a bug-bounty programme, for instance, is usually what removes the safe harbour that made your testing permitted in the first place.

What real authorisation looks like

"Sure, go ahead" in a chat message is not authorisation. A usable engagement document answers all of the following before any traffic is sent:

A minimal rules-of-engagement extract, in the form you should expect to see it:

SCOPE (in):    *.example.com  |  198.51.100.0/24  |  iOS app "Example" build 4.2
SCOPE (out):   payments.example.com (third-party processor)
               anything resolving outside 198.51.100.0/24
WINDOW:        2026-08-03 09:00 -- 2026-08-14 18:00 Europe/London
FORBIDDEN:     DoS / load testing, social engineering, physical, data modification
RATE LIMIT:    max 20 req/s per host; no automated scanning 08:00-10:00 (peak)
ACCOUNTS:      pentest1..pentest5 supplied; do not access other accounts
CONTACTS:      Security lead <sec-lead@example.com>, +44 ...  (Signal preferred)
STOP:          Either party may halt testing; confirm by phone, then email
ON FINDING PII: stop, do not download, record location only, notify within 1 hour
EVIDENCE:      encrypted at rest, destroyed 30 days after report acceptance

When you find something out of scope

It happens constantly: a wildcard in scope resolves to a third-party service, an in-scope host sits on a shared address, or an in-scope vulnerability opens a path into something that is not. The rule is boring and firm — stop, do not explore further, document only what you already have, and report it through the agreed channel. Ask, in writing, before continuing. The instinct to "just confirm the impact" is exactly how an authorised test becomes an unauthorised one.

Bug bounty and safe harbour

Bug-bounty and vulnerability-disclosure programmes are standing authorisation — but only on their own terms, and only for what the policy names. Read the policy first, in full, and note:

• Scope and out-of-scope, including whether wildcards genuinely mean everything and whether acquisitions are included.
• Prohibited techniques — automated scanning is banned or rate-limited in many programmes, and ignoring that is a common way to be removed.
• Whether safe harbour is real. Look for explicit language that the organisation will not pursue civil or criminal action for good-faith research within the policy — and note that no such promise binds third parties whose systems you touch.
• Disclosure rules. Many programmes require permanent confidentiality or approval before publication. Decide whether you accept that before you look; you cannot un-know a finding.
• Data rules — what you may access to demonstrate impact, and what you must never retrieve.

Reporting outside a formal programme is still normal and usually welcome, but the authorisation question does not disappear: finding a bug during ordinary use of a public service is different from probing for one.

Coordinated vulnerability disclosure

Coordinated vulnerability disclosure (CVD) is the mainstream model: report privately, give the vendor a reasonable window to fix, publish afterwards so everyone else can defend themselves. Full disclosure — publishing immediately, without notice — is a minority practice, occasionally justified when a vendor is unreachable or negligent, and it always trades users' short-term safety for pressure on the vendor. Choose deliberately, not out of irritation.

Typical published windows, for calibration (they vary and you should follow the policy you are actually operating under): CERT/CC's default disclosure policy is 45 days; Google's Project Zero uses 90 days plus a 30-day grace period after a fix ships; the Zero Day Initiative uses 120 days. There is no universal deadline — what matters is that the timeline is stated up front and applied consistently.

Finding the right contact

1. /.well-known/security.txt (RFC 9116) — the standard place. Look up a domain's security.txt →
2. The security@ role mailbox (RFC 2142 defines it for exactly this).
3. The vendor's PSIRT page, or a bug-bounty platform if they run one.
4. A coordinator — CERT/CC or your national CSIRT — if the vendor is unreachable, if many vendors are affected, or if you need a neutral intermediary. A CVE Numbering Authority can assign an identifier.

A valid security.txt is small; Contact and Expires are the required fields:

# https://example.com/.well-known/security.txt
Contact: mailto:security@example.com
Contact: https://example.com/security/report
Expires: 2027-01-01T00:00:00.000Z
Encryption: https://example.com/pgp-key.txt
Preferred-Languages: en, de
Policy: https://example.com/security/policy
Acknowledgments: https://example.com/security/thanks

What a good report contains

• One-paragraph summary and the concrete impact — what an attacker gains, not just what is technically true.
• Exact affected asset, version, endpoint and parameters; the date and time you observed it.
• Reproduction steps precise enough for their engineer, with the minimum evidence needed. One redacted screenshot, not a database.
• Suggested remediation if you have one, and any mitigating factors — credit for accuracy is worth more than drama.
• Your intended disclosure timeline, stated politely and up front, and how to reach you (with a PGP key if you offer one).

When the vendor is hostile

Sometimes the response is silence, denial, or a lawyer's letter. Keep the moral and evidential high ground:

• Stay factual and unemotional in writing. Every message you send may be read later by people you did not intend.
• Keep a dated record of every contact attempt and response.
• Never attach a price to your silence, and never imply one. Payment demanded in exchange for not publishing reads as extortion regardless of what you meant.
• Do not retaliate, do not re-test to "prove" a point, and do not publish out of spite — the people harmed by an unpatched bug are users, not executives.
• Escalate to a coordinator (CERT/CC, a national CSIRT, or a platform's triage team) who can mediate and add legitimacy.
• If legal threats arrive, stop communicating directly and get advice. Anonymity is not a plan: assume you are identifiable.

If you stumble into personal data

Sooner or later a proof of concept returns somebody's real name, address or medical record. At that moment your obligations change, and restraint matters more than speed:

• Stop immediately. You have proof of access; you do not need proof of volume.
• Do not exfiltrate. Not "to check", not "to prove it", not to a personal machine or cloud drive. Downloading a dataset moves you from research to acquisition of data, which is treated very differently.
• Minimise evidence. One redacted record, or a count plus the field names, is normally enough — and redact before it lands anywhere permanent.
• Report promptly. The data controller may have a statutory notification deadline that starts when they become aware. Telling them late makes their position worse.
• Destroy what you hold once remediation is confirmed, and state in the report what you held and that it is gone.
• Never publish samples of real personal data, redacted or not, and do not paste it into third-party tools.

The rules of this site

Plainly, so there is no ambiguity about what h4ck0r.com is:

• These tools are diagnostic. They are the same class of thing as a DNS lookup, a certificate viewer or an HTTP header check — they read what a host publishes. There is no exploitation, no payload delivery, no credential attack and no flooding capability here, and none will be added.
• Active probes — port checks, HTTP method and CORS probes, exposure and reachability checks — target one named host at a time, are rate-limited server-side, and are logged like any other web request.
• The site cannot tell whether you are entitled to test a target, and it does not pretend to. Using these tools against systems you do not own or have written permission to test is your decision and your liability.
• Output from these tools is information about a public-facing configuration. Using it to attack somebody is not what any of this is for.
• The learning material here describes attacker behaviour so it can be recognised and defended against. That understanding is the point; the conduct is not.