"Hacking" is an overloaded word. In security work it can mean testing controls, finding weaknesses, or proving impact. In law, the dividing line is usually authorization. Access without permission, access beyond permission, or interference with systems can be criminal even when no permanent damage was intended.
Safety note: this is general information, not legal advice. Laws, enforcement, and definitions of "authorization" vary by jurisdiction and context.
The authorization boundary that matters most
Most legal systems treat a computer system as something you need a right to access. "I was curious" is not a permission model. If you are doing security testing, the safest posture is written authorization that defines:
- Scope: exactly what systems and accounts are in bounds.
- Methods: what you will and will not do (no denial-of-service, no data exfiltration, no persistence).
- Time window and points of contact: who can stop the test and how you report.
Common activities and why they create legal risk
| Activity | Risk without explicit authorization | Safer alternative |
|---|---|---|
| Logging into someone else's account or guessing credentials | Unauthorized access, identity harm | Test only with accounts you control or written permission from the system owner |
| Scanning or probing a system you do not own | Can be interpreted as access attempts or interference | Use vendor bug bounty scope lists or a lab environment |
| Downloading data to "prove" exposure | Data theft, privacy violations, breach notification triggers | Prove with minimal samples and coordinate disclosure through an authorized channel |
| Changing or deleting data during testing | Integrity interference and operational harm | Use non-destructive proof-of-concept techniques and document carefully |
| Publishing exploit details or access paths | Enables abuse and can create additional liability | Responsible disclosure to the owner or a coordinated program |
If you want the defensive and permitted side of the topic, read what are ethical hackers and the term reference for zero-day vulnerabilities.
What laws often target (in plain language)
Legal frameworks differ, but the same themes show up repeatedly:
- Unauthorized access: getting into a system or account you are not allowed to access.
- Exceeding permission: accessing data or systems outside the scope you were given.
- Interference: impairing systems, deleting data, introducing malware, or causing outages.
- Tooling with intent: creating, supplying, or using tools in ways tied to illegal access or interference.
In the United States, the Department of Justice publishes its charging policy for the Computer Fraud and Abuse Act (CFAA), which is one of the major federal computer crime statutes: Justice Manual: Computer Fraud and Abuse Act.
In the United Kingdom, the Crown Prosecution Service provides guidance on Computer Misuse Act offenses and how "unauthorized access" is assessed in prosecutions: CPS: Computer Misuse Act.
What to do if you discover a real vulnerability
If you find a vulnerability in a system you do not own, do not escalate access to "confirm" it. Your goal is to reduce harm, not to create a larger incident.
- Stop at the minimum proof needed to describe the issue.
- Document what you saw without copying sensitive data.
- Use the organization's published security contact or bug bounty program if one exists.
- If there is no published path, use a standard responsible disclosure email and include clear reproduction steps that do not enable abuse.
Common mistake: "helpful" testing that becomes unauthorized access. If you are not sure you have permission, assume you do not.
What to do if you are the victim of hacking
Legal consequences matter, but recovery matters more. If you are dealing with account compromise, prioritize containment and evidence. Start with been hacked: take these steps immediately and then stabilize the accounts that can reset other accounts.
The operational truth is simple. Permission boundaries are part of security. When authorization is explicit and scoped, security research can help. When authorization is absent or vague, the same behavior can become a crime.
If you want to learn security safely, use labs, capture-the-flag environments, and vendor-run programs. Skills built in a permitted environment transfer. Legal risk does not.
That is the core tradeoff: learn and test in ways that reduce harm and increase trust, not in ways that create victims and legal exposure.