Security at Remove Zero

Security applies across accounts, image requests, result delivery, and infrastructure. No security program eliminates every risk, so controls are monitored and improved as the service changes.

An independent audit, certification, or service-level commitment applies only when Remove Zero publishes it in writing.

• Single-image processing and account access fail closed when their live service is unavailable.
• Internal service secrets are never placed in browser bundles, URLs, analytics events, or ordinary logs.
• Customer uploads must never be replaced with an unrelated example result.

The static site submits bounded image data through a protected Remove Zero service. GPU provider credentials remain internal and are never exposed to the browser.

The static site, authentication provider, abuse-control Worker, and inference workers use separate trust boundaries and scoped credentials.

• Use a dedicated authentication provider rather than storing passwords in the static site.
• Verify the current session before showing the protected account page.
• Allow the user to end the current-device session immediately.
• Rate-limit authentication and image processing independently.
• Never place passwords or privileged authentication keys in browser code or ordinary logs.

• Validate URL scheme, content type, decoded dimensions, size, and redirect behavior before processing.
• Protect fetchers from private-network and metadata-service access.
• Return results only to the request that created them and avoid public persistent result storage.
• Do not use customer images for general model training by default; verify the same restriction with every provider.
• Do not make customer source images or results public to other users.

The free tool validates content type, file size, decoded dimensions, and image format before processing.

Human verification, per-IP limits, bounded polling, exact-origin CORS, and sanitized upstream errors reduce automated abuse and accidental data exposure.

• Bound retries and queue depth so provider failure does not create a retry storm.
• Use per-IP and global limits, anomaly detection, and emergency service controls.
• A secondary compute path is enabled only after the same model and result contract are verified.
• Monitor success rate, latency, queue age, provider errors, and request failures.
• Maintain tested recovery, incident, and provider-failover procedures.

Report suspected vulnerabilities through a contact method published by Remove Zero without including live credentials or sensitive customer images. Written authorization is required before security testing.

Incident handling preserves evidence, contains access, assesses affected data and customers, meets applicable notice duties, communicates verified facts, and records corrective actions.