A pre-launch routine that checks your site or app for leaked secret keys, access settings and monitoring

How the system fits together

Secret scanning (TruffleHog) → review GitHub alerts → rotate the key if it leaked → Supabase access review → deployment and domain settings → accessibility and uptime monitoring → fix list with owners.

• 
  TruffleHog required

  Scans repository history and files on your own computer; by default it tries each key it finds against the service's API

  Tool guide

• 
  GitHub secret scanning optional

  If your repository is on GitHub, you check where alerts and push protection show up

  Alternative: If you keep your repository on GitHub; it is an extra alert layer alongside TruffleHog, not a replacement

  About the tool

• 
  GitGuardian ggshield optional

  A command-line scanner that can be used instead of TruffleHog; it requires a GitGuardian account and the scanned content is sent to GitGuardian's API

  Alternative: If you are fine with creating an account and having the scanned content sent to GitGuardian's servers

  Tool guide

• S
  Supabase row-level security required

  Database rules that determine who can read and write user data; this guide only reviews them

  Official site

• 
  Lighthouse required

  Runs an accessibility audit inside Chrome DevTools

  About the tool

• 
  Better Stack required

  Checks from the outside whether the site is up and sends alerts

  Tool guide

• 
  SigNoz optional

  More thorough monitoring for teams that want to collect traces and error data from inside the app

  Alternative: If a simple up/down check is not enough and you need in-app error and performance data; its setup is not covered in this guide

  Tool guide

• 
  Cloudflare optional

  If your domain is already on Cloudflare, you review its DNS and protection settings

  Alternative: Only if your domain is managed through Cloudflare

  About the tool

• 
  Docker optional

  Optional and advanced: needed only if you want to test on a local copy of Supabase

  Alternative: If you want to run the access test on a local copy rather than the live project

  About the tool

• 
  Strix optional

  Further reading: an automated security testing tool used only on your own app, in a test environment and with explicit written permission; not set up in this guide

  Alternative: If you are considering deeper testing after finishing the basic check

  Tool guide

• 
  CrowdSec optional

  Further reading: not set up in this guide

  Alternative: If you are looking into server protection after finishing the basic check

  Tool guide

• 
  NVIDIA SkillSpector optional

  Further reading: not set up in this guide

  Alternative: If you are looking into additional scanning tools after finishing the basic check

  Tool guide

Before you start

Step-by-step setup

The steps you check stay only in this browser; they do not confirm that the setup works. You finished 0/9 steps.

1. Step 1 · In an app

   Write down what you are checking and who is responsible

   I finished this step

   What for: Every issue found gets an owner, so the check does not stay vague.

   !You check this step yourself; the system should not move past it without your approval.

   1. If the repository or project belongs to someone else (a client), get written permission first. Do not scan without permission; do not open or export live user data.
   2. On one page, write down: the repositories to check, the Supabase project, the domain, the hosting and the monitoring account.
   3. Pick an owner for each item and decide where the fix list file for the findings will live.
   4. Write down now who will rotate keys on which account if a key leaks, and which email address alerts will go to.
   5. When recording findings, write the key's type, file and commit number, not the key itself. Do not paste the key value into the list, an email, a chat, a support form or an AI assistant.

   How you know it worked

   • A one-page scope list with owner names and the alert email address is written down.
   If you get stuck: problems specific to this step

   • It is unclear who is responsible, and everyone leaves it to someone else
     Put a single name on every finding; the person with permission to rotate keys must be on the list.
   • Nobody knows which accounts use which key
     First check the API Keys section in the Supabase Dashboard and the environment variables in your hosting panel, and add what you find to the list.
   Based on: GitHub Docs: Removing sensitive data from a repository, Supabase Docs: API keys
2. Step 2 · In an app

   Download a specific version of TruffleHog

   I finished this step

   What for: Run the scan on your own computer without creating an account.

   !You check this step yourself; the system should not move past it without your approval.

   1. Open v3.99.2 on the TruffleHog GitHub releases page. Download trufflehog_3.99.2_windows_amd64.tar.gz for Windows, or the matching archive for macOS and Linux.
   2. Find the archive's SHA256 value in the checksums file on the same release page. On Windows, compute your file's value with the Get-FileHash command below and compare the two; upper/lower case does not matter, but the characters themselves must match (the sha256sum command in the README is for Linux and macOS).
   3. This comparison shows the file was not corrupted during download; it does not prove the publisher's identity, because both come from the same release page. The README also explains how to verify the checksums file's signature with Cosign; this guide does not set that up.
   4. Extract the archive, put the trufflehog program in a separate tools folder and make sure you can run it from the terminal. Do not use the path that downloads and directly runs an install script.
   WindowsFolder: The folder where you downloaded the archive

   › Get-FileHash .\trufflehog_3.99.2_windows_amd64.tar.gz -Algorithm SHA256Copy

   How you know it worked

   • Typing trufflehog in the terminal shows the list of commands.
   • The SHA256 value of the file you downloaded matches the one in the checksums file (ignoring letter case); this only shows the download was not corrupted.
   If you get stuck: problems specific to this step

   • Windows cannot open the archive
     The file is in .tar.gz format; use an archive program that can open it, or ask for help. The README also describes running it with Docker, but that requires installing Docker.
   • The terminal cannot find the trufflehog command
     Run it with the full path from the folder where the program is, or add the folder to your system path.
   Based on: TruffleHog README, TruffleHog v3.99.2 release, Microsoft Learn: Get-FileHashGet help with this step →
3. Step 3 · In the terminal

   Scan the repository history and build files for secret keys

   I finished this step

   What for: Look for keys and passwords left in the code, in old commits or in the build output.

   !You check this step yourself; the system should not move past it without your approval.

   1. BEFORE YOU RUN IT: The default commands (1 and 3) connect to the relevant service's API to verify each key found (the README gives the example of a GetCallerIdentity call for AWS). This means a real key that is found gets tried against that provider from your computer and may leave a trace in the provider's logs; since command 3 scans the .env file, the project's live keys are included too. Do not do this on a repository that belongs to someone else.
   2. If you do not want keys to be tried externally, use commands 2 and 4 (both include --no-verification).
   3. Command 1 (git history) and command 3 (files) run with no extra options: they show all verified, unverified and unknown results. Commands 2 and 4 turn verification off; in that case every finding shows as 'unverified', which is normal. Do not combine the no-verification commands with --results=verified,unknown: with verification off, the findings can be filtered out, the output can look empty and you may think it is 'clean'.
   4. Result types: verified means the key is valid and active on the service (the most urgent); unverified means a key-like value was found but TruffleHog could not confirm its validity with the provider (it may be invalid or real, so review each one); unknown means verification could not be done because of a network or API error (retry and review).
   5. Commands 3 and 4 scan uncommitted files and the build output, not the git history (for example .env and the build folder). The git scan does not see these files. Change the folder names to match your own project.
   6. The terminal output prints the key's full value on screen. Do not share the output, a screenshot or the key with anyone (including support, chat or AI). Write only its type, file and commit number in the list. Treat every real key you see as exposed and rotate it.
   7. An empty result does not mean 'no leaks'; the scan cannot catch every type.
   Windows · macOS · LinuxFolder: The project folder to scan

   › trufflehog git file://.Copy

   Windows · macOS · LinuxFolder: The project folder to scan

   › trufflehog git file://. --no-verificationCopy

   Windows · macOS · LinuxFolder: The project folder to scan

   › trufflehog filesystem .env distCopy

   Windows · macOS · LinuxFolder: The project folder to scan

   › trufflehog filesystem .env dist --no-verificationCopy

   How you know it worked

   • When the scan finishes, the terminal lists the findings or shows a summary if there are none.
   • You sorted the findings by type and added them to your list without writing the key values.
   If you get stuck: problems specific to this step

   • No findings came up, but you know you put a key in at some point
     Rotate that key anyway; the scan cannot catch every type. Also check uncommitted files and the build output with command 3 or 4.
   • There are a lot of findings
     Review verified results first, then unverified and unknown; note fake values in test and example files as 'not an issue' in the list, but do not delete them.
   • Command 3 or 4 says the file was not found
     Replace the .env and dist names in the command with your project's real file and build folder names; the README shows that the filesystem command accepts one or more paths.
   Based on: TruffleHog READMEGet help with this step →
4. Step 4 · In the browser

   Check GitHub's secret scanning alerts and push protection

   I finished this step

   What for: Know where new leaks will show up and which protection applies to your repository.

   !You check this step yourself; the system should not move past it without your approval.

   1. Check whether the repository is public or private. If it is public, secret scanning runs automatically and for free; you see the alerts in the repository's 'Security and quality' tab. If the repository is already public, treat every key that ever got into it as exposed. GitHub's scanning does not undo a past leak and does not replace the TruffleHog scan.
   2. If your private repository belongs to an organization, check whether GitHub Secret Protection is enabled; according to the documentation, scanning on private repositories comes with this product and requires a Team or Enterprise plan. According to the documentation, secret scanning on private repositories owned by a personal account exists only on Enterprise Cloud with Enterprise Managed Users (or on Enterprise Server when Secret Protection is enabled); it is not available on an ordinary personal private repository.
   3. A private repository on a personal account has no GitHub scanning; for that repository you rely only on your own TruffleHog scan, which does not catch every key either.
   4. Push protection at the personal account level and push protection at the repository level are separate features: the personal one is on by default and blocks you from pushing keys to public repositories; the repository-level one requires Secret Protection and is off by default.

   How you know it worked

   • You noted which screen shows the alerts for your repository and which protection is enabled.
   If you get stuck: problems specific to this step

   • Your repository has no secret scanning section
     The repository may be private with Secret Protection off, or your account may not be covered by this feature; in that case run the TruffleHog scan regularly and let the person who makes purchasing decisions know.
   • You bypassed push protection, thinking 'I'll fix it later'
     According to the documentation, this choice creates an open alert; rotate the key before closing the alert.
   Based on: GitHub Docs: secret scanning, GitHub Docs: push protection, GitHub Changelog: push protection for free users (February 29, 2024), GitHub Docs: GitHub Advanced Security (Secret Protection purchase requirements)Get help with this step →
5. Step 5 · In the browser

   If a key leaked, rotate it; do not just delete it

   I finished this step

   What for: Make sure the leaked key no longer works for anything.

   !You check this step yourself; the system should not move past it without your approval.

   1. Identify which service the leaked key belongs to. Close off the cause of the leak (wrong file, public repository); otherwise the new key will leak too.
   2. Order: 1) create a new key in the service's panel, 2) replace it everywhere it is used (server, hosting environment variables, automations), 3) check that every component works with the new key, 4) only then revoke or delete the old key. Do not turn off the old key before the new one works.
   3. According to GitHub's documentation, the first step is to revoke or rotate the key; deleting the Git history is not enough, because other people's copies and forks remain.
   4. If a Supabase secret key leaked, the same order applies; for the legacy JWT-based service_role key, you disable the legacy keys in the same section instead (this can be undone).
   5. It makes sense to check the leaked key's usage and access logs on the service, but the Supabase documentation does not explain where to look after a leak. If you cannot find the service's log or usage screen, or you see something suspicious, show it to an expert. Seeing nothing in the logs does not mean 'no problem'.

   How you know it worked

   • The old key was revoked in the service panel (for Supabase legacy JWT keys this means a reversible disable, not a deletion).
   • The site and app keep working with the new key.
   If you get stuck: problems specific to this step

   • Part of the site stopped working after you deleted the old key
     This means you skipped a component during rotation; the Supabase documentation says to check that everything has moved to the new key before deleting the old ones. That is why you should first disable the legacy key and keep it in a state that can be re-enabled.
   • The key has been sitting in a public repository for a long time
     Assume it has been used; after rotating, check the service's log screen if you can find it, and if you cannot, or you see anything unusual, ask for an expert review. No visible log entries does not mean you are safe.
   Based on: GitHub Docs: Removing sensitive data from a repository, Supabase Docs: API keysGet help with this step →
6. Step 6 · In the browser

   List the state of user data in Supabase (this is not proof of security)

   I finished this step

   What for: See and list the current state: which tables have RLS off, where the secret key is stored, which findings need to be shown to an expert.

   !You check this step yourself; the system should not move past it without your approval.

   1. In the Supabase Dashboard, check the API Keys section under Settings. Only the publishable key (starting with sb_publishable_) should go into the browser or the mobile app; the secret key starting with sb_secret_ should stay only on the server. With the legacy keys, anon and service_role are both long JWTs that start with eyJ, so you cannot tell which is which by looking at the value.
   2. Read which one is which from its label (anon or service_role) in the legacy key list in the Dashboard.
   3. If you find a value starting with eyJ in the site's build files, compare it character by character with the values in the Dashboard's legacy key list; service_role or sb_secret_ must not be in the client, while anon and sb_publishable_ are normal there. If you cannot tell which one it is, show it to an expert without pasting the value anywhere.
   4. Open the Security Advisor in the Supabase Dashboard and read each finding one by one. Do not dismiss a finding without understanding what it means.
   5. Run the read-only query below in the SQL Editor: it lists ALL tables in the public schema; those where the rowsecurity column is false are tables with row-level security (RLS) turned off, and true only tells you RLS is turned on. A table with RLS off can be read and written by every role that has access to it. Write the tables holding user data on your list; if other schemas are exposed to the API, look for those too.
   6. The query does not show partitioned or foreign tables, or the forced RLS (FORCE) status.
   7. What this query does not show: RLS being on does not mean every row is protected. A loose policy (for example, a rule that lets the anon role read every row), views and functions that bypass RLS, and Storage buckets do not appear in this query and are outside the scope of this guide. Show every table and policy you consider risky to an expert.
   8. Do not make changes in the live database, and do not add test users or test records to production. Leave the fix to the person who built the app.
   9. The two-user test this guide suggests (which the Supabase documentation does not walk through step by step) is done with the person who built the app, in a separate test project. Setting up the test project is outside the scope of this guide and is done by the person who built the app: they set up the same tables and policies (via migration files) in a separate Supabase test project; if there are no migration files, this path is not ready.
   10. Do not copy real user data into the test project. If the Supabase CLI is used, check which project it is linked to before pushing anything; pushing changes while accidentally linked to the live project breaks production. In the test project, create two test users, add a record with the first, then try to read and modify that record with the second and with an unauthenticated request. This test shows only the scenario you tried.
   11. Even if the test passes, it does not show that the system is secure. A local Supabase copy can also be used, but that is advanced and requires Docker.
   rls-durumu.sql (read-only query) · sqlCopy

   select schemaname, tablename, rowsecurity
   from pg_tables
   where schemaname = 'public'
   order by tablename;

   Read-only. Lists all tables in the public schema; rows where the rowsecurity column is false are tables with row-level security turned off.

   How you know it worked

   • You wrote the RLS status of every table holding user data, and the ones you consider risky, on your list.
   • You recorded the results of the scenarios you tried in the test project as 'scenario tested'.
   If you get stuck: problems specific to this step

   • You want to set up the Supabase stack for local testing, but you do not have Docker
     This path is optional and advanced: according to the documentation, the local stack runs in Docker containers. Before installing Docker Desktop, check that your company size fits the license terms (it is defined as free for small businesses with fewer than 250 employees and less than $10 million in revenue), or run the test in a separate Supabase test project.
   • RLS is on, but no data comes from the table
     According to the documentation, once RLS is turned on, no data comes through the API until a policy is written; this is expected behavior, and the person who built the app defines the policy.
   Based on: Supabase Docs: Row Level Security, Supabase Docs: API keys, Supabase Docs: database testing, PostgreSQL documentation: the pg_tables view, Supabase Docs: local development with the CLIGet help with this step →
7. Step 7 · In the browser

   Review your deployment settings (Cloudflare only if you need it)

   I finished this step

   What for: See that keys are stored in the right place and that domain protection does not break the app.

   !You check this step yourself; the system should not move past it without your approval.

   1. Check the environment variables in your hosting panel: secret keys should live only on the server side, as environment variables; they must not go into source code, CI scripts or files sent to the browser.
   2. Check that keys are not shared over chat, email or SMS; the Supabase documentation explicitly forbids this.
   3. If your domain is already on Cloudflare (this guide does not cover moving a domain to Cloudflare; if you plan to, read Cloudflare's own documentation and export your existing DNS records first): the Free plan is described as for personal and non-business-critical projects; for a commercial site, weigh your plan choice with Cloudflare. The plans page lists DDoS protection, WAF and 'simple bots' bot protection on the Free plan.
   4. Note the current setting before turning on Bot Fight Mode. If you turn it on, JavaScript Detections is turned on automatically and cannot be turned off; if you use a Content Security Policy, you need to allow Cloudflare's /cdn-cgi/challenge-platform/ path. According to the documentation, JavaScript Detections is not supported with a CSP whose nonce is set via a <meta> tag. The mode can challenge API or mobile traffic and cannot be bypassed with WAF rules.
   5. After turning it on, test login, forms, payment returns, webhooks, Supabase function calls and email links.
   6. If something breaks, go to Security > Settings in the Cloudflare dashboard, filter by 'Bot traffic', turn off Bot Fight Mode and go back to the previous setting.
   7. If you do not use Cloudflare, skip the Cloudflare part of this step; the basic check does not require Cloudflare.

   How you know it worked

   • The locations of the secret keys are written on your list, and there are no secret keys in the source code.
   • If you use Cloudflare, the Bot Fight Mode status and the fact that the app still works are noted.
   If you get stuck: problems specific to this step

   • After enabling Cloudflare, the app's API calls, webhooks or payment returns are being rejected
     According to the documentation, Bot Fight Mode can challenge API and mobile traffic and cannot be bypassed with a WAF rule. First turn the mode off and confirm the problem goes away; for more granular control, Cloudflare recommends Bot Management for Enterprise, which means there is no fine-tuning on the Free plan.
   • You do not know which environment variable holds the key
     Open the environment variables section in your hosting panel and look at the names; if you cannot find out who wrote it, rotate the key and set the variable again.
   Based on: Supabase Docs: API keys, Cloudflare: Network and CDN plans, Cloudflare Docs: Bot Fight ModeGet help with this step →
8. Step 8 · In the browser

   Run an accessibility audit and set up uptime monitoring

   I finished this step

   What for: See the site's usability issues and find out if it goes down.

   !You check this step yourself; the system should not move past it without your approval.

   1. Open the site's key pages in Chrome, open DevTools and run the Accessibility category from the Lighthouse tab. Write the issues it finds on your list; Lighthouse also lists 'manual checks' items you need to review by hand, so check those separately.
   2. In Better Stack, choose Create monitor from the Monitors section, enter the site's address and set up an HTTP status code check (the documentation says a 2XX success code is expected). The documentation does not describe redirect behavior; if you get alarms, check the status code the monitor shows and enter the final address if needed. Set the alert option in the 'How should we escalate incidents?' section.
   3. Choose email or Slack as the alert channel ('Slack & e-mail alerts' is listed on the free plan). The alert should go to the owner named on the scope page.
   4. To test alerts, do not break the live monitor's address: create a separate temporary test monitor with an address that does not exist, confirm the alert reaches the owner, then delete the test monitor.
   5. If you want to collect in-app error and performance data, consider SigNoz as further reading; the basic check does not require it.

   How you know it worked

   • The results of the Lighthouse accessibility report were added to your list.
   • There is an active monitor in Better Stack, and the test alert reached the owner.
   If you get stuck: problems specific to this step

   • It is unclear whether the Better Stack free plan is suitable for a business site
     The pricing page describes the free plan as for personal projects; for business use, ask Better Stack or choose a paid plan.
   • The alert email did not arrive
     Check your spam folder first, then check the monitor's alert channel and email address in Better Stack.
   • The site has a redirect and the monitor raises an alarm
     The documentation does not describe redirect behavior; check the status code the monitor shows and, if needed, enter the final address after the redirect.
   Based on: Chrome for Developers: Lighthouse overview, Better Stack Docs: getting started with monitoring, Better Stack pricingGet help with this step →
9. Step 9 · In an app

   Turn the findings into a fix list with owners and dates

   I finished this step

   What for: At the end of the check, the work to be done and its limits are clear.

   !You check this step yourself; the system should not move past it without your approval.

   1. Collect the findings from the previous steps in one list: finding, location, priority (leaked keys that are still valid at the top), owner and target date.
   2. Do not write the key itself on the list; write its type, location and commit number. When sharing the list, findings or terminal output with a support service, make sure they contain no key values.
   3. For every item that cannot be fixed or that you are unsure about, write 'needs expert review'.
   4. At the bottom of the list, write this note: 'This is a basic pre-launch check. It is not a security certification or a penetration test, and it does not show that the system is secure.'
   5. Repeat the check before launch and after major changes; add the date to the list.

   How you know it worked

   • Every finding on the one-page list has an owner and a date.
   • The limitations note is written at the end of the list.
   If you get stuck: problems specific to this step

   • The list is very long and it is unclear where to start
     Start with valid key leaks, then user data left publicly accessible, then monitoring and accessibility issues.
   • You are not sure whether a finding is a real risk
     Do not close it yourself; read the relevant service's documentation or ask for an expert review, and mark it 'under review' on the list.
   Based on: GitHub Docs: Removing sensitive data from a repository, Supabase Docs: API keysGet help with this step →

What you pay for

The items are separate, not a total; which ones you need depends on the path you set up. Prices change, so check the source of each item.

• No costTruffleHog

  AGPL-3.0 open source; the documentation lists no fee for using it. source

• SubscriptionGitHub Secret Protection

  For organization projects on private repositories, secret scanning comes with this product and requires a GitHub Team or Enterprise plan; the price is on GitHub's billing page. source

• SubscriptionGitGuardian ggshield (alternative)

  The pricing page lists the Starter plan at $0, for up to 25 developers and 10,000 API calls per month. The comparison table says 'Limited' for the ggshield CLI; the page does not make clear which plan column this belongs to. Personal/commercial use terms are not stated on the page. (October 17, 2026) source

• SubscriptionBetter Stack monitoring

  The free plan includes 10 monitors and heartbeats, and Slack and email alerts, and is described as for personal projects; for a business, check the plan terms with Better Stack. source

• SubscriptionCloudflare (only if your domain is there)

  The Free plan is $0 and described as for personal or non-business-critical projects; higher plans are paid. (October 17, 2026) source

• SubscriptionDocker Desktop (only for local Supabase testing)

  Free use condition: a small business with fewer than 250 employees and less than $10 million in annual revenue; larger ones need a paid plan. (October 17, 2026) source

• Setup serviceConfiguration and fix support

  You can get support from DijiKoçum to fix the issues found and configure the settings. Independent penetration testing and expert security review are not part of this service; if needed, you are referred to a separate expert.

• SubscriptionSeparate Supabase test project (only for the two-user test)

  The free plan's project limit or cost is not stated here; check Supabase's plans and pricing page before creating a test project. source

Sources

• GitHub Docs: secret scanning · Official documentation · read October 17, 2026
• GitHub Docs: push protection · Official documentation · read October 17, 2026
• GitHub Changelog: push protection for free users (February 29, 2024) · Vendor page · read October 17, 2026
• GitHub Docs: GitHub Advanced Security (Secret Protection purchase requirements) · Official documentation · read October 17, 2026
• GitHub Docs: Removing sensitive data from a repository · Official documentation · read October 17, 2026
• TruffleHog README · Source code · read October 17, 2026
• TruffleHog v3.99.2 release · Source code · read October 17, 2026
• GitGuardian pricing · Vendor page · read October 17, 2026
• ggshield README · Source code · read October 17, 2026
• Supabase Docs: Row Level Security · Official documentation · read October 17, 2026
• Supabase Docs: API keys · Official documentation · read October 17, 2026
• Supabase Docs: database testing · Official documentation · read October 17, 2026
• Supabase Docs: local development with the CLI · Official documentation · read October 17, 2026
• PostgreSQL documentation: the pg_tables view · Official documentation · read October 17, 2026
• Cloudflare: Network and CDN plans · Vendor page · read October 17, 2026
• Cloudflare Docs: Bot Fight Mode · Official documentation · read October 17, 2026
• Docker Docs: Docker Desktop license · Official documentation · read October 17, 2026
• Chrome for Developers: Lighthouse overview · Official documentation · read October 17, 2026
• Better Stack pricing · Vendor page · read October 17, 2026
• Better Stack Docs: getting started with monitoring · Official documentation · read October 17, 2026
• Strix README · Source code · read October 17, 2026
• Microsoft Learn: Get-FileHash · Official documentation · read October 17, 2026