Security

Every render is isolated

Each screenshot runs in a browser context created for that request and destroyed with it. No cookie, localStorage entry or cached response can cross from one render to the next, whether the two belong to the same customer or to different ones.

That is asserted rather than assumed. A test suite plants a cookie and a storage entry during one render and fails if a later render can see either — and it runs against the deployed renderer, not only against a developer's machine, because the risk is specific to a warm instance serving two requests in a row.

Site Isolation is enabled, so cross-origin frames on a captured page run in separate processes. Customer-supplied JavaScript is never executed: pages run their own scripts and there is no option to inject any.

What the renderer will not fetch

Target addresses are validated before any browser starts, and again inside the renderer where DNS has been resolved and redirects can be revalidated. Private, loopback and link-local addresses are refused, so the API cannot be used to reach a service that is only reachable from inside a network.

Credentials

• Passwords are stored as an Argon2id hash. We cannot read them, and we will never ask you for one.
• API keys are stored as a keyed digest. The plaintext is shown once, at creation, and cannot be retrieved afterwards — including by us.
• Revoking a key takes effect at the edge, and a revocation that fails to reach the edge is retried until it lands rather than being forgotten.
• Dashboard sessions are HttpOnly cookies with a separate cross-site request forgery token. Sign-in attempts are rate limited per address and per account.

Data in transit and at rest

Everything is served over TLS. Service-to-service calls inside the platform are signed and timestamped, so a replayed or re-encoded request is rejected rather than trusted.

Rendering happens in Frankfurt and the database is in the European Union. See the privacy policy for the full list of processors and what each one holds.

What we log

Request logs record the hostname you asked us to capture, never the full URL — a URL commonly carries a token in its query string. Error messages returned by the API never echo a value you sent, so they are safe to log and safe to show to your own users.

Reporting a vulnerability

Email hello@urlshot.io with enough detail to reproduce the problem. We will acknowledge within three working days and tell you what we intend to do.

We will not pursue you for testing in good faith against your own account. Please do not run denial-of-service tests, do not access data belonging to anyone else, and give us a reasonable chance to fix an issue before publishing it. We do not currently run a paid bounty programme.

What we do not claim

urlshot.io is a young product. We hold no security certification, we are not SOC 2 or ISO 27001 audited, and we do not have a formal uptime guarantee. This page describes what is actually built rather than what would look best; if any of it matters for your use, ask us before you depend on it.