Aikido

Aikido Attack Surface systematically evaluates publicly accessible Supabase configurations to detect conditions that could result in unauthorized data exposure. In Supabase, limited client access via the public anon key is expected; however, the security of this model relies on correctly implemented Row Level Security (RLS). Absent or improperly scoped RLS policies may render tables broadly readable or writable, exposing personally identifiable information (PII) or enabling cross-tenant access. Because the anon key is embedded in client-side code, any visitor can exploit such weaknesses, potentially leading to a material data breach depending on the sensitivity of the affected data.

Methodology

• Key discovery: Crawl deployed frontend JavaScript assets to extract the Supabase client anon key.
• Project identification: Determine the Supabase project endpoint (e.g., https://<project>.supabase.co) from the JWT token or code references.
• Credential validation: Establish a connection to the project to verify that the extracted anon key is valid.
• Surface enumeration: Enumerate tables within the public schema that are addressable through the client context.
• Permission testing: Attempt read and write operations on each table using only the anon key to identify gaps caused by missing or misconfigured RLS.
• Sensitivity assessment: For any table that is readable, analyze returned records for PII and other sensitive fields to determine exposure severity and remediation priority.

Through this process, Aikido precisely identifies exposed tables, confirms write capabilities where present, and characterizes the sensitivity of leaked data, enabling timely and targeted corrective action.