Security considerations

Connecting any tool to a production Firebase project deserves scrutiny. This page explains Firedeck’s security model in plain terms.

Fully client-side

Firedeck is a client-side Firebase console that acts strictly as the signed-in Google user. There is no backend, no proxy, no token vault, and no Firebase Admin SDK. Every API call goes directly from your device to Google’s first-party APIs.

What this means in practice

• No backend. Firedeck does not run a server, Cloud Function, or relay. There is no Firedeck-owned host in the request path.
• No data proxying. Responses are read and rendered on your device. Your Firebase data is never sent to a Firedeck endpoint.
• No server-side token storage. Tokens never leave your device. The active account’s tokens live inside Google’s sign-in SDK; refresh tokens for additional accounts are stored in the iOS Keychain. Access tokens are never written to disk, and nothing is ever sent to a Firedeck server — there isn’t one.
• No Admin SDK. Firedeck does not use service-account keys and never impersonates a service account.
• User-scoped. You see and can change exactly what your own Google account’s IAM permissions allow — nothing more.

Verify it yourself

Don’t take our word for any of this — the network behavior is observable. Run Firedeck through an HTTP proxy such as mitmproxy or Charles Proxy and watch the traffic: every request goes to Google’s first-party domains (*.googleapis.com, firebaseio.com, and Google’s sign-in endpoints). There is no Firedeck-owned host in the request graph, because there is no Firedeck server.

Safe by default

Destructive actions — deleting a document, removing a file — require an explicit confirmation. Write access is gated behind both your granted OAuth scopes and Firedeck Pro, so read-only use stays read-only.