Request security: one isolated browser per request
Every API call gets its own incognito browser context — created for that request, destroyed when it finishes. No cookies, caches, or profiles are ever shared between requests, and every URL is screened against reserved IP ranges before and during rendering, so a request can never reach a private network.
A cloud browser is a security boundary
When you send a URL to a browser API, that page runs real JavaScript inside a real Chromium on someone else’s infrastructure. It can redirect, load subresources, open WebSockets — everything any web page can do. Which makes every request a set of questions worth asking about what that page can reach:
Microlink’s answer is structural: the blast radius of a request is the request itself. Isolation and network screening are enforced inside the rendering engine on every request — not by policy, not by plan tier.
Request isolation by construction
Isolation is not a setting you enable — it is how the engine allocates browsers. Every request gets a context that exists only for that request, and the engine tears it down the moment the request ends, whichever way it ends.
SSRF protection at two layers
Checking the input URL once is not enough — a page can redirect or load resources into places its URL never mentioned. Microlink validates the destination before the fetch and keeps validating while the page renders.
Sandboxed execution with hard ceilings
The function parameter runs your JavaScript against the live page — inside a VM with an execution timeout and a memory ceiling. On the free plan, code size is capped and cross-origin fetch, xhr, and websocket calls are blocked, so anonymous code cannot use the platform as an egress proxy.
The same discipline applies to every request, code or no code: hard time limits and concurrency caps mean one heavy render can never starve another customer’s traffic, and anonymous traffic is rate-limited per client IP.
Your secrets stay secret
Credentials never reach the logs. x-api-key and authorization values are redacted before anything is written, and every forwarded x-api-header-* secret is masked the same way.
Cached responses cannot cross credential boundaries either: cache keys are SHA-512 hashes that incorporate the headers a request was made with, so a page fetched with your session cookie is never served to a request without it. Cache lifetime is under your control, from 1 minute to 31 days.
On the way out, every request carries sec-gpc: 1 and dnt: 1, forwarding Global Privacy Control and Do-Not-Track signals to the sites being rendered. For the compliance side — GDPR, data processing, subprocessors — see our security practices, DPA, and privacy policy.
Enterprise: isolation down to the hardware
Everything above is the default on the public API. Microlink Enterprise moves the boundary one level down: your own API endpoint running on hardware that serves only you, backed by a dedicated pool of always-ready browsers. No shared capacity, no noisy neighbors — and you choose which of 8 locations the hardware lives in.
The data terms are just as explicit: your content is never used to train or fine-tune AI models, you own what you process, and we delete it within 60 days of your request — all backed by a GDPR-compliant Data Processing Agreement ready for your legal team.
Isolated by default, dedicated when you need it.
Every plan runs on the same isolation model — one incognito browser per request, SSRF screening on every URL. When your compliance team needs physical separation, Enterprise puts the whole API on your own hardware. Read our security practices for the full picture.
Does every request really get its own browser?
How does Microlink prevent SSRF?
Are cookies, cache, or sessions shared between requests?
What limits apply to user-supplied code?
fetch, xhr, and websocket calls are blocked.