Quick links

Security at Zona

How to report a vulnerability responsibly, and how Zona protects the alerts your scripts, servers and agents send.

Report a vulnerability

Send reports privately by email, and test only against accounts, sources and data you own.

Contact

Email a report
Address
terabasedevteam@gmail.com
Response owner
Terabase Team (Ho Yu Lee)
Acknowledgment target
2 business days

What to include

  • A concise description and its impact
  • The affected build or function
  • Reproduction steps
  • Timestamps or request IDs, when available

Never include live source tokens, Supabase sessions or keys, push tokens, or real notification content. The maintainer will arrange a safe channel for sensitive evidence.

Scope

The latest approved build and its matching deployed backend: database schema and Edge Functions, including the sender API.

Do not test against

  • Accounts, sources or data you do not own
  • Denial of service
  • Social engineering
  • Provider-account access
  • Privacy-impacting testing

How Zona protects your alerts

No service is perfectly secure. These are the controls Zona actually uses, and the policy below says where their limits are.

Alert content passes through Supabase, Expo and Apple or Google push services and can appear on a lock screen. Never put secrets in an alert. Read the Privacy Policy.

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 (Ho Yu Lee)
  • 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 (seven days on the standard plan); per-source ingest request rows expire after one day and account rate events after two days.
  • 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;
  • 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.