Skip to main content

​
Executive summary

The highest-risk themes are public edge endpoints that intentionally run with verify_jwt = false, service-role operations that can bypass RLS if org scoping is missed, and third-party webhook trust boundaries that rely on correct signature verification and replay protection. The largest impact areas are cross-tenant data exposure, PHI disclosure through integrations or AI tooling, and integrity compromise of payroll/background-check/telephony workflows. Critical CI controls exist, but supply-chain hardening (for actions and dependency provenance) remains an important residual risk.

​
Scope and assumptions

  • In scope paths:
    • src/ runtime app and auth/session handling
    • supabase/functions/ edge runtime (HTTP functions + shared auth/cors/supabase helpers)
    • supabase/config.toml platform auth and edge JWT-mode settings
    • .github/workflows/build.yml critical CI gate controls
    • vercel.json deployment headers and browser hardening
  • Out of scope:
    • Detailed per-integration protocol audits for every one of the 200+ edge functions
    • Non-critical local tooling behavior (dist/, node_modules/, test fixtures)
    • Infrastructure outside repo (cloud firewall, WAF, secret manager policies)
  • Assumptions:
    • Deployment is internet-exposed production SaaS with PHI and strict tenant isolation requirements.
    • Supabase service-role keys are restricted to server-side functions and never exposed to clients.
    • RLS is the primary tenant isolation boundary for authenticated data access.
    • Third-party integrations (RingCentral, Checkr, Plaid, Ramp, OpenRouter) are reachable from edge functions.
  • Open questions that could materially change ranking:
    • Is there centralized API gateway/WAF rate limiting in front of Supabase edge endpoints?
    • Are webhook replay windows and nonce caches enforced consistently per provider?
    • Are CI workflows protected by branch protection + required approvals for workflow file changes?

​
System model

​
Primary components

  • Browser SPA (React + react-router) with Supabase session usage and lazy-loaded modules (src/App.tsx).
  • Client auth/session abstraction via useCurrentUser and Supabase JS client (src/platform/auth/useCurrentUser.ts, src/integrations/supabase/client.ts).
  • Supabase Auth + Postgres (RLS + SECURITY DEFINER helper pattern) for tenant isolation (supabase/migrations/20260211182655_6aeefd1c-c5cc-4eaf-98b0-3e38abc7ba6a.sql, tests/rls/pf-profiles.rls.test.ts).
  • Supabase Edge Functions for business and integration workflows (supabase/functions/*, supabase/config.toml).
  • Third-party integrations: telephony/SMS, financial aggregation, background checks, AI providers (supabase/functions/ringcentral-webhook/index.ts, supabase/functions/sms-webhook/index.ts, supabase/functions/plaid-webhook/index.ts, supabase/functions/checkr-webhook/index.ts, supabase/functions/ai-skill-execute/index.ts).
  • CI gate in GitHub Actions before build/test artifact acceptance (.github/workflows/build.yml).

​
Data flows and trust boundaries

  • Internet user browser -> SPA runtime (src/App.tsx)
    • Data: credentials, access tokens, org/site context, UI inputs.
    • Channel: HTTPS browser requests.
    • Security guarantees: route-level auth session checks, React Query caching, error boundary.
    • Validation/enforcement: session lookup and auth state listener (supabase.auth.getSession, supabase.auth.onAuthStateChange).
  • SPA runtime -> Supabase Auth/PostgREST (src/integrations/supabase/client.ts, src/platform/auth/useCurrentUser.ts)
    • Data: JWT bearer token, row-scoped queries, profile/org lookups.
    • Channel: HTTPS via Supabase JS.
    • Security guarantees: JWT auth, RLS-backed data filtering.
    • Validation/enforcement: supabase.auth.getUser() and RLS policies.
  • Internet/webhook providers -> Edge Functions with verify_jwt = false (supabase/config.toml)
    • Data: webhook payloads, provider signatures/JWTs, event metadata.
    • Channel: HTTPS POST webhooks.
    • Security guarantees: function-local signature checks (provider specific) and CORS handling.
    • Validation/enforcement: HMAC/JWT verification in webhook handlers (verifySignature, verifyWebhookSignature, verifyPlaidWebhook, computeCheckrSignature).
  • Edge Functions -> Postgres with service role (supabase/functions/_shared/supabase.ts)
    • Data: PHI/PII metadata, payroll/banking references, audit events, role assignments.
    • Channel: internal Supabase client over TLS.
    • Security guarantees: elevated service credentials plus explicit org filtering.
    • Validation/enforcement: manual .eq('organization_id', ...) and role checks (verifyOrgAccess, verifyOrgRole).
  • Edge Functions -> External APIs (Checkr/Plaid/Ramp/RingCentral/OpenRouter)
    • Data: integration tokens, webhook event payloads, AI prompts/messages.
    • Channel: HTTPS API calls.
    • Security guarantees: provider auth headers, optional encryption at rest for stored tokens.
    • Validation/enforcement: per-provider request signing and error sanitization patterns.
  • GitHub -> CI workflow (.github/workflows/build.yml)
    • Data: source code, dependency graph, test/build outputs.
    • Channel: GitHub-hosted runner execution.
    • Security guarantees: validation steps and smoke gates.
    • Validation/enforcement: format/type/lint/test/RLS coverage/build checks.

​
Diagram

​
Assets and security objectives

​
Attacker model

​
Capabilities

  • Remote internet attacker can send arbitrary requests to public endpoints and webhook paths.
  • Attacker can replay captured webhook payload/signature pairs if anti-replay controls are weak.
  • Authenticated low-privilege tenant user can attempt privilege escalation and cross-tenant data access.
  • Third-party integration compromise can send validly signed but maliciously crafted events.
  • Dependency or CI adversary can attempt supply-chain tampering via build pipeline inputs.

​
Non-capabilities

  • Attacker does not have assumed direct shell access to Supabase or Vercel runtime hosts.
  • Attacker does not start with possession of Supabase service-role keys by default.
  • Attacker cannot bypass strong cryptographic signature verification when keys remain secret and implementation is correct.

​
Entry points and attack surfaces

​
Top abuse paths

  1. TM-001 Cross-tenant read/write via public edge path
    1. Attacker discovers a verify_jwt = false function lacking complete authz checks.
    2. Sends crafted request with attacker-controlled organization identifiers.
    3. Function executes with service role and missing org filter on one mutation/query.
    4. Data from another tenant is read or modified.
  2. TM-002 Webhook spoofing or replay for privileged workflow mutation
    1. Attacker replays previously valid webhook payload/signature pair.
    2. Endpoint accepts signature but lacks nonce/timestamp replay defense.
    3. Duplicate or stale financial/telephony/background-check state transition is applied.
    4. Integrity and downstream reporting are corrupted.
  3. TM-003 Service-role token misuse in edge auth helper
    1. Service-role key is exposed through misconfiguration/logging/ops leak.
    2. Attacker sends it as Bearer token to validateAuth-using endpoints.
    3. Handler treats requester as internal service-role principal.
    4. Org checks are bypassed where not independently enforced.
  4. TM-004 AI exfiltration of sensitive data through tooling/fallback provider
    1. Authenticated user submits prompts containing PHI or data extraction requests.
    2. Skill executes with tool calls and optional provider fallback.
    3. Sensitive content may transit external provider or tool outputs beyond intended minimum scope.
    4. PHI handling and confidentiality boundaries are weakened.
  5. TM-005 Credential misuse or weak proxy trust assumptions in payroll integration
    1. Attacker abuses endpoint with spoofed proxy headers or compromised account.
    2. Proxy path forwards actions with stored OAuth tokens.
    3. Unauthorized payroll API actions or data access occurs.
    4. Financial integrity and confidentiality are impacted.
  6. TM-006 SMS/telephony ingestion manipulation and consent-state abuse
    1. Attacker submits forged/ambiguous inbound SMS payloads or provider-like callbacks.
    2. Contact matching and status updates mutate communication records.
    3. Consent and message status become inaccurate.
    4. Compliance and patient communication integrity are impacted.
  7. TM-007 CI supply-chain compromise
    1. Malicious dependency update or compromised action behavior enters PR path.
    2. CI executes build/tests with attacker-controlled package code.
    3. Artifact or lockfile integrity is subverted and malicious code reaches deploy path.
    4. Broad confidentiality/integrity impact across all tenants.
  8. TM-008 Resource exhaustion against public edge endpoints
    1. Botnet floods webhook/public function endpoints.
    2. Signature verification and downstream DB/API calls consume compute budget.
    3. Legitimate requests are delayed or dropped.
    4. Availability and SLA degrade across modules.

​
Threat model table

​
Criticality calibration

  • Critical in this repo/context:
    • Any exploit yielding cross-tenant PHI exposure or mutation at scale.
    • Any compromise of service-role credentials enabling broad bypass of tenant controls.
    • CI compromise resulting in malicious code shipped to production.
  • High in this repo/context:
    • Single-tenant PHI exposure through integration or AI data egress.
    • Unauthorized payroll/background-check workflow mutation with financial/compliance consequences.
    • Reliable replay/spoof attacks on webhook-driven state changes.
  • Medium in this repo/context:
    • Availability degradation of public functions without direct confidentiality/integrity loss.
    • Limited-scope consent/message integrity issues requiring multiple conditions.
    • Weak observability that delays detection but does not directly grant access.
  • Low in this repo/context:
    • Informational leakage without tenant crossover or sensitive payload access.
    • Dev-only behavior that is isolated from production paths.
    • Non-exploitable hardening gaps with compensating controls and low attacker utility.
Examples by level:
  • Critical examples: TM-001 at scale with PHI extraction, TM-003 with leaked service-role key, TM-007 with malicious build artifact insertion.
  • High examples: TM-002 replay against financial events, TM-004 PHI egress via AI provider fallback, TM-005 payroll proxy abuse.
  • Medium examples: TM-006 consent-state manipulation with partial impact, TM-008 sustained but bounded endpoint flooding.
  • Low examples: CORS/header hardening deviations without credential-bearing exploit path (none prioritized in top table).

​
Focus paths for security review

​
Quality check

  • Covered discovered entry points: yes (SPA auth, edge API, webhooks, AI endpoint, CI workflow).
  • Covered trust boundaries in threats: yes (internet->edge, edge->DB/service role, edge->vendors, git->CI->deploy).
  • Runtime vs CI/dev separation: explicit in scope/system model and TM-007.
  • User clarifications reflected: yes (whole platform, PHI multi-tenant, runtime + critical CI, top-risk integration deep dive).
  • Assumptions and open questions explicit: yes (scope/assumptions section).