Security

A screenshot service is a machine that fetches URLs on a stranger's behalf and runs their JavaScript. That makes two things dangerous by default: what the browser can reach from inside our network, and what one render can learn about another. Both are addressed below, first.

What we refuse to fetch

Server-side request forgery is the defining vulnerability of this product category. A rendering API without these checks is an authenticated proxy into its operator's private network, available to anyone with an account.

• Private, loopback, link-local, multicast and reserved address ranges are refused, in both IPv4 and IPv6.
• Cloud metadata endpoints are refused explicitly, including the IPv6 form.
• Hostnames are resolved and the resolved address is checked — a public name pointing at a private address does not get through.
• Redirects are re-checked at every hop, so a public URL that redirects inward is refused at the redirect.
• Only http and https are accepted. No file:, no gopher:, no data:.

Isolation between renders

• Every capture runs in its own browser context, created for the render and destroyed after it. Cookies, storage, cache and service workers do not survive it.
• Workers are sandboxed containers, one emoji set each, with no credentials for the application beyond a single-purpose worker token.
• A render cannot read another render's output: images are addressed by ULID and every read is authorised against the owning team.

Credentials

• API tokens are generated with a cryptographically secure source, shown exactly once, and stored only as a hash. We cannot recover one; you revoke and reissue.
• Token restrictions. A token can be limited to a set of target domains and to a set of caller IP addresses, so a token leaked from CI is useless from anywhere else and against anything else.
• Revocation is immediate and keeps the token's history, so you can still see what it did.
• Passwords are hashed with bcrypt. Resets are single-use, time-limited, and invalidate the session token.

Where data lives

• Application, database and object storage are hosted in the EU. The full list of providers is on the subprocessors page.
• TLS in transit everywhere, including to the database and cache.
• Images you asked us to keep are in encrypted object storage and served through short-lived signed URLs, never from a public bucket.
• A render you did not ask us to keep is never durably stored; its file exists only to carry bytes out of the worker and is deleted on collection.
• Retention windows are enforced nightly by a scheduler — see the retention table.

Application security

• Sessions are cookie-based, HTTP-only, SameSite-restricted and regenerated on sign-in, on password reset and on privilege change. CSRF tokens on every state-changing form.
• Rate limits on sign-in keyed by email and address, so neither a household nor an individual can be locked out by somebody else's attempts.
• Every API failure carries a stable machine-readable code. Errors do not leak stack traces, internal hostnames or the existence of other accounts.
• Sign-in and password-reset flows do not reveal whether an email address has an account.
• Dependencies are pinned; the browser version is pinned and stamped on every response, so an upgrade is deliberate and visible.

Operations

• Infrastructure access is limited to the people who operate the fleet, over SSH keys, with no shared accounts.
• Errors go to a monitored error tracker; the fleet reports its own health, and a set going dark raises an alert rather than waiting for a customer to notice.
• The database is a managed instance with the provider's automated backups and point-in-time recovery.

What we do not have yet

Stated plainly, because a security page that only lists strengths is not one a professional trusts:

• No SOC 2 or ISO 27001 certification. We will say so rather than imply otherwise.
• No third-party penetration test yet. It is scheduled ahead of the first enterprise contract.
• No SSO, SCIM or audit-log export. These arrive with the team-seats work.
• Backups are the provider's automated ones, and we have not yet rehearsed a full restore against them. Until we have, treat it as untested — because it is.
• No formal bug bounty — but see the disclosure section: we do not treat reports as an inconvenience.

Reporting a vulnerability

Email security@webshotter.com. Include what you found, how to reproduce it, and what you think the impact is. We aim to acknowledge within two working days and to tell you what we are doing within five.

• Test against your own account and your own data only.
• Do not run automated scanners against the API — you will find our rate limiter, not a vulnerability.
• Do not access, modify or exfiltrate anyone else's data. If you can, stop and tell us that you can.
• Give us reasonable time to fix it before publishing.

Research conducted within those limits is welcome, and we will not pursue legal action over it. We credit reporters who want to be credited.

Abuse, rather than a vulnerability

If one of our customers is pointing the service at your site, the report page is the faster route — abuse@webshotter.com.