/security
Security by design.
Last updated: August 25, 2026. ZANCTA is built with security at every layer — and without theatre. This page does not claim a certification, audit, penetration test, or compliance program that has not been independently verified.
Local processing boundary
Supported local tools process selected file bytes in the browser and do not upload those bytes to ZANCTA for processing. This reduces the need to transmit routine documents and images, but it is not a formal certification or a guarantee about unrelated software on a device.
Transport and browser protections
The deployed application uses HTTPS and security headers including Content Security Policy, frame protection, content-type protection, referrer policy, permissions policy, and HSTS in production. CSP restricts script, connection, and worker origins to support local browser processing.
Accounts and secrets
Authentication uses credential handling, password hashing, session controls, verification and reset tokens, and authenticated account actions. Paid checkout requires a verified email. Sensitive provider configuration is intended to remain server-side rather than in browser code.
Payments and abuse controls
Payment notifications are verified before account access is updated, and sensitive actions are rate limited. Checkout and billing are handled by the payment service shown during purchase.
Errors and data handling
Tool failures are designed to return honest error states rather than fabricated output. Local file content is not logged by the local tool workflows. Account deletion is available through the authenticated account experience where supported.
Reporting
Report security issues to security@zancta.tech. Do not send passwords, session tokens, private files, or payment information by email. There is no published bounty and no promised response SLA. See Contact.
Next steps