Title here
Summary here
Security at stellarbridge
This page summarizes how Stellarbridge secures access to the portal and APIs today. It is written for users and administrators and only describes what we currently do in the product and our managed deployments.
How we secure access
- Authentication
- Email and password sign‑in. Passwords are stored as secure hashes; we never store plaintext passwords.
- Optional multi‑factor authentication (MFA) using time‑based one‑time passwords (TOTP).
- New accounts use an email verification flow before full access is granted.
- Sessions and tokens
- Signed JSON Web Token (JWT) is issued on login and kept in a cookie named “stellarbridge”.
- The JWT cookie is HttpOnly and set with SameSite=Lax. Typical lifetime is up to 24 hours.
- We encrypt other application cookies at the framework level; the JWT cookie itself remains readable by the server but is not accessible to scripts in the browser.
- Short‑lived server sessions are used for login/MFA challenges. When configured, we use Redis for session storage; otherwise the app falls back to in‑memory storage.
- Authorization
- Role‑based access control (RBAC) is enforced across API routes. We seed sensible default roles, and administrators can assign roles to users to govern access.
Protecting data in transit
- Portal and APIs are served over HTTPS in our managed environments (TLS termination at the ingress).
- For self‑hosted deployments, we recommend enabling TLS at your ingress or load balancer.
- File actions initiated from the portal (uploads and streams) use encrypted connections. See the related topics for what to expect during transfers.
Related topics: File uploads, File streaming
Abuse protection
- Rate limiting is enabled for API endpoints by default to reduce abuse and credential‑stuffing attempts. The current policy allows approximately 30 requests per 15 seconds per client for API routes (static assets are not limited).
Logging and audit signals
- Security‑relevant events such as successful and failed sign‑ins are recorded with timestamps and basic context (e.g., IP address). Logs are written asynchronously for reliability.
- Application errors are handled centrally and recorded with structured fields to aid investigation without exposing sensitive data in responses.
If you need access to logs for your organization, contact support.
Responsibilities and good practice
- Administrators
- Use roles to restrict who can invite users, configure destinations, upload, or initiate streams.
- Require MFA for accounts with elevated permissions.
- If you self‑host, ensure HTTPS is enforced at the edge and keep Redis (if used) restricted to trusted networks.
Admin requirements by deployment
| Admin action | Self-hosted | Cloud-hosted | Notes |
|---|---|---|---|
| Enforce HTTPS/TLS at the edge | Yes | Managed | TLS termination at ingress/load balancer. |
| Configure roles and permissions | Yes | Yes | Govern access for invites, uploads, streams. |
| Require MFA for privileged accounts | Yes | Yes | Recommended security baseline. |
| Manage Redis session store (if used) | Yes | Managed | Keep self-hosted Redis on trusted networks. |
| Review audit logs on request | Yes | Yes | Access available via support as needed. |
- Users
- Keep your password unique and enable MFA when offered.
- Sign out on shared devices.
Third‑party services and compliance
- Third‑party processors we rely on are listed here: 3rd‑party data processors.
- Our current SOC 2 posture and plans are tracked here: SOC 2.
Related resources
- Permissions and roles: Permissions and RBAC
- How to upload a file: File uploads
- How to stream a file: File streaming
- Data processors and compliance: 3rd‑party data processors, SOC 2
- Need help? Contact support