Security

Data Flow

All network traffic flows directly between your browser and Microsoft Azure's cloud endpoints. We do not run middle-tier servers that intercept or process your messages. There is no external infrastructure that can access or leak your messaging payload.

No Message Storage

No Service Bus entity names, queue definitions, metadata, or message body payloads are ever sent to or stored on our servers. All message data retrieved from Azure is held strictly in your browser's volatile memory and is cleared when you close the tab.

Telemetry and Analytics

We use GoatCounter, a privacy-friendly analytics tool, to count simple usage stats such as page views. It does not use cookies and does not track personal data, so no consent banner is needed. No Azure Service Bus connection details, access keys, or message payloads are ever sent to GoatCounter or any other third-party services.

Browser-Only Execution

Because Bussin runs as a standard static web application, it inherits the sandbox protections enforced by modern browser engines:

• Same-Origin Isolation: Cross-origin resource sharing (CORS) rules prevent other websites or scripts from accessing Bussin's memory space or local storage.
• TLS Encryption: All communication with Microsoft management and data endpoints is secured via standard browser-enforced TLS 1.2 or 1.3 channels.

Microsoft Authentication Model

MSAL.js handles sign-in directly within your browser's security context. The acquired OAuth 2.0 access token is used locally to connect to Azure. Your credentials never pass through external servers, and access rights conform strictly to your active Azure Role-Based Access Control (RBAC) permissions.

What Bussin Stores in Your Browser

Nothing Bussin stores ever leaves your machine, but some of it does persist between sessions rather than living only in memory. Being precise about this matters more than sounding reassuring, so here is exactly what is written where.

• Token cache (localStorage): Sign-in uses the Microsoft Authentication Library (MSAL.js), configured with its localStorage cache so you are not forced to re-authenticate on every page load. OAuth 2.0 tokens issued by Entra ID therefore persist on disk until they expire or you sign out. This is MSAL's own cache, in its own format, and it is the same mechanism the Azure Portal and most Microsoft web clients use.
• Connection strings (localStorage): If you add a namespace using a Service Bus connection string, that string is saved with your workspace so the namespace is still there next time you open the app. A connection string contains a shared access key, which is a long-lived credential, and it is stored in plain text. Anything with access to your browser profile can read it. If you would rather not persist a key, use Entra ID sign-in instead, or remove the namespace when you are done with it.
• Workspace settings (localStorage): Namespace bookmarks, folder layouts, column choices, and theme.
• Message data (memory only): Message bodies, properties, and search results are never written to storage. They are held in the tab's memory and are gone when you close or reload it.

All of this lives under the app.bussin.dev origin, so browser same-origin rules keep other sites out of it. Clearing site data for that origin removes everything above. On a shared or untrusted machine, prefer Entra ID sign-in over connection strings, and sign out when you finish.

Source Availability and Auditability

Bussin's full source is published under the Business Source License 1.1. It is source-available rather than open source: free to read, audit, and self-host for personal, educational, and internal business use, and it converts to Apache 2.0 on 1 January 2029. Security teams are encouraged to audit the codebase or self-host the static client:

• Bussin App Core: Audit the client-side WebAssembly rendering, AMQP protocol logic, and local storage configurations: github.com/sgebb/bussin
• Bussin Static Site: Audit this documentation site and static landing pages: github.com/sgebb/bussin-site