Look for unsafe database access in source files
The built-in checks flag broad Firebase rules and SQL that explicitly disables Row Level Security. These patterns can signal a development shortcut that should be investigated before release. A finding is a starting point for reviewing who may read and change data.
RLS enabled is only part of the review
Row Level Security also needs policies that match the ownership and role requirements of the application. Review reads and writes, unauthenticated access and attempts by one user to access another user’s records. The deeper AI review can flag likely mistakes in relevant code; it does not verify every deployed policy.
Check the actual project you will deploy
Source files may differ from the live database configuration. Confirm the active rules, policies and project environment using the provider’s dashboard or CLI. Test with the real client roles rather than relying only on an administrator connection.
Keep privileged credentials on the server
Supabase service-role keys and other private credentials must not be shipped to a browser. Public client keys have a different purpose and require correctly enforced access policies. If a privileged credential is exposed, revoke or rotate it before cleaning the repository.
Frequently asked questions
Does Quick Scan First test my live Supabase database?+
No. It reviews repository source files. It does not connect to Supabase to enumerate deployed policies or query production tables.
Does it review Firebase security rules?+
It can flag unsafe patterns in relevant repository rules files. Verify that the intended rules are deployed and test authorised and unauthorised access separately.
Is turning RLS on enough?+
No. Review the applicable policies and test that users can access only the data their role and ownership permit.
Sources and current provider information
Reviewed 14 October 2026. Provider capabilities and terms can change.