Client: democompany | Date: March 12, 2026
This executive summary highlights critical vulnerabilities discovered during our initial automated surface scan. These represent immediate risks to your data integrity and tenant isolation.
The platform's central credential vault — `credentials_entity` — stores every third-party integration secret for every tenant: Stripe payment keys, OpenAI API keys, Slack bot tokens, and webhook signing secrets. A user with a standard Trial account can call the database API directly and retrieve the complete credential payload for every Enterprise organization on the platform in a single request.
Impact: This is a company-ending event if discovered by a malicious actor before remediation. With a stolen Stripe secret key, an attacker can process or refund payments on behalf of Enterprise clients. With stolen OpenAI keys, they can exhaust an enterprise client's AI budget ($50k+/month accounts are common at this scale). Each exfiltrated credential constitutes a separate GDPR reportable incident requiring notification to the affected organization within 72 hours. There is no log of this access — the leak is silent.
When users connect external services (Google, GitHub, HubSpot, Slack) to their democompany workflows, the platform stores their live OAuth bearer tokens in `oauth_access_tokens` and their persistent refresh tokens in `oauth_refresh_tokens`. Both tables have no access controls. Any authenticated user can retrieve the current session token for any connected account across any organization.
Impact: A stolen OAuth access token does not require knowing a password. The attacker presents the token directly to the third-party provider (Google, Slack, GitHub) and is immediately granted full account access as the victim — including read/write access to email, documents, repositories, and CRM data. The refresh token makes this access permanent: even if the victim revokes their democompany connection, the attacker can continue generating new access tokens. This is Account Takeover (ATO) at platform scale.
democompany issues long-lived API keys for programmatic platform access. These keys are stored in `user_api_keys` with no row-level restrictions. Unlike session tokens, API keys do not expire by default and are not invalidated by a password reset — making them the most dangerous credential type on the platform. All keys for all users are accessible via a single authenticated REST call.
Impact: An attacker who harvests API keys gains a backdoor into every account on the platform that survives password resets, 2FA enrollment, and account lockouts. They can silently operate as any user — triggering workflows, accessing execution data, and reading credentials — for an indefinite period without detection, as API key usage is typically attributed to the legitimate user in audit logs.
Supabase Security Advisor (SSA) is a great tool for static config, but it doesn't simulate real-world attacks. Here is the difference:
| Feature | Supabase Advisor (Free) | Otobrix Labs (Pro) |
|---|---|---|
| Logic Type | Static / Passive | Dynamic / Active |
| Detection | "Is RLS enabled?" | "Can I leak cross-tenant data?" |
| Scope | DB Schema Only | API + JWT + DB Handshake |
| The "BOLA" Test | Cannot detect | Primary Focus |
The "False Green" Scenario: SSA gives a green check if RLS is "on". However, a faulty policy like USING (true) will still appear "secure" to standard tools, while leaking 100% of your data to an attacker. We verify the boundary, not just the toggle.
Proprietary assessment generated by Otobrix Security Engine v7.2.0 — Confidential