BridgeStick

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 (429 with Retry-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.

Risks BridgeStick's design answers
RiskAnswer
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.