In the Detector of the Month series, we will be featuring our favorite projects or services our secrets detection engine supports. We’re kicking off the series with Supabase!
Supabase, The Open Source Firebase Alternative
If you’ve never used Firebase, it might be hard to guess what its open source alternative is all about. Supabase enables developers to spawn a backend in no time, batteries included. Creating a Supabase project gives you instant access to:
- A hosted Postgres database;
- A REST API and a client library;
- A Real-time server;
- An extensible user authentication system;
- A storage system to handle all your static files;
- And an admin dashboard to manage these components all the way through.
What sets Supabase apart from other projects in the space is its strategy to exclusively harness the power of open source. The database provided is PostgreSQL, the RESTful API is based on PostgREST, user authentication is based on the Netlify GoTrue API, and all the components are tied together with Kong's Gateway API. This also gives users the ability to easily extend and self-host their Supabase projects using Docker.
You can give it a try for your next project here.
GitGuardian now detects Supabase keys
At GitGuardian, we’re regularly adding support for new types of credentials. We simply aim to help as many developers as possible keep secrets and credentials out of their git repositories. So when considering building a new specific detector, our R&D team pays close attention to the project’s popularity within the developer community.
Supabase checked all the boxes and this came as no surprise. The project has consistently ranked in GitHub's top-20 fastest-growing open source startups and has launched 50,000 databases in 2021 only. This inspired us to build two specific detectors, helping developers catch hardcoded:
These secrets should always be kept private and never exposed in client-side code. Failure to do so allows malicious actors to gain super admin (read supa admin) rights over a Supabase project and the associated production Postgres database.
How to handle Supabase secrets-in-code incidents
If you’re a Supabase user and receive an alert from GitGuardian mentioning a leaked Supabase key, follow the steps below:
- Understand the implications of the incident. A bad situation can be made worse if a secret is revoked without understanding how that secret is currently being used. In the case of Supabase, leaking a JWT secret (anon key) is not a threatening situation if you have RLS enabled (Row Level Security) on your Postgres database. However, leaking a Service Role JWT means you are giving access with super admin privileges to your project. You can learn more in the Supabase docs.
- Rotate and revoke the secret. Contact firstname.lastname@example.org, ask their team to revoke your compromised secret and issue you a new one.
- Manage your secrets. Use a dotenv file properly or look for alternative Secrets Management solutions to avoid hardcoding credentials in the future.
- Optional – Remove all evidence from your git history. Delete the entire repository or rewrite the git history.
- Review access logs. Check for suspicious activity in the log data of your services impacted by the secret.
What about other secrets?
GitGuardian helps developers keep 250+ types of secrets out of source code. Our automated secrets detection and remediation solution secures every step of the development life cycle, helping you monitor your code for sensitive data:
- On developer workstations with Git hooks (pre-commit and post-commit);
- On Git repositories hosting platforms (GitHub, GitLab, and Bitbucket);
- In CI pipelines (Circle CI, Travis CI, Jenkins CI, GitHub Actions, and much more);
- In Docker images.