Security

Capture happens in your user’s browser. We do not run a fleet of headless browsers that log into your application to take screenshots — which means we hold no credentials of yours, and there is no server here that could be compromised into browsing your product as one of your customers.

The same decision is why redaction is trustworthy: blurred and excluded regions are destroyed during the render, before encoding, so the original pixels never leave the browser. Redaction that happened on our servers would mean we had received the unredacted version first.

• TLS everywhere. HSTS on our domains.
• Encryption at rest for the database and the storage bucket.
• Files live in a private bucket. There is no public read path — every download goes through a signed URL that expires, and never later than the object it points at: the capture’s own retention window for captures, 24 hours for files opened through the File API.
• Captures are deleted from storage after three days by default, and seven at the outside. Seven is the ceiling for every account — a project can choose less, no plan buys more.
• Signed URLs are unguessable but unauthenticated. Treat one like a password: anyone you forward it to can open the file until it expires.

Every table carries row-level security tied to organisation membership, so one organisation cannot read another’s rows even if the application code above it has a bug. The service-role key that bypasses RLS is used only by server routes that have already authenticated an API key, and is never present in a browser bundle.

• Publishable keys (pk_) ship in your frontend and are stored in the clear, because we look them up on every request. They are not the security boundary — the origin allowlist is. A live key is refused from an origin you have not listed.
• Secret keys (sk_) are stored only as a SHA-256 hash, shown exactly once at creation, and compared in constant time. If you lose one, you rotate it; we cannot recover it.
• Webhook payloads are signed with HMAC-SHA256 over a timestamped body, so your endpoint can detect both tampering and replay. Verify the signature.
• Passwords are handled by Supabase Auth and never reach our own code in a form we could store. Reset codes are six digits, stored hashed, expire in 15 minutes and die after five wrong guesses.

• Rate limits on signup, sign-in, password reset and invitations, counted in the database so they hold across instances rather than per-process.
• SSRF protection on any URL we fetch: private and link-local addresses are refused, so a capture request cannot be pointed at cloud metadata.
• CSV exports escape formula-injection prefixes, so a spreadsheet opening one cannot be made to execute a cell.
• The editor and the auto-attach overlay run inside a shadow root, so your styles cannot break them and they cannot leak into your page.
• Error reports are scrubbed before they leave the process — API keys, JWTs, cookies, webhook signatures and signed URLs are redacted, PII collection is off, and session replay is disabled.

This is a young product and it would be dishonest to imply otherwise. As of the date above:

• No SOC 2 or ISO 27001. No audit is in progress.
• No third-party penetration test yet.
• No bug bounty programme — but see the disclosure section below, and we will thank you publicly if you want that.
• No SAML or SCIM. Sign-in is password or email link; there is no enterprise SSO.
• No customer-managed encryption keys, and no region selection: storage is in the EU (eu-west-1) for everyone.
• No formal uptime SLA outside a negotiated agreement.

If one of these is a blocker for you, say so — knowing which of them people actually need is how they get prioritised.

Email security@screen2api.com. Include enough detail to reproduce it. We aim to acknowledge within two working days and to tell you our assessment and a rough timeline within a week.

We will not take legal action over research done in good faith: testing only against your own account and data, no attempt to reach another customer’s captures, no degradation of the service, and no disclosure until a fix is out or 90 days have passed. Please do not run automated scanners against production — they cost us availability without finding anything a careful look would not.

Sub-processors · Data processing addendum · Privacy policy