Module 1M — Hacker Lawsuits: The Cases That Defined the Line

Non-Lawyers Summary

This module is the technical translation of cybersecurity case law. It explains court decisions not through legal jargon, but through the lens of technical authorization, authentication bypass, and system boundaries. If you probe systems, scrape data, or conduct security research, these are the cases that determine where the "Safe Harbor" ends and the "Felony" begins.

The Root Summary

The law wasn't built for you. It was built in 1986, for a world where a "hacker" was someone breaking into mainframes with war-dialers and guessing passwords by brute force. The Computer Fraud and Abuse Act doesn't know what a bug bounty is. It doesn't distinguish between a researcher who finds a flaw and reports it privately and a criminal who exploits it for money. It draws one line: authorization. Everything else — your intent, your disclosure practices, your ethics — gets decided by judges and juries after the fact.

These are the cases that pulled that line into focus. Each one was a bet someone made about where the boundary was. Some of them were right. Some of them were very, very wrong.

The Hacker's Cheat Sheet: Landmark Rulings

1. Van Buren v. United States (2021) — The Case That Rewrote the Rules

The Before

Sergeant Nathan Van Buren was a Georgia police officer with a problem. He owed money, and a man had offered him a way out: run a license plate number through the law enforcement database. Find out who owned the car. Get paid.

Van Buren had legitimate access to the database. He was authorized to use it. He used it — for a purpose his authorization was never meant to cover.

The Disruption

Federal prosecutors charged him under the Computer Fraud and Abuse Act for "exceeding authorized access." The theory: even though he had a valid login, he used it to access data he had no legitimate purpose to access. The act of misuse, they argued, was itself a violation.

The Mystery

If prosecutors were right, the implications went far beyond a corrupt cop. Every person who had ever used a work computer to check personal email. Every researcher who had accessed a system for purposes that violated the terms of service. Every security professional who had used authorized credentials to probe systems in ways the vendor hadn't explicitly blessed. All of them could be criminals.

The Reveal

Then the Supreme Court dropped the ruling that changed everything.

The Court held that CFAA's "exceeds authorized access" covers accessing a prohibited area of a computer system — not mere misuse of permitted access. In other words: if you can technically access the data, using it for the wrong reason isn't a CFAA crime. The law is about crossing technical gates. Not about what you do once you're inside.

Van Buren v. United States, 593 U.S. ___ (2021).

The Escalation — What This Means for Security Research

The decision was seismic. It meant that violating a terms-of-service clause — "you may not use this site for security research" — while using legitimately issued credentials does not trigger criminal CFAA liability. ToS violations alone are not a federal crime.

The Collapse — The Part Everyone Forgets

But Van Buren didn't end civil CFAA liability. Private plaintiffs suing under CFAA § 1030(g) are not the Department of Justice. A company that doesn't like what you found — even if it makes their systems safer — can file a civil suit. Van Buren narrowed the criminal exposure. It did not eliminate the legal risk.

The Lesson

Hacker Translation: If you have an account and you use it to do something the company doesn't like — but your account technically has permission to access that data — you didn't "exceed authorized access" under the federal criminal CFAA. This protects you from being a criminal just for violating a robots.txt or a "don't use this for security research" clause in a ToS, as long as you didn't bypass a technical gate.

Your Risk Level: Lower — for authorized users. Not zero.

2. hiQ Labs, Inc. v. LinkedIn Corp. (2022) — The Public Web Ruling

The Before

hiQ Labs built its business on LinkedIn data. Their product analyzed public profiles — job titles, career trajectories, skill sets — to help companies predict employee attrition. The data was public. LinkedIn didn't require a login to view it. hiQ scraped it at scale.

The Disruption

LinkedIn sent a cease-and-desist. Then they started blocking hiQ's IP addresses. Then they filed suit.

LinkedIn's argument: even scraping public data is "without authorization" when the site owner tells you to stop.

The Reveal

The court said no.

CFAA is about "breaking and entering." If there is no login gate — no authentication barrier — there is nothing to break. You cannot "access without authorization" a system that places no restriction on access. The public web is, by definition, public.

hiQ Labs, Inc. v. LinkedIn Corp., 31 F.4th 1180 (9th Cir. 2022).

The Lesson

Hacker Translation: Scraping public data is generally safe from CFAA, even if the owner says "stop." But watch out for state laws and breach of contract claims — and understand that "public" is the operative word. Scraping data behind a login, even a trivially bypassed one, is a different analysis entirely.

Your Risk Level: Lower — for genuinely public data. Different calculation if any authentication exists.

3. United States v. Auernheimer (2014) — The Warning No One Heeded

The Before

The vulnerability was almost embarrassingly simple. AT&T's website assigned ICC-IDs to iPad accounts. The IDs were sequential. If you knew one, you could guess the next. There was no login gate. Just an IDOR sitting in plain sight on a publicly accessible URL.

Andrew Auernheimer — known online as "weev" — found it. He and an associate wrote a script. They iterated. They collected 114,000 email addresses of iPad customers, including government officials and executives.

Then came the choice that defined the case. Instead of reporting privately, they went to Gawker.

The Disruption

Federal prosecutors charged Auernheimer with conspiracy to violate the CFAA and identity fraud. No password was bypassed. No authentication was defeated. The URLs were publicly accessible. And yet a federal jury convicted him.

The Mystery

How? The technical act — sending GET requests to a public URL — seemed indistinguishable from normal web browsing. The government's theory was that the intent and the collection at scale transformed ordinary web requests into unauthorized access.

The Escalation

The conviction was eventually reversed — but not because the court decided the underlying act was legal. It was reversed on venue: the trial was held in New Jersey, but neither Auernheimer nor his servers were located there. The technical merits were never fully adjudicated.

The Collapse

What the case left behind was a warning, not a vindication.

The Lesson

Hacker Translation: Just because there is no admin:admin login page doesn't mean the "unauthorized" hammer won't swing. If you find a data leak and then advertise it before the company has a chance to fix it, your "intent" payload becomes exhibit A. You only needed one record to prove the vulnerability. Taking 114,000 and handing them to a journalist is a different act — legally and ethically.

Your Risk Level: High — if you collect at scale and disclose publicly before the vendor can remediate.

4. Facebook, Inc. v. Power Ventures, Inc. (2016) — The "Stay Out" Bit

The Before

Power Ventures thought they had found a clever model: aggregate a user's social network data from multiple platforms — with the user's permission — and display it in one place. Users gave Power Ventures their Facebook credentials. Power Ventures used those credentials to access Facebook on the users' behalf.

Facebook didn't see it that way.

The Disruption

Facebook sent a cease-and-desist letter. They blocked Power Ventures' IP addresses. Power Ventures found a way around the IP blocks and kept scraping.

The Reveal

Then the court drew a line that every security researcher should memorize.

When Facebook blocked the IP addresses and sent the C&D, something changed. Before the block: access was arguably authorized through the users. After the block: Facebook had implemented a technical restriction and communicated it in writing. Circumventing that restriction was "without authorization" under CFAA.

Facebook, Inc. v. Power Ventures, Inc., 844 F.3d 1058 (9th Cir. 2016).

The Escalation

Power Ventures was held liable. The court found that the IP block, combined with the C&D letter, constituted a clear revocation of authorization. Once revoked, any further access — regardless of the users' continuing permission — was a CFAA violation.

The Lesson

Hacker Translation: The moment they send you a letter saying "Stay Out" AND implement a technical block, any attempt to circumvent that block is a CFAA violation. It doesn't matter that you believe you have a right to access the data. The "Stay Out" bit has been set — at both the technical and legal level. Rotating proxies to get around an IP ban, after a C&D, is not resilience. It's a felony.

Your Risk Level: Critical — after notice. Stop immediately. Document that you stopped.

5. Sandvig v. Barr (2020) — The Researcher's Partial Win

The Before

Academic researchers wanted to study algorithmic bias on employment platforms. To do it properly, they needed to create test accounts — which would violate the platforms' terms of service. The research was legitimate. The method was necessary. And the researchers were afraid they'd be prosecuted under CFAA just for running the study.

The Disruption

They filed a pre-enforcement challenge before the research began, asking the court to declare that the CFAA threat was unconstitutional as applied to their ToS-violation research.

The Reveal

The D.C. Circuit held that mere ToS violations — without bypassing authentication — do not constitute "access without authorization" under CFAA. A researcher who creates a fake account on a platform to study discriminatory behavior is not a federal criminal for that act alone.

Sandvig v. Barr, 980 F.3d 94 (D.C. Cir. 2020).

The Lesson

Hacker Translation: Breaking "Terms of Service" to test for bias or run academic research isn't automatically a federal crime. Van Buren later confirmed this logic at the Supreme Court level. But the protection is narrow: it applies to ToS violations, not to authentication bypasses. And it does not address state computer crime laws, which have their own standards.

Your Risk Level: Lower — for pure ToS research with no authentication bypass. Not zero.

Hacker's Protocol: How to Stay in the Safe Harbor

The cases above define the edges. Here's the operational protocol that keeps you on the right side of each one:

1. Check for a SECURITY.txt or VDP first. If they have a program, you have Contractual Authorization — the legal equivalent of a get-out-of-jail-free card. This removes the "without authorization" element from the CFAA analysis entirely. Nothing else in this protocol matters as much as this step.
2. Don't bypass auth if you don't have to. If it's behind a login, use your own account or an account provided by the program. The moment you defeat an authentication mechanism — any mechanism, even a weak CAPTCHA — you move from Van Buren's protected zone back into full CFAA exposure.
3. Watch your intent log. If you find a bug, report it. If you find a bug and then sell the data, post it publicly, or use it for any purpose beyond demonstrating the vulnerability, your "intent payload" will be used against you. Prosecutors don't just look at what you did. They look at what you did next.
4. Respect the technical "NO." A 403, an IP ban, a C&D letter — these are not challenges. They are legal events. After a block and a C&D, continuing to probe — regardless of how you feel about the merits — moves you squarely into Power Ventures territory. Stop. Document that you stopped. Then decide whether to engage legal counsel.
5. Minimum necessary data. To prove a BOLA/IDOR, you need one record. Not a full database dump. The scope of what you collect determines whether you're demonstrating a vulnerability or committing a data theft. Take one. Document it. Report it. Stop.

Quiz: Are You About to Get Pwned by the Law?

1. You scrape a public API with no key that has no "Terms of Service" listed.

• [ ] Safe (Gates Down)
• [x] Mostly Safe (But check for state-level "Computer Trespass" laws)

1. You find a BOLA/IDOR that lets you see other users' data. You download the whole DB to "prove" the bug.

• [ ] Good Research
• [x] CFAA Risk (Exceeding scope/authorization. You only needed to prove it on ONE record).

1. A company sends you a C&D for your research. You switch to a VPN and keep testing.

• [ ] Resilient
• [x] Felony-Level Risk (Circumventing technical barriers after notice).