Security at Zona

Zona is currently a private TestFlight and Android preview project. The existence of this policy does not mean the service has completed its public release security gates. See the threat model and test plan.

Supported versions

Only the latest explicitly approved TestFlight build and its matching deployed Supabase schema/Edge Functions are supported. Version 1 is pinned to Expo SDK 57. Older builds should be removed from tester access after a replacement is verified.

Reporting a vulnerability

• Security email: terabasedevteam@gmail.com
• Response owner: Terabase Team
• Acknowledgment target: 2 business days; urgent credential/data incidents are acknowledged according to the production incident policy.

Include a concise description, affected build/function, reproduction steps, impact, and timestamps/request IDs when available. Do not include live source tokens, Supabase sessions/keys, push tokens, or real notification content. The maintainer will coordinate a safe channel for sensitive evidence.

Do not test against accounts, sources, or data you do not own. Avoid denial of service, social engineering, provider-account access, or privacy-impacting testing.

Security model

• Authorization is enforced by Supabase Auth, row-level security, and authenticated Edge Functions.
• Senders receive a separate opaque credential per source. The backend stores only its SHA-256 hash and derives source/owner identity from it.
• Sender applications call only the bounded notification Edge Function; they do not receive database or service-role access.
• Notifications are inserted before durable push jobs are sent. Transient provider failures receive bounded retries; inbox acceptance never implies a banner was displayed.
• Source credentials are independently and immediately revocable.
• Notifications and associated push-delivery diagnostics expire after the plan-resolved retention period of the plan they arrived on, or the longer period of any plan the account had while they were in the inbox (one day for guests, seven days on the standard plan, thirty days on Zona Plus; a downgrade never shortens it), except an alert the owner pinned in the app, which is kept until it is unpinned or its pin expiry passes, up to a per-plan number of pinned alerts; per-source ingest request rows expire after one day and account rate events after two days. Revoked sources are removed 30 days after revocation once no alert refers to them, disabled push registrations after seven days, raw diagnostic logs after 30 days, and account security events after one year. The full schedule, including what account deletion keeps, is in the privacy policy.
• On iOS 17 or later, a running Live Status card acts in place with a scoped Live Activity action key kept in the App Group, never a session token. The key can only mark read, pin, unpin or delete its owner’s alerts, is stored server-side only as a SHA-256 hash, expires after 12 hours, is bound to the sign-in session that minted it, and is revoked when the card ends, on sign-out, or when another account signs in (ADR 0013, threat T-39).
• Future PC control is out of scope. Arbitrary remote shell execution is prohibited.

Credential handling

Never commit, paste, log, screenshot, or transmit through notification metadata:

• Supabase secret/service-role keys;
• source zona_live_… tokens;
• user access/refresh tokens;
• Live Activity action keys (zona_la_…) from the iOS App Group;
• Expo/Apple administrative credentials;
• production push tokens unless required in a restricted provider workflow.

Source tokens should be stored in an OS-backed secret store. On suspected source exposure, revoke that source, create and verify a replacement, and investigate the leak. On Supabase secret exposure, follow the immediate rotation and audit procedure in RUNBOOK.md. Deleting a message or commit containing a credential does not make the credential safe again.

Dependency and change policy

• Use lockfile installs in CI and review dependency diffs.
• Run dependency, secret, static, Expo compatibility, Deno, database/RLS, and produced-bundle scans for every release.
• No critical/high finding may ship. A moderate exception needs documented impact, mitigation, owner, approval, and expiry.
• Keep Expo and React Native on the SDK 57-compatible versions verified by Expo Doctor. Resolve or explicitly assess transitive advisories against the supported SDK.
• Authentication, RLS/grants, secret access, security-definer functions, retention, and push payload changes require security-owner review.
• Production dashboard edits must be reconciled into version-controlled config and deployed source.

Privacy and incident response

Notification content is processed by Supabase, Expo Push Service, and Apple APNs or Google FCM and may appear on a phone lock screen. Do not use Zona for secrets or regulated/sensitive data without an approved privacy/security assessment.

Security incidents follow RUNBOOK.md: contain and rotate credentials, preserve minimal evidence, determine access and data impact, restore verified service, communicate as required, and complete a post-incident review. Account deletion and the published privacy notice are release gates.