Security

Last updated: September 14, 2026

dbOrbit was built around one constraint: for the databases it connects to directly, your credentials and the data inside your databases should never reach our servers. This page says exactly which layer protects what, what is still in development, and how to report a vulnerability.

1. Security Posture

dbOrbit is a local-first mobile database client. Credentials, SSH keys, saved queries and query history live on your device in the iOS Keychain or Android Keystore. For PostgreSQL, MySQL, MariaDB, their compatible cloud engines, self-hosted MongoDB and local SQLite, the app opens a socket straight from your phone to your database — we do not proxy that traffic and never see your queries. There is no dbOrbit account and no password on our servers to recover.

Two engines are the exception: MongoDB Atlas and dbOrbit-hosted SQLite, both coming soon, pass through our proxy because they need DNS SRV lookups or server-side storage.

2. Local-First Architecture

The trust boundaries:

• On the device: credentials, SSH keys, PIN hash, saved queries, query history and results, schema cache
• Platform keystore: credentials, SSH keys, saved queries, history, PIN hash and recovery email are stored in the iOS Keychain or Android Keystore
• Leaves the device when you use a feature: encrypted GitHub backup, recovery-email delivery, MongoDB Atlas and dbOrbit-hosted SQLite traffic
• Always sent: scrubbed analytics and crash reports (see Section 6 and the Privacy Policy)

Keys and PIN

1. On first launch, the app generates a 256-bit data-encryption key (DEK) and stores it in the iOS Keychain or Android Keystore.
2. The DEK is reserved for the SQLCipher-encrypted local store, which is in development. It does not encrypt anything yet.
3. The PIN gates app unlock, not encryption. It is stored as a PBKDF2-SHA256 hash with a per-install salt and 100,000 iterations.
4. Biometric unlock (Face ID, Touch ID, fingerprint) is the primary unlock method, with the PIN as the fallback.

3. Data at Rest

• iOS Keychain / Android Keystore — connections (including passwords and SSH keys), saved queries, query history, the PIN hash, recovery email and the DEK. Protected by the Secure Enclave or the device’s trusted execution environment where available.
• App storage — the schema cache (table and column names) is written as files in the app’s private storage, and app settings are kept in local storage. These rely on the operating system’s sandbox and device encryption, not on an app-level key.
• SQLCipher (in development) — a second encryption layer for the local store. Until it ships we do not claim it.
• GitHub backup (optional) — the backup is encrypted on the device with AES-256-GCM, using a key derived from your PIN with PBKDF2-SHA256 (100,000 iterations) and a random salt stored alongside it. We never receive a plaintext copy. Because the PIN is four digits, the backup is only as private as the repository: keep it private.

4. Data in Transit

• Database connections — direct TCP from the device, with TLS when enabled for the connection. react-native-tcp-socket provides the net and tls bindings used by pg, mysql2 and the MongoDB driver.
• SSH tunneling — SSHv2 (ssh2) over the same socket layer, with cryptography from react-native-quick-crypto. Available for PostgreSQL and MySQL-family engines.
• Proxy-backed engines — MongoDB Atlas and dbOrbit-hosted SQLite connect to proxy.dborbit.io over HTTPS, and the proxy connects onward to the database.
• API traffic — recovery-email delivery, GitHub sign-in and hosted-database requests use HTTPS.
• App distribution — App Store / Play Store transport is signed and encrypted by the platform.

5. Authentication & Access

• App lock — biometric primary, PIN fallback.
• Auto-lock — when app lock is on, the app locks after a configurable period of inactivity or time in the background: never, 30 seconds, 1 minute (default) or 5 minutes.
• Recovery email — optional, used only to reset a forgotten PIN. The address is stored on the device; each code is sent through our email service and ZeptoMail.
• One-time codes — generated and checked on the device, valid for 10 minutes and single-use.
• Temporary PIN — with a verified recovery email, you can request a one-time temporary unlock code if you forget your PIN. Disabled if no recovery email is set.
• Erase all local data — Settings → Security → Erase all local data wipes everything held in the Keychain or Keystore. Some app settings remain until the app is uninstalled. To have data on our servers deleted too, see Delete your data.
• Read-only mode — blocks writes on one connection, or on every connection from Settings. The per-connection toggle is not yet enforced for local SQLite files; the app-wide setting is.
• No cloud account — there is no email/password login. The app cannot be unlocked remotely or by us.

6. What We Don’t Store

For directly connected databases, the following are never transmitted to or stored on dbOrbit’s servers:

• Database passwords, SSH private keys, or any connection credentials
• SQL query content, query results, execution plans, query parameters
• Data stored in or retrieved from your databases
• Your app PIN or biometric data
• Keystroke logs, clipboard contents, screen recordings

Analytics events pass through an on-device scrubber before they are sent. It removes fields that could hold sensitive values, reduces SQL to its leading keyword, and masks email addresses, IPv4 addresses and connection URLs. It does not remove bare hostnames or object names, so an error message such as a failed connection can still include a database hostname. Analytics and crash reporting cannot currently be turned off in the app.

7. SOC 2 Readiness

We follow controls aligned with the SOC 2 Trust Services Criteria (Security, Availability, Confidentiality, Processing Integrity, Privacy) appropriate for our scale. Specifically:

• Principle of least privilege for all internal systems; access is reviewed quarterly
• Centralized audit logging on backend services with 12-month retention
• Mandatory two-factor authentication on all production access
• Vendor security review for all subprocessors before onboarding
• Incident response runbook with severity levels, communication templates, and a post-incident review process
• Annual penetration test of internet-facing infrastructure

A formal SOC 2 Type II audit is on our roadmap. Current and prospective enterprise customers may request a copy of our security questionnaire (e.g. CAIQ, SIG Lite) by emailing security@dborbit.io.

8. CCATS / Export Compliance

dbOrbit uses standard cryptographic primitives — TLS and SSHv2 for connections, AES-256-GCM for GitHub backup, PBKDF2-SHA256 for PIN hashing, and the platform keystore for secrets. We have self-classified the App under U.S. Export Administration Regulations §740.17(b)(1) as eligible for the encryption-export exemption on the basis that:

• The cryptographic functionality is ancillary to the App’s primary purpose, which is database client tooling
• The cryptographic primitives are publicly available and standard (AES-256, PBKDF2, TLS, SSHv2)
• The App does not provide cryptographic functionality as a service to third parties

We file the annual self-classification report with the U.S. Bureau of Industry and Security as required. The corresponding ITSAppUsesNonExemptEncryption declaration in the iOS application bundle is set to false consistent with this classification.

9. Vulnerability Disclosure

Security researchers are encouraged to report issues responsibly. We commit to a good-faith response and treat researchers as collaborators, not adversaries.

How to report

• Email: security@dborbit.io
• Subject line: "Vulnerability report — [short description]"
• PGP: available on request
• Please include: a description of the issue, steps to reproduce, affected versions, and your assessment of impact. If you have a proof of concept, attach it.

Response targets

• Acknowledgement: within 3 business days
• Initial triage: within 7 business days
• Critical-severity fix or mitigation: within 14 calendar days
• Coordinated disclosure: we ask for at least 90 days before public disclosure of unfixed issues; we’ll usually be much faster

Scope

• The dbOrbit iOS and Android applications (current production version)
• The dborbit.io marketing site
• API endpoints under api.dborbit.io and proxy.dborbit.io

Out of scope

• Issues affecting third-party services we use (Mixpanel, Sentry, RevenueCat, ZeptoMail, GitHub) — please report those to the relevant vendor
• Self-XSS or social-engineering attacks against our staff
• Reports requiring physical access to a victim’s unlocked device
• Denial-of-service via volumetric traffic

Safe harbor

Activities conducted in good faith in accordance with this policy will not be subject to legal action by us. We will not pursue or support pursuit of civil or criminal action against researchers who comply with the scope and reporting guidelines above. If a third party initiates legal action against you for activities conducted in good faith under this policy, we will make our authorization known.

10. Recent Security Updates

A rolling log of security-relevant changes will be maintained in this section. Patch-level updates that fix non-security bugs are tracked in our standard release notes and not duplicated here.

• September 14, 2026 — Corrected this page. SQLCipher encryption of the local store was described as shipped; it is in development, and credentials are protected by the platform keystore today. Added the proxy-backed engines, the limits of the analytics scrubber, and the four-digit PIN behind GitHub backup encryption.
• May 1, 2026 — Initial publication of this page.

Contact

For security questions or to report a vulnerability: security@dborbit.io.

For general product or privacy questions: support@dborbit.io.