We Built a Secret Scanner. In 5 Minutes, We Found 68 Exposed Auth Credentials.

Every business that uses modern cloud services has the same single point of failure: a configuration file somewhere that holds the keys to everything. Database credentials. API tokens. Login system secrets. These files are supposed to stay on the server, or in an environment variable, or in a secrets manager. They are not supposed to end up on GitHub, where anyone in the world can read them.

But they do. Constantly.

At Securva, we recently built an automated pipeline that hunts for exactly this category of leak. It targets credentials for the seven most common authentication services that developers use: Amazon Cognito, Google Firebase, Auth0, Supabase, Keycloak, Microsoft Azure AD B2C, and Okta. These are the systems that handle login for a huge portion of modern web applications, including many Nigerian fintechs, e-commerce platforms, and SaaS products.

We wanted to know: how bad is the leakage problem in 2026? What would a single automated pass find?

The answer was grimmer than we expected.

What We Actually Did

The pipeline is conceptually simple. We wrote a small program that calls GitHub's official code search API with 21 carefully chosen patterns. Each pattern is a sentence that developers typically leave in a configuration file when they set up one of the seven auth providers. For example, a Firebase setup almost always includes the strings firebaseConfig, apiKey, and authDomain together. A Supabase setup has SUPABASE_URL and SUPABASE_ANON_KEY. These are fingerprints, not secrets by themselves, but they tell us which files to look at.

For every repository that matched a fingerprint, we downloaded the raw file and ran a second pass with regex extractors. These look for the actual concrete credential values that follow the fingerprint. A Firebase API key always starts with AIza and is exactly 39 characters. A Supabase JWT token always starts with eyJ and has three dot-separated parts. A Cognito user pool ID matches the pattern region_alphanumeric. When the regex matches, we have a real credential, not a placeholder.

Then we filtered out the noise. Example domains like developer.okta.com and help.okta.com are not findings, they are documentation. Template values like yourproject and replaceme are not findings, they are placeholders. Repositories owned by the auth provider itself (such as okta/okta-spring-boot or auth0/nextjs-auth0) are not findings, they are the provider's own SDKs. Everything that survived this filter is a concrete, production, non-placeholder credential that a real human committed to a public repository by mistake.

Of the 210 initial matches, 68 survived.

The Three That Matter Most

Three hits were flagged at the top of our triage report under a bright red "Critical" header. These are the ones that keep security researchers awake at night.

Each of the three is a Supabase JSON Web Token (JWT) with the role claim set to service_role. If you are not familiar with Supabase, here is the short version. Supabase is a popular "backend-as-a-service" platform that a lot of Nigerian startups use because it is fast to set up and the free tier is generous. Every Supabase project has two main API keys. The anon key is for frontend code and is limited by Row Level Security rules that you configure in the dashboard. The service_role key is the admin key. It bypasses Row Level Security entirely.

All three of the service_role leaks we found were in personal developer projects, not enterprise deployments. That is actually worse in some ways. A large enterprise might have detection and rotation processes. An individual developer who committed their .env.txt file by accident probably will not notice until something bad happens.

We are engaging with the affected developers through coordinated disclosure channels and will not publish the specific repository names in this article. The goal is not to shame them, it is to help them rotate the keys before an attacker finds them.

How Fast Does This Actually Happen?

Here is the part that should terrify every business owner reading this. Research published by security firm GitGuardian has shown that the median time between a secret being committed to a public GitHub repository and the first automated scraper picking it up is under four minutes. There are bots that watch the GitHub public event stream 24 hours a day, 7 days a week, specifically hunting for leaked credentials. These bots are faster than human security researchers. They are faster than the developers who made the mistake. They are faster than almost any monitoring system.

This means that if you commit a .env file containing your Supabase service_role key at 10:00 in the morning, by 10:04 that key is almost certainly in an attacker's automated processing queue. By 10:30 it has been tested against the Supabase API to confirm it is valid. By noon, if the attacker decides it is valuable, they have started quietly exfiltrating your database.

The window between the mistake and the compromise is measured in minutes, not days or weeks. By the time the developer notices, the data is already gone.

What This Looks Like Across All Seven Providers

The Supabase service_role leaks get top billing, but they are not the whole picture. Here is the full breakdown of what our 5-minute pass surfaced, by authentication provider, showing how many repositories had real extracted credentials:

Add it up and you get 77 repositories with real extracted values in the initial pass. After filtering placeholders and provider-owned documentation repositories, we land at 68 genuine findings. That is one finding every 4.9 seconds of runtime.

What This Means for Nigerian Businesses

Here is where the Nigerian angle gets sharp. Nigerian fintechs, e-commerce platforms, and SaaS products are some of the heaviest adopters of these exact seven authentication providers. Firebase and Supabase in particular are extremely popular in the Lagos startup scene because they are quick to set up, they scale, and the free tiers are generous enough for early-stage products.

The flip side of that adoption is exposure. Every Nigerian startup that uses Supabase for their backend has, somewhere in their codebase, the same categories of configuration files we are hunting. Every Nigerian fintech that uses Auth0 for their customer logins has the same tenant domain fingerprint in their frontend bundle. The risk is not hypothetical. It is architecturally baked into how these companies ship software.

Under the Nigeria Data Protection Act (NDPA), a Nigerian company that leaks a Supabase service_role key and suffers a customer data breach is in serious trouble. The Nigeria Data Protection Commission (NDPC) has been moving sector by sector through enforcement, and their definition of "appropriate technical and organisational measures" absolutely includes basic secret hygiene. A company that committed its database master key to a public GitHub repository is not meeting the standard.

Fines under NDPA can reach the greater of 10 million naira (₦10,000,000) or 2% of annual gross revenue. A leaked secret is the kind of failure that directly maps to "inappropriate technical measures" in a regulatory investigation.

How to Check Your Own Exposure

Before you worry, check. Here is a five-minute audit that any Nigerian business can run on themselves, right now, without any tools:

1. Open GitHub and search your own company name. Look at every public repository that mentions your organization.
2. For each repository, open any file named .env, .env.example, config.js, firebase-config.js, or anything with secret in the name.
3. If the file contains a real value next to any of: SUPABASE_SERVICE_ROLE_KEY, FIREBASE_API_KEY, AUTH0_CLIENT_SECRET, AWS_SECRET_ACCESS_KEY, or anything that looks like a JWT starting with eyJ, you have an exposure.
4. Rotate that credential immediately at the provider's dashboard. Not "next week". Today.
5. Use git filter-repo or BFG Repo-Cleaner to remove the historical commit. Simply deleting the file from the current version does not help. The secret is still in git history.
6. Add the filename to your .gitignore so the same mistake does not happen again.

How to Prevent This From Happening Again

Prevention is cheaper than incident response. Six practices every Nigerian business should have in place:

1. Use a secrets manager from day one. Every cloud provider has one. AWS Secrets Manager, Google Secret Manager, Azure Key Vault. Your secrets live in the manager, and your application code reads them at runtime via an API call. They never touch your source code.

2. Install a pre-commit secret scanner. Tools like gitleaks or trufflehog run on every commit and refuse to let you push a file that looks like it contains secrets. Set this up once, benefit forever.

3. Use environment variables for everything, never hardcoded values. Your code reads from process.env.SUPABASE_KEY, and the actual value is configured in your deployment platform (Vercel, Netlify, Cloudflare Pages) as an environment variable outside of git.

4. Treat .env files like nuclear waste. They should be 0600 permission, never shared, never committed, never emailed, never pasted into Slack. The only person who should ever touch the file is the person who created it.

5. Rotate credentials on a schedule. Every 90 days is a good default. If you think you cannot rotate because it would break something, that means your architecture is too fragile and needs fixing.

6. Monitor GitHub for your own leaks. Set up a GitHub secret scanning alert on your organization, or use a third-party monitoring service. Find out about your own leaks before an attacker does.

The Bottom Line

We ran one automated pass. It took 5 minutes and 36 seconds. It found 68 real credentials and three master database keys. If we ran this same pass 12 times a day, we would find hundreds more. If we ran it for a week against enterprise-specific patterns instead of generic public repositories, we would find leaks at companies whose names you would recognize. This is the baseline noise of the modern software supply chain, and it is getting worse, not better.

The fixes are not technically difficult. Secrets managers exist. Pre-commit hooks exist. Environment variables exist. The problem is that most organizations do not know where their secrets currently live, let alone have a process to make sure they never end up in the wrong place. That is the gap we are trying to close with Securva.

If you build software in Nigeria, today is a good day to check your own GitHub organization. The next automated scanner that finds your secret will not be a Securva research team writing a blog post. It will be someone looking to make money.

If you need help auditing your GitHub repositories, rotating exposed secrets, or setting up pre-commit scanning for your team, the team at Pejji can help Nigerian businesses close these gaps fast. Start with a free consultation.