Security

Security at Inbora

We take security seriously. Here's how we protect your data and API access.

API Key Security

  • API keys are shown only once at creation — we store a SHA-256 hash, never the raw key.
  • Keys use prefixed formats (INBX, INBP, INBE) to make them identifiable in leaked credential scans.
  • You can revoke keys instantly from the dashboard.
  • Each key tracks its own request count for anomaly detection.

Data Encryption

  • All data is encrypted at rest using AES-256 (managed by Supabase/AWS).
  • All traffic is encrypted in transit using TLS 1.2 or higher.
  • Database connections use SSL and require authentication.
  • Email content processed via the API is never persisted to disk.

Access Control

  • Row-Level Security (RLS) is enforced at the database level — users can only access their own data.
  • Service-role operations are isolated from the public API surface.
  • Dashboard access requires authenticated sessions via Supabase Auth (JWT).
  • OAuth callback and magic links use time-limited tokens.

Infrastructure

  • API servers run on Fly.io with automatic TLS provisioning.
  • Database hosted on Supabase (AWS us-east-1) with automated backups.
  • No SSH access to production — deployments are fully automated via CI/CD.
  • Dependencies are scanned for known vulnerabilities on every build.

Open Source Transparency

Inbora's codebase is fully open source under the MIT License. Security researchers and users can audit the code, verify our claims, and identify issues before they affect production systems. Transparency is one of our strongest security controls.

View the source code on GitHub

Responsible Disclosure

If you discover a security vulnerability in the Inbora service or codebase, please report it responsibly. We appreciate your help in keeping Inbora secure.

Please do not publicly disclose vulnerabilities before we have had a reasonable opportunity to address them.

Privacy PolicyTerms of ServiceDocumentation