For the complete documentation index, see llms.txt. Prefer markdown by appending .md to documentation URLs or sending Accept: text/markdown.

Overview

Treat the device as untrusted: keep secrets on the API, harden deep links, and never grant access from client-only checks.

The mobile app is a client. It talks to the same Hono API and Better Auth stack as web - it should never become a second source of truth for secrets, entitlements, or tenant access.

This section is a security playbook - what must stay off-device, how auth deep links stay safe, and what to double-check before you ship to the stores.

Be mindful

Security is not a one-time setup. Revisit these practices whenever you add screens, deep links, billing providers, or native modules that touch sensitive data.

Security model

Defense on mobile is client-focused. The API still owns authorization:

LayerWhat it protectsWhere it lives
No secrets on deviceAPI keys and webhook secrets never ship in the binaryServer env / web deployment
Public env onlyEXPO_PUBLIC_* values are readable by anyone with the appapps/mobile + EAS
Trusted deep linksAuth redirects only from your app schemeBetter Auth trustedOrigins
Session + APIMutations require a valid session on protected routesAuth client → Hono enforceAuth
EntitlementsPurchases are confirmed by provider webhooks, not UI callbacks@workspace/billing-mobile + API

Server-side rules (middleware, Zod validation, webhook signatures, package ./server entry points) are documented in Web security. Use that section whenever you change the API.

Each of these topics is covered in more detail in the following guides:

How is this guide?

Last updated on

On this page

Ship your startup everywhere. In minutes.Try TurboStarter