Security

Security Compliance

An overview of ScreenNabster security controls, subprocessors’ trust documentation, responsible disclosure, and current compliance posture (non-certification).

Last updated: May 17, 2026

Account and data protection

Authentication is handled through Supabase; password policies and storage follow the identity provider.

Application data paths use Row Level Security, narrowly scoped privileges, deliberate use of privileged service roles where required, and database migrations hardened for privileged routines.

API and abuse controls

API traffic is keyed, metered, and rate limited. SSRF defenses aim to restrict private IPs, unsafe redirects, metadata endpoints, and similar fetch risks inherent to screenshot services.

Server-side prohibited-use controls may include blocked domains and URL patterns, account restrictions, logged abuse findings, and optional reputation checks.

Injected CSS and JavaScript (`inject_css` / `inject_js`)

When you supply `inject_css` or `inject_js`, that code runs in the same browser context as the page being rendered (not in an isolated JavaScript sandbox). You should treat injected snippets as trusted code.

To reduce cross-site and SSRF-style abuse from scripts that trigger new network requests, our rendering workers install request interception for captures that use a URL target or non-empty inject parameters. HTTP(S) requests from the page are checked against the same **public URL** policy used for the main capture (private IPs, metadata hosts, and similar targets are blocked where the check applies).

This does **not** provide a full VM-style sandbox: malicious or inefficient scripts can still affect CPU, memory, or the DOM inside the ephemeral browser session for that job. We additionally enforce plan tiers, request-size limits, and abuse controls (including optional restrictions on inject features for high-risk accounts).

Application and worker posture

HTTP security headers apply by default. Rendering workers run with tightened browser posture; secrets arrive only through environment or hosted secret stores—not source control.

Logging and investigations

We use logs and metadata for incident response, reliability, quota enforcement, and abuse workflows. Sensitive values must not appear in logs deliberately; rotate leaked credentials immediately.

Report vulnerabilities

Please report suspected security bugs responsibly; see our Responsible Disclosure page for scope and expectations. Operational questions stay on support.