Home/Security

SECURITY · DESIGN, NOT DECORATION

A browser API should be difficult to trick.

A screenshot service accepts URLs and runs a real browser, which creates an unusually sharp security boundary. ogshot checks that boundary before navigation, during every browser request, and again when it handles credentials and public embeds.

Read the engineering detailReport a security concern

Network isolation

Every user-supplied URL must use HTTP or HTTPS and resolve only to public unicast addresses. Loopback, RFC1918 private networks, link-local addresses, cloud metadata endpoints, carrier-grade NAT space, multicast, reserved blocks, and IPv4-mapped IPv6 disguises are refused.

The check does not stop at the first URL. Browser-level request interception applies the same policy to redirects, scripts, images, fonts, iframes, and popups. Service workers are blocked because they create a fetch path outside normal page routing.

Keys and signed URLs

API keys are stored as SHA-256 hashes. The plaintext is returned once when a key is created and cannot be recovered from the database later. Keys can be revoked from the dashboard. Public og:image embeds should use HMAC-SHA256 signed URLs: the browser receives a public signing id and request signature, while the signing secret remains server-side.

Do not place a raw API key in public HTML. The dashboard includes a signed URL generator and the docs include the canonicalization algorithm.

Accounts and billing

GitHub OAuth requests identity information only and does not request repository access. Session cookies are signed, HTTP-only, SameSite=Lax, and marked Secure in HTTPS deployments. State cookies protect the OAuth redirect. Billing is handled by Stripe; ogshot stores customer and subscription identifiers, not card numbers.

Submitted content

URLs and HTML are processed to render an image. Output may be cached using a hash of every render-affecting option so repeated requests do not launch Chromium again. Submitted material is not used to build advertising profiles. Operational logs should be treated as potentially sensitive, so users should avoid placing secrets in query strings or rendered HTML.

Browser-facing protections

Responses include a Content Security Policy, HSTS, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, and Permissions-Policy. The CSP limits scripts and network connections to the application while allowing the font and image origins the product intentionally uses.

Current limitations

ogshot currently runs as a small independent service rather than a multi-region enterprise platform. The documented residual SSRF concern is DNS rebinding between validation and Chromium's own connection; the long-term control is a pinned egress proxy. No service can promise perfect security. Responsible reports can be sent to support@ogshot.dev with reproduction steps and without accessing data that is not yours.