Security

Breaklytix handles two sensitive categories of data: GitHub access tokens (used to scan your repositories and open auto-fix pull requests) and API keys you add for provider monitoring. We apply the same basic principle to both: credentials are encrypted before storage, never exposed to the browser, and scoped to what the feature needs.

• Provider API keys and GitHub tokens are encrypted before they are stored (Fernet, AES-128-CBC with HMAC). The encryption key exists only in the server environment, never in the database or the browser.
• Credentials are never returned to the frontend. The UI shows only safe metadata: provider name, connection status, and a masked identifier.
• Credentials never appear in URLs, emails, or logs.

• In transit: all traffic uses HTTPS/TLS.
• At rest: data is stored in a hosted PostgreSQL database (Supabase) with encryption at rest.
• Credentials: symmetric encryption (Fernet / AES-128-CBC with HMAC) as described above.

• Sign-in uses GitHub OAuth 2.0. We never see or store your GitHub password.
• After OAuth, the backend issues a short-lived, signed session token (30 days) that the frontend keeps in browser storage.
• The frontend's GitHub OAuth flow uses a random one-time state value to prevent request forgery.

• Every API route resolves the authenticated user server-side; queries are scoped to that user's ownership (repositories, provider connections, alerts).
• Admin-only routes require an admin flag verified server-side.
• Internal/background endpoints require a shared secret; debug endpoints are additionally protected.

• We access GitHub only through the permissions you grant when you connect a repository.
• Repository scanning reads metadata and source files needed to detect API usage.
• Auto-fix may create branches and open pull requests in repositories you connect — only after you authorize the connection. Pull requests are never merged automatically; you review and merge them.
• You can revoke the application's GitHub access at any time from your GitHub account settings.

• Server secrets (database service-role key, encryption key, OAuth secret, email/billing keys) are configured in the hosting environment and never compiled into client code.
• Public-build variables are limited to what the browser genuinely needs (API base URL and the GitHub OAuth client ID, which is public by design).
• Diagnostic endpoints return partial values only (e.g. a prefix) and only when the internal secret is supplied.

• Cross-origin requests are restricted to an allow-list of frontend origins (including preview domains); credentials are not shared cross-origin.
• Requests that fail validation or authentication receive generic error messages that do not reveal internal details.

We keep limited diagnostic logs to operate and debug the service. Logs never include tokens, API keys, passwords, or repository contents. Error responses returned to the browser are deliberately generic and contain no secrets.

Data is stored per user: provider-connection records include the owning user, and monitoring snapshots are scoped by user (and repository where relevant). Global provider-incident records are not tied to individual users. Users cannot read or modify another user's repositories, connections, or alerts.

We monitor provider health and incidents surfaced through the service, review dependency security advisories, and ship fixes through our normal release process. We recommend keeping dependencies updated and watching for release notes.

Found a security issue? Please tell us privately before disclosing it publicly: hashirattari73@gmail.com or open a private issue via our Contact page. We investigate reports and keep reporters informed.