The authenticated scraping guide nobody wants you to read
If you need data from a page you are logged into, there are only two safe options. Most operators pick the unsafe one and regret it. Here is how to do it right.
The two options
Option 1: upload your session cookie to a cloud scraper. Fast to set up, dangerous to run. Your session now lives on a server in someone else's datacenter, and every scrape comes from their IP. This is how PhantomBuster, Evaboot, Dripify, and Waalaxy all work.
Option 2: scrape from the same browser you logged in with. Slower to build because you need a real browser automation stack. But there is no cookie to upload, no datacenter IP mismatch, and the target site sees your normal session.
Why option 2 is now viable
Browser extensions used to be too limited for real scraping. In 2023 MV3 landed with scripting APIs powerful enough to automate the DOM from inside the extension context. In 2025, declarativeNetRequest added the last missing piece for safe request interception.
Stekpad was built on MV3 from day one. The extension runs scripts in the page context with your session, extracts structured data, and sends it to your configured destination — all without a cloud hop.
When option 1 still makes sense
Hosted scrapers are not always wrong. If you need 24/7 automation on 10,000 LinkedIn profiles per day, you cannot keep Chrome open that long. PhantomBuster has a legitimate place for heavy-volume teams willing to accept the restriction risk.
For everyone else — the 95% who do 100-500 actions per day — running locally from your own browser is strictly safer and cheaper.
Related on Stekpad
More in this cluster
How to Scrape LinkedIn Safely in 2026
Two-part post: (1) legal landscape — what hiQ v. LinkedIn established about public profile scraping, what LinkedIn's ToS says about automated access, and the practical risk level for typical use cases (sales prospecting, research); (2) technical how-to — using Stekpad's browser-native scraper to pull LinkedIn data without exposing credentials to a third-party server, rate-limiting best practices, and what fields are safe to extract. Positions running in your own browser session as the lowest-risk approach.
Why Stekpad Runs in Your Browser, Not on a Server
**Use the contrarian voice from `docs/brand-voice.md`.** Make a direct argument: every cloud scraper — Apify, browse.ai, PhantomBuster — routes your session through their infrastructure. Name the specific risk: if their server is breached, or their employee is compromised, your cookies are exposed. Back this with specifics: PhantomBuster's cookie-based phantom model, browse.ai's credential storage for authenticated robots. Then argue for the browser-native model on three grounds: (1) your session never leaves your machine, (2) it works on any site you can open, including internal tools with no public URL, (3) it runs faster because there's no round-trip to a remote proxy. Close with what this means for privacy-conscious teams and regulated environments.
Authenticated Scraping: Scrape Pages You're Logged Into
Explains how Stekpad handles authenticated pages by running in the user's active browser session — no credential storage, no cookie forwarding to a remote server. Covers: supported sites (LinkedIn, Salesforce, internal tools, paywalled sites), limitations (CAPTCHA flows, 2FA mid-session), and best practices for stable authenticated scraping. Differentiates clearly from cloud scrapers that require credential sharing.
Authenticated scraping — your session, your browser, your data
Stekpad runs inside your browser and uses your existing login session to scrape authenticated pages, so your credentials never leave your machine — unlike hosted scrapers that require you to share cookies with a third-party server.