Supabase Misconfigurations Reveal Over 16,000 Exposed Databases

Scale of the Supabase Exposure

In a recent security study, analysts identified more than 16,000 Supabase instances that were unintentionally open to the internet. Each instance contained at least one table that could be queried without authentication, allowing anyone to retrieve data stored in the database.

Discovery methodology

The research team used automated scanners that probed public IP ranges for Supabase endpoints. When a response indicated that the public schema was accessible, the scanner attempted to list tables and fetch sample rows. Over a period of several weeks, the process yielded a large list of vulnerable databases.

For background on how public cloud services can be unintentionally exposed, see the guidance from the Cybersecurity and Infrastructure Security Agency.

Types of data found

Among the exposed tables, researchers observed three broad categories of sensitive information.

Personal identifiers

• Full names and email addresses
• Phone numbers and mailing addresses
• Birth dates and government issued identifiers

Authentication tokens

• OAuth access tokens that could be used to impersonate users
• API keys for third party services
• Refresh tokens stored in plain text

Credentials and passwords

• Hashed passwords that could be cracked with offline attacks
• Plain text passwords for development accounts
• Database connection strings containing usernames and passwords

The presence of authentication tokens is particularly concerning because they can grant immediate access to user accounts on other platforms. The Open Web Application Security Project lists token leakage as a high severity issue.

Why misconfigurations happen

Supabase is designed to be developer friendly, offering a managed Postgres database with built-in authentication and real time features. However, several factors contribute to the frequent exposure of data.

Default settings

When a new project is created, the public schema is often left open by default. If developers do not adjust the Row Level Security (RLS) policies, the tables become readable by anyone who knows the endpoint URL.

Developer oversight

Many teams treat Supabase as a quick prototype tool and move code to production without a thorough security review. In fast paced environments, security settings can be overlooked, especially when the focus is on delivering features.

Lack of automated checks

Continuous integration pipelines rarely include scans for open database endpoints. Without automated alerts, a misconfigured instance can remain exposed for months.

Potential impact on users and businesses

When personal data is publicly accessible, the risks extend beyond simple privacy concerns. Attackers can use harvested emails for phishing campaigns, combine phone numbers with other data for identity theft, or sell the information on underground markets.

Compromised authentication tokens enable credential stuffing attacks against related services. If an API key is leaked, malicious actors can consume paid resources, leading to unexpected costs for the affected organization.

Regulatory frameworks such as the European Union's General Data Protection Regulation (GDPR) and the California Consumer Privacy Act (CCPA) impose heavy fines for inadequate protection of personal data. Companies that host the exposed Supabase instances may face legal exposure if the breach is linked to their negligence.

Best practices to secure Supabase deployments

Supabase provides several built‑in mechanisms to protect data. Implementing them correctly can dramatically reduce the chance of accidental exposure.

Enable row level security

• Activate RLS on every table that stores sensitive information.
• Define policies that restrict SELECT, INSERT, UPDATE and DELETE operations to authenticated users only.
• Test policies with the Supabase console before moving to production.

Audit public tables regularly

Schedule a weekly review of the public schema. Use the Supabase CLI or API to list tables and verify that none contain confidential fields.

Rotate secrets and tokens

• Generate new API keys whenever a project is created.
• Store keys in a secret manager rather than hard coding them.
• Set expiration dates and automate rotation to limit the window of exposure.

Use environment specific projects

Separate development, staging and production environments into distinct Supabase projects. This prevents accidental leakage of production data during testing.

Integrate security scanning into CI/CD

Tools such as NIST security checklists can be adapted to verify that no public endpoints are left open before code is merged.

Industry response and recommendations

Supabase has acknowledged the findings and released a security advisory that outlines steps developers should take immediately. The company also announced upcoming features that will make RLS enforcement the default for new tables.

Security experts advise organizations that rely on Supabase to conduct a rapid audit of all existing projects. Any database that shows a public schema without RLS should be locked down within hours.

Regulators are expected to increase scrutiny of cloud based database services after this incident. The CISA recently published guidance on securing serverless data stores, which aligns closely with the steps described above.

By treating database configuration as a critical component of the software development lifecycle, teams can avoid the costly fallout of accidental data exposure.