Proxy site's OrganizationVisit Website →
← Back to blog

Avoid GDPR Fines and CFAA Risk: 2026 Web Scraping Playbook

September 12, 2026
Avoid GDPR Fines and CFAA Risk: 2026 Web Scraping Playbook

Scraping publicly accessible, logged-out web pages is generally lawful in the United States and most jurisdictions, but "generally lawful" is not "always safe." The real answer hinges on five variables: whether you bypass an access control, what a contract or terms of service says, whether the content is copyrighted or database-protected, whether personal data is involved, and whether your crawling causes measurable server harm. Purpose matters too. Scraping for AI training or resale draws sharper regulatory scrutiny than scraping your own competitor's public price list, and the jurisdiction you operate in can flip the answer entirely.

TL;DR:

  • Scraping publicly accessible pages without login or personal data generally remains low risk, but bypassing security measures or violating site terms can raise serious legal issues.
  • Under U.S. law, scraping public data is less likely to violate the CFAA, especially if no technical access restrictions are bypassed; however, contract breaches and server harm claims remain viable.
  • In Europe, GDPR and database rights impose stricter controls, requiring lawful processing, transparent safeguards for personal data, and caution against extracting protected database content.
  • Bypassing CAPTCHAs or login gates significantly increases legal exposure, making technical compliance, like rate limiting and accurate request logging, essential for risk mitigation.
  • When training AI models with scraped content, organizations must implement robust privacy safeguards, document balancing tests, exclude sensitive data, and consider licensed data sources to avoid regulatory penalties.
Natproxies
Scale Scraping With Reliable Access
NatProxies provides static ISP and rotating residential proxies with country, state, and city targeting for consistent data access.
Explore proxy solutions

Table of Contents

Most scraping disputes fall into one of three risk tiers, and knowing which one you're in tells you exactly what to do next.

Low risk covers logged-out pages with no personal data, no copyrighted media reuse, and light request volume. Examples: pulling public product prices, scraping job postings, or aggregating publicly listed business hours. The move here is simple: document your access method, respect robots.txt where practical, and proceed.

Three-tier web scraping legal risk chart

Medium risk shows up when you're collecting personal data (names, emails, social profiles), scraping behind a free account login, or pulling content at a volume that could strain a server. Examples: scraping LinkedIn-style profile pages, aggregating user reviews with usernames attached, or building a dataset from a site that requires free registration. Here, the operational next step is to restrict scope, run a documented legitimate-interest or fair-use assessment, and audit your logs before scaling up.

High risk means you're bypassing a paywall, CAPTCHA, or login gate; scraping biometric or health data; or ignoring a cease-and-desist. Examples: circumventing authentication to access gated profile data, or scraping facial images for identity matching. At this tier, stop and consult counsel before another request goes out.

The financial stakes at the high end are real. Enforcement actions tied to biometric scraping, such as the regulatory actions against Clearview in Europe, resulted in fines and injunctions specifically because facial-recognition data collected via scraping was treated as sensitive personal data requiring explicit safeguards, not just a legitimate-interest justification.

Pro Tip: Build a one-page risk memo for every new scraping target before you write a line of code. Ten minutes of documentation now is cheaper than a legal review after a cease-and-desist letter arrives.

U.S. Law: CFAA, Van Buren, hiQ, and the Contract Angle

The Computer Fraud and Abuse Act (CFAA) is the statute most scrapers fear, and the fear is mostly outdated. In hiQ Labs v. LinkedIn, the Ninth Circuit held that scraping publicly accessible pages, ones that require no login or password, generally does not violate the CFAA because there's no technical access control being circumvented. The court's reasoning tracks what's now called the "gates up or down" test: if the gate is up (public, no authentication needed), walking through it isn't hacking, even if the site owner objects.

The Supreme Court reinforced this narrow reading in Van Buren v. United States, holding that "exceeds authorized access" under the CFAA applies to breaching specific file or area restrictions, not to violating a website's stated policy on how you use publicly available data. That distinction changed the calculus for scraper defense strategy nationwide. A company can say "please don't scrape us" in its terms of service, but under Van Buren's logic, ignoring that request isn't automatically a federal crime unless you actually broke through a technical gate to get the data.

Where the CFAA falls short, contract law often steps in. This is where clickwrap versus browsewrap matters enormously. Clickwrap agreements, where a user actively clicks "I agree" before proceeding, are consistently enforceable in court. Browsewrap agreements, where terms are merely linked in a footer and never affirmatively accepted, face a much tougher enforceability standard, and courts frequently refuse to bind a scraper who never saw or agreed to those terms. If you scraped a site without ever creating an account or clicking through any agreement, a straightforward browsewrap breach claim is weak. If you signed up for an account and agreed to terms explicitly banning automated collection, you have real contract exposure regardless of what the CFAA says.

Trespass to chattels is the other lingering U.S. theory, rooted in cases like eBay v. Bidder's Edge, where server load became the actual harm alleged. This claim only has legs when a plaintiff can show measurable degradation, slower load times, increased infrastructure costs, or downtime traceable to your crawler. Rate-limit your requests, crawl during off-peak hours, and cache aggressively, and this risk largely disappears. Courts have consistently required proof of actual harm, not just annoyance at being scraped, as Quinn Emanuel's analysis of the legal landscape makes clear.

EU and UK Law: GDPR, EDPB Guidance, and Database Rights

Europe treats scraping far more cautiously than the U.S., and the gap between the two regimes catches a lot of American teams off guard. The General Data Protection Regulation applies to any personal data you collect, even if that data was already publicly posted by the individual themselves. Publicly available does not mean fair game under GDPR; it means you still need a lawful basis to process it.

Legitimate interest is the basis most scrapers lean on, but it isn't a rubber stamp. Regulators expect a documented balancing test weighing your business purpose against the individual's privacy expectations, and that documentation needs to exist before you start collecting, not after a complaint lands. CNIL's guidance on legitimate interest recommends excluding certain sensitive source categories by default and applying immediate anonymization or pseudonymization measures as part of that balancing exercise, not as an afterthought.

The EDPB's 2026 guidelines on web scraping for AI training go further, specifically addressing large-scale scraping feeding generative model training. The guidance calls for exclusion lists that filter out sensitive categories automatically, transparency measures explaining how data was sourced, and demonstrable safeguards proving the balancing test wasn't just theoretical. Organizations training models on scraped web content are now expected to show their work, not just claim good intentions.

Beyond privacy law, the EU's sui generis database right adds a layer the U.S. doesn't have. Under the Database Directive and CJEU precedent, a rights-holder can block extraction of a "substantial part" of a protected database even when the individual data points are unprotected facts. That means a site owner in the EU can restrict reuse through contract and database-right mechanisms even in scenarios where U.S. anti-hacking law wouldn't touch you at all. Any multi-jurisdiction scraping project should default to the stricter EU standard rather than assuming U.S. case law travels with you.

Other Jurisdictions and State Laws That Change the Calculus

U.S. federal law isn't the only American law in play. California's CCPA/CPRA gives residents rights over their personal information, and scraped data can trigger those obligations depending on how it's used. If you're aggregating scraped consumer data and monetizing it, that activity can qualify as a "sale" or "sharing" of personal information under CPRA's broad definitions, which means opt-out rights, disclosure obligations, and potential liability attach even though you never directly collected the data from the consumer.

Illinois's Biometric Information Privacy Act (BIPA) is the sharpest sector-specific risk in the country. BIPA imposes statutory damages for collecting biometric identifiers, including facial geometry, without consent, and it has produced some of the largest privacy settlements in U.S. history. Scraping any image dataset with the intent to run facial recognition on it, or reselling that dataset to someone who will, puts you squarely in BIPA's crosshairs if any Illinois resident's data is involved. Other states, including Texas and Washington, have similar biometric statutes with their own penalty structures.

Outside North America and Europe, the patchwork gets more uneven. Canada's PIPEDA requires meaningful consent for personal information collection, with fewer scraping-specific carve-outs than GDPR. Australia's Privacy Act applies similar consent-based principles and has been increasingly active in enforcement against data brokers. India's Digital Personal Data Protection Act imposes consent and purpose-limitation requirements that scraping projects routinely underestimate. China treats data localization and cross-border transfer as a national security matter, and scraping Chinese platforms or user data carries government-level risk that has no real U.S. or EU equivalent. The practical rule: never assume your home jurisdiction's tolerance for scraping travels with the data. Check the local data-protection and surveillance framework for every jurisdiction whose residents' data you're touching, before you touch it.

Raw facts are not copyrightable. A product's price, a business's phone number, a flight's departure time, none of that carries copyright protection, and scraping factual data points generally sits on safe ground. The risk climbs sharply once you cross from facts into expression: product descriptions, reviews, article text, photos, and video are all original creative works, and republishing them wholesale is a copyright problem regardless of how you obtained them.

Fair use offers some cover in the U.S. for transformative purposes, research, criticism, or analysis that doesn't substitute for the original, but it's a case-by-case defense, not a blanket exemption, and it depends heavily on how much you copied and what you did with it. Summarizing a product review in your own words is safer than storing and displaying the original text verbatim.

The EU's sui generis database right operates on a different axis entirely and doesn't care whether the underlying content is copyrighted. It protects the investment made in compiling a database, and the operative question is whether you extracted a "substantial part" of that database, measured qualitatively or quantitatively. Scraping 5% of a database's records might still count as substantial if those records represent the most valuable or resource-intensive portion of the compilation. There's no bright-line percentage that makes you safe.

The practical playbook for reducing IP risk on both fronts is consistent: transform rather than republish. Extract structured data points instead of storing full-text copies. Summarize instead of mirroring. Avoid downloading and rehosting images, video, or long-form text you don't own. If your use case genuinely requires the original expression itself, and not just the facts embedded in it, licensing or partnership is the safer path forward.

Contracts and Site Terms: When ToS Creates Real Liability

Whether a website's terms of service can bind you comes down almost entirely to how those terms were presented. A clickwrap agreement, one where you had to affirmatively click "I agree" during signup, is enforceable in the overwhelming majority of court decisions. A browsewrap agreement, buried in a footer link that nobody clicks, is far weaker, and courts routinely decline to enforce it against a party who never manifested assent. Logged-out scrapers who never created an account are in the strongest position to argue browsewrap terms never applied to them at all.

That said, even a losing CFAA claim doesn't mean you walk away clean. The hiQ litigation illustrates this precisely: hiQ won on the CFAA question, but the underlying dispute ultimately resolved through a consent judgment addressing contract-based claims, proof that breach of contract remains a viable and frequently successful theory even when the federal anti-hacking statute doesn't apply.

Before scaling any scraping project, run through a short operational audit:

  • Confirm whether your team created an account or accepted any clickwrap agreement on the target site.
  • Preserve evidence showing no affirmative assent occurred if you scraped without logging in.
  • Retain request logs, timestamps, and volume records in case you need to demonstrate good-faith, low-impact crawling later.
  • Review the current terms of service periodically, since a site can update its terms after you began scraping, and courts look at what applied at the time of collection.

If a cease-and-desist letter arrives, stop scraping that target immediately and route the letter to counsel before responding. A prompt, documented stop is one of the strongest defensive facts you can create, and ignoring a cease-and-desist converts a defensible gray-area activity into a much harder case to win.

Technical Measures: Robots.txt, CAPTCHAs, and Polite Crawling

Robots.txt is a voluntary signal, not a locked door, and in most jurisdictions ignoring it isn't itself illegal. But it carries evidentiary weight. A court weighing bad faith will notice if you scraped a site that explicitly asked crawlers to stay out of specific directories. In the EU, this matters even more concretely: under the Text and Data Mining exception in Directive 2019/790, a machine-readable opt-out like robots.txt can be treated as an effective reservation of rights, which means ignoring it can strip away an exception you'd otherwise be able to rely on.

CAPTCHAs and login gates are a different category entirely, and this is where the "gates up or down" framework from Van Buren becomes operationally important. A CAPTCHA is a gate. Bypassing it, whether through automated solving services or credential stuffing, is the single clearest way to convert a defensible public-scraping activity into a CFAA and contract violation simultaneously. The same goes for logging in with a fake or another person's account to reach gated data. Never do this. It's the fastest path from "gray area" to "named defendant."

Beyond the legal signal, technical behavior shapes how a target site perceives and responds to your traffic. Good crawling hygiene includes:

  • Identifying your crawler honestly in the user-agent string rather than spoofing a browser.
  • Rate-limiting requests to match what a human user could plausibly generate.
  • Implementing exponential backoff when you hit errors or rate limits, rather than hammering the endpoint.
  • Caching responses so you're not re-requesting unchanged data on every run.

None of these are legal requirements in every jurisdiction, but they're the difference between a scraper that never draws attention and one that ends up the subject of a server-harm claim.

Privacy and AI Training: Where the Scrutiny Is Sharpest

Scraping web content to train AI models sits at the intersection of every legal risk in this article, and regulators know it. The EDPB's 2026 guidance specifically calls out generative AI training as a use case requiring heightened safeguards, not just a standard legitimate-interest write-up.

The recommended mitigations are concrete and implementable. Exclusion lists should automatically filter out sources known to carry sensitive personal data, health forums, religious or political affiliation pages, dating profiles, before any scraping begins. Automated classifiers should flag and remove special-category data (health, biometric, sexual orientation, political opinion) from the training pipeline immediately upon capture, not at some later cleanup stage. Pseudonymization should happen as close to the point of collection as possible, and retention limits should be defined and enforced rather than left indefinite.

Illustration of filtering and pseudonymizing scraped data

Documentation matters as much as the technical controls themselves. Regulators expect a written balancing assessment showing you considered the individual's reasonable privacy expectations against your training purpose, along with provenance logging that tracks where each data point came from. This becomes essential if you later receive a data subject access request (DSAR) and need to locate and delete a specific individual's information from a training corpus, a task that's nearly impossible without that provenance trail.

There's a threshold question worth asking honestly: does this project need scraped data at all? For high-sensitivity use cases, licensed datasets with clear provenance and consent already baked in are often cheaper than the legal and engineering overhead of building a defensible scraping-and-mitigation pipeline from scratch. Teams exploring AI-driven workflows can look at how licensed and lawful data sourcing supports AI-for-SEO content pipelines as one model for balancing speed with provenance.

Practical Compliance Checklist: Pre, During, and Post-Scrape

A scraping project has three distinct compliance windows, and most legal problems trace back to skipping steps in one of them.

  1. Pre-scrape: Define scope narrowly. Review the target's terms of service and robots.txt. Identify which fields, if any, count as personal or sensitive data. Write a one-paragraph legal-basis note before the first request goes out.
  2. During scrape: Enforce rate limits and honor exclusion lists for flagged domains or data categories. Log every request with timestamps. Build an automatic stop rule that halts collection if sensitive data (health, biometric, financial) appears unexpectedly in the response.
  3. Post-scrape: Anonymize or pseudonymize personal data immediately. Set and enforce a retention schedule rather than storing indefinitely. Document the lawful basis you relied on. Have a DSAR and incident-response workflow ready before, not after, you need it.

Pro Tip: Treat your stop-on-sensitive-data rule as non-negotiable automation, not a manual review step. By the time a human notices a scraper pulled in medical records or biometric images, that data has often already been logged, cached, and copied downstream.

Representative Cases That Shaped the Law

Three matters define the current legal terrain, and each teaches a different lesson.

hiQ Labs v. LinkedIn established that scraping public, logged-out pages generally survives CFAA scrutiny, but the case's ultimate resolution through a consent judgment on contract grounds shows that winning the federal criminal-statute argument doesn't end your exposure. Contract claims can still land.

Van Buren v. United States narrowed "exceeds authorized access" to technical gates rather than policy violations, giving the entire scraping industry a clearer, more defensible line: if there's no lock to pick, there's no CFAA violation for picking it.

Meta v. Bright Data tested whether scraping public Facebook and Instagram data through a proxy-based service violated platform terms, and outcomes in that line of litigation have generally reinforced that publicly accessible data collected without credential misuse sits on firmer ground than data obtained by bypassing authentication. Meanwhile, enforcement actions against Clearview AI in multiple EU member states, driven by biometric data scraping without consent, produced significant fines and show regulators treating sensitive personal data as a bright line regardless of how "public" the source images were.

Operationalizing Lawful Scraping: Where Proxy Infrastructure Fits

None of this is legal advice, and infrastructure choices don't override the legal analysis above. But once you've cleared the legal questions, technical architecture determines whether you can actually execute a compliant scraping program at scale.

Geographic IP targeting matters for two operational reasons: it lets you verify how a site renders content in a specific region for compliance or ad-verification purposes, and it supports data-residency checks when a project requires confirming what a user in a given country or state actually sees. Rate-limited, geo-aware crawling is far easier to demonstrate as "polite" behavior when your traffic pattern mirrors real regional user distribution rather than a single IP hammering an endpoint.

Session design matters just as much as geography. Sticky sessions, where the same IP persists across a multi-step crawl, work best for workflows that need session continuity, like navigating a multi-page checkout flow for price verification. Rotating sessions, where each request gets a fresh IP, work better for high-volume, single-request data pulls where you want to distribute load naturally. Whichever you choose, integrate request logging at the proxy layer so your provenance and audit trail exists automatically rather than as an afterthought. Teams building out these systems can review a practical breakdown of proxy types for scraping tasks and how session design maps to different collection workflows.

Balancing Scraping's Utility With Privacy and Rights

The conventional advice on this topic tends to stop at "scraping public data is legal," which is true and also dangerously incomplete. The more useful framing is that scraping is a spectrum of risk, not a binary, and most teams get burned not by the act of scraping itself but by treating documentation as optional.

The regulators writing guidance in 2026 aren't trying to ban data collection. The EDPB's exclusion-list and balancing-test framework, CNIL's anonymization recommendations, they're describing what responsible collection looks like at scale, and most of it is achievable with modest engineering effort. Skipping it isn't a shortcut; it's a bet that nobody will ask you to show your work. Given how enforcement has trended around biometric and AI-training data specifically, that's an increasingly bad bet.

Transparency and audit trails aren't compliance theater. They're what lets a team defend a borderline project honestly instead of hoping it never gets noticed.

— proxy

Scaling Respectful Scraping With NatProxies

Proxy infrastructure supports the operational side of everything above: sending requests with rate limiting, geographic accuracy, and clean logging, without replacing legal review. Dedicated ISP proxies give you stable, per-IP infrastructure with unlimited bandwidth, useful when you need consistent access without triggering the kind of erratic traffic patterns that draw attention. Rotating residential proxies add country, state, and city targeting for projects that need geo-aware collection or data-residency verification across markets.

Natproxies

These proxy options support audit trails important for compliance: transparent request patterns, controllable session behavior, and geographic precision to document data collection location and method. Before scaling any project, check Natproxies's Acceptable Use Policy and review current pricing tiers to match infrastructure to your project's actual volume. If your use case sits in a gray area, reach out to the sales team for guidance on lawful-use configuration before you commit budget to a build.

This article is general information, not a substitute for advice from a qualified lawyer. Consult a qualified legal professional about your own circumstances before acting on anything here.

Sources

FAQ

Public, logged-out pages with no personal data and no copyrighted media reuse carry the lowest legal risk in most jurisdictions. Sites requiring login, containing personal or biometric data, or explicitly prohibiting scraping through a clickwrap agreement carry meaningfully higher risk.

Can web scraping be detected?

Yes. Sites commonly detect scraping through traffic pattern analysis, unusual request rates, repeated access from a single IP, and missing browser fingerprints, which is why rate limiting and geographic distribution matter for both technical stability and legal defensibility.

Is AI scraping illegal?

Scraping data specifically to train AI models isn't automatically illegal, but it faces the sharpest regulatory scrutiny of any use case, particularly under the EDPB's 2026 guidance, which requires documented balancing tests and exclusion safeguards for personal data used in training.

Can ChatGPT do web scraping?

ChatGPT and similar AI tools can generate scraping code and analyze scraped data you provide, but the legality of the underlying scraping activity depends on the same factors covered here, access method, contract terms, and data type, regardless of which tool executes the code.

Is data scraping illegal if the data is publicly posted?

Not automatically. Public availability affects but does not eliminate legal obligations, especially under GDPR, where personal data remains regulated even after an individual posts it themselves.