Security
Security by architecture, not by promise.
Every guarantee on this page comes from how BridgeStick is built: what each part can reach, what it keeps, and what it never sees.
Tenant isolation
Every user is a tenant with a space of their own.
- Every query, realtime event and data-API key keeps to its tenant: a user sees, changes and is told of nothing of anyone else's.
- Files a tenant uses on the server (a SQLite source or destination) live in a folder of its own; a path elsewhere is refused.
- One writer per table: a connection that would write a table another connection writes is refused — without naming the other.
- The platform administrator manages accounts and engine settings, never a tenant's data.
Secrets encrypted at rest
Credentials of sources and destinations are encrypted before they are stored.
- Fernet: AES-128-CBC with an HMAC-SHA256 tag, the key derived with HKDF-SHA256.
- Never returned by the API, and scrubbed from the logs.
- Sent to an agent over TLS only when a connector opens, and kept in its memory only.
Data API keys
Your applications read data with keys built to be lost safely.
- Stored as SHA-256 hashes, shown once, scoped to the sources you choose, expiring and revocable, with last use tracked.
- Rate-limited per key (
429withRetry-After); a source is readable only when you enable it. - A key holder learns a source's name, type and health — never its host, its user or an error that names the network behind it.
Signed agent identity
An agent proves who it is with a key that never leaves its machine.
- On joining, the agent makes an Ed25519 key pair in its folder, readable by its owner only, and registers the public key.
- Every connection signs a fresh challenge from BridgeStick: no bearer secret travels after enrolment.
- Auth keys are one-off by default, expiring and revocable; enrolment can require your approval; revoking an agent closes its session at once.
Outbound-only agents
Agents dial out; nothing dials in.
- One WebSocket over HTTPS on port 443: no inbound port, no listening service, no tunnel.
- The agent connects to your systems by their real host names, so TLS certificates are checked as anywhere else.
- On Linux the service runs as an unprivileged user, hardened: no new privileges, a read-only system, only its folder writable.
Allow lists the customer controls
What an agent may reach is decided on the agent, by you.
- Hosts, networks, ports and folders, added with
bridgestick allow add. The list starts empty. - Every target a connector will reach is resolved and checked before it opens; anything else is refused.
- Only the agent enforces it: a compromised cloud cannot use an agent to reach what you did not allow.
Egress policy in the cloud
A tenant cannot point BridgeStick at BridgeStick.
- Every host a cloud source or destination names must resolve to public addresses only — checked when it is saved, tested and opened.
- So no connector can reach the cloud's own network: its metadata server, its private network, its control database. Private systems are reached through links.
- As defense in depth, the servers drop the application's traffic to the metadata server and to private ranges.
Resilience
A stop loses nothing.
- Every run keeps checkpoints as it goes: after a restart, a crash or a cancel it resumes from the last one, and every destination stays consistent.
- Agents and the app reconnect by themselves; agents wait 1 second and double up to 60, with jitter, so they do not all come back at once.
- BridgeStick's cloud backs up its control database every day and keeps the backups for 14 days.
- Installations on PostgreSQL can run two servers, active/standby: when the leader stops, the standby takes over within seconds.
Signed downloads
What you install is what BridgeStick published.
- Agent bundles and packages are listed with their SHA-256 sums in a manifest signed with BridgeStick's Ed25519 release key.
- The installer verifies that signature before it installs anything; the apt repository is signed with GPG.
Sign-in and audit
Who did what is known, and kept.
- In BridgeStick's cloud you sign in with Firebase Authentication (email and password, or Google); the server verifies the signed ID token, and that the sign-in comes from BridgeStick's own app (Firebase App Check, with reCAPTCHA Enterprise telling people from bots), before it opens a session.
- Changes are recorded in an audit trail; installations with their own login hash passwords with PBKDF2-SHA256 and lock out repeated failures.
- The website and the app are served over HTTPS only, with HSTS.
Threat model
Risks, and how they are met.
| Risk | Answer |
|---|---|
| A tenant points a source at the cloud's own network (SSRF: the metadata server, the private network, the control database). | The egress policy: cloud connectors reach public addresses only, checked when saved, tested and opened; the servers also drop such traffic. |
| A compromised cloud tries to reach into a customer's network. | The agent enforces its own allow list; it opens no inbound port and runs as an unprivileged user. |
| An auth key is stolen. | Keys expire, are one-off by default and revocable, and enrolment can require approval. |
| An agent's key is stolen. | Revoking the agent closes its session; the private key never leaves the agent's machine. |
| Two tenants use the same private address. | A table's identity includes its link, so tenants never conflict, and one writer per table still holds within a network. |
| A download is tampered with. | Signed manifests verified by the installer, and a GPG-signed apt repository. |
Bridge your data with nothing bent on the way.
Create your space, connect a source and run your first sync — free during early access. When your systems are private, an agent is one command away.