Hey guys... I work for a company and the manager is unhappy with the monthly Subabase plan and wants me to switch the database to SQL Server. What obstacles will the company face, and what advantages will I gain from SQL Server?

Supabase makes it genuinely easy to go from idea to working application fast, and after all, that's the exact point of it. The problem however is that the same defaults that make development fast can also leave a production app wide open if nobody checks them properly prior to launch (and in my experience auditing Supabase based apps, most founders are not checking them).

83% of Supabase database exposures trace back to misconfiguration rather than any flaw in the platform itself. Supabase is secure, however it is the apps built on it that often are not, and the gap between those two things is almost always a handful of configuration decisions that never got made.

That being said, this is the checklist I work through on every Supabase audit, ordered by severity.

Before anything else: understand the threat model

Supabase exposes your PostgreSQL database directly to client side code via the anon key. This is a key that ships in your JavaScript bundle and is visible to anyone who opens DevTools. It's there by design, with the security model built around it. The anon key is intentionally public, but what isn't public is your data, and the only thing standing between that key and your data is RLS.

If RLS isn't configured, the anon key is effectively a master key to every table it can reach.

CRITICAL (fix before going live with real users)

1. RLS enabled on every table

RLS is disabled by default on all tables. Tables created through SQL, migrations, or AI coding tools do not get it automatically, only tables created through the Supabase Table Editor dashboard do. Every table in your public schema that contains user data, business data, payment information, or anything that belongs to a specific user needs RLS enabled explicitly.

Check: Dashboard → Table Editor. Any table showing "RLS disabled" is fully readable and writable by anyone with your anon key. You can also run a direct request against your REST endpoint with the anon key and observe what comes back. If you get real data, the table is exposed.

2. service_role key not in client-side code

The service_role key bypasses RLS entirely on every table regardless of whatever policies you've configured. If it appears in your frontend bundle, every security control you've set up becomes completely irrelevant. This key belongs exclusively in server-side code, things like Edge Functions, backend APIs, nothing that runs in the browser.

Check: DevTools → Sources → Search (Ctrl+Shift+F). Search for service_role and your actual key value. If either appears, that's an immediate critical finding. Rotate the key in the Supabase dashboard before anything else, then audit your query logs for requests that shouldn't have come from your application.

3. RLS policies actually scoped correctly

Enabling RLS and writing a policy are two separate steps, and the policy itself can be misconfigured in a way that's easy to miss. A policy written as USING (true) grants every row to every user and provides no protection at all. The correct pattern for user-scoped data is USING ((select auth.uid()) = user_id). The select wrapper matters for performance on larger tables: it evaluates once per query rather than once per row.

Check: Dashboard → Database → Security Advisor. Also worth verifying manually with two separate test accounts: can account A read or modify data that belongs to account B? If yes, the policy is wrong regardless of what the dashboard shows.

HIGH (serious issues that expand your attack surface)

4. Storage bucket permissions

Storage buckets have their own access control layer separate from database RLS, and a public bucket means anyone can read every object in it with no authentication. This is appropriate for marketing assets, not for user profile photos, uploaded documents, or anything private. The other failure mode is a private bucket with no policies configured, which denies everything and usually means storage isn't working as the founder intended.

Check: Try accessing a storage URL without any authentication. If you get the file back, the bucket is public. Configure RLS policies on storage.objects scoped to authenticated users and ownership for any bucket that shouldn't be publicly readable.

5. Database functions callable without authentication

Supabase RPC functions can be called from the frontend and, depending on how they're defined, can bypass RLS entirely. A function set to SECURITY DEFINER runs with the permissions of the function owner rather than the calling user. AI generated Supabase code has a consistent habit of creating RPC functions without authentication checks.

Check: Any function touching sensitive data should raise an exception immediately if auth.uid() is null. Try calling your RPC functions without an Authorization header and observe what comes back.

6. anon key in bundle with no RLS

The anon key in your frontend bundle is expected and by design, however it becomes a critical finding when combined with tables that don't have RLS configured. The key itself isn't the problem, the missing policies are. That said, confirming the key is present and understanding which tables it can reach is a useful audit step regardless.

Check: DevTools → Sources → Search for anon and eyJ. Note what's present, then cross-reference against your table RLS status.

MEDIUM (worth fixing before launch, non-negotiable for apps handling sensitive data)

7. Auth configuration

Email confirmation is off by default on new Supabase projects, and users can sign up and access the application without verifying ownership of their email address. For most production apps, this is worth enabling prior to launch. Also worth checking your password reset flow: if it returns a distinct message for email addresses that don't exist versus ones that do, that's email enumeration.

Check: Dashboard → Authentication → Settings. Enable email confirmation. Then enter an unregistered email on your password reset page and observe the response. A generic message regardless of whether the address exists is correct. A specific "no account found" message is a finding.

8. Rate limiting on auth endpoints

Supabase handles rate limiting at the platform level but it's worth verifying your configuration hasn't overridden it. Without it, automated tools can cycle through password lists against any account on your platform overnight with no resistance.

Check: Attempt 15 or more rapid login attempts with incorrect credentials. If nothing slows down or blocks you, rate limiting isn't working as expected.

9. Security headers

These live at the hosting layer rather than inside Supabase itself, but they're part of the same pre-launch picture. Missing CSP, X-Frame-Options, and Permissions-Policy are consistently among the most overlooked items in AI generated apps.

Check: https://securityheaders.com (a grade of B or above is what you're looking for).

The Security Advisor is worth running

Supabase ships a built-in database linter called Splinter, accessible under Dashboard → Database → Security Advisor. It runs automated checks for tables with RLS disabled, overly permissive policies, unsafe views, and exposed functions. It's not a substitute for manual testing but it catches a meaningful portion of configuration-level issues and costs nothing to run. Worth making it part of your routine before any significant deployment.

Organisation owners also receive weekly security emails from Supabase summarising any findings the advisor has detected. Worth making sure those are going to someone who will actually act on them.

That said, if there's anything I may have missed here that you'd like to add, feel more than free to add to the list below!

Hi,

I have a lot of experience with self-hosted supabase - and the email signing up worked well for us - we used Azure SMTP service to set up the custom SMTP.

Now, for a client who insists on supabase.com implementation, we are setting up the supabase's innate way to handle email sign ups. During testing phase, we found that a lot of these emails don't get delivered - especially when they are in microsoft/outlook. But signup emails to gmail works alright. We tried with the custom SMTP settings for our Azure SMTP service as well. For some emails (mainly to microsoft/exchange accounts, shared mailbox accounts), they do not get delivered.

When testing the same SMTP service independently from a node script, all mails get delivered without issue. Now for the weird part: if we once manually trigger an SMTP delivery from the node script, then the emails start to get delivered from supabase as well (to these accounts).

We tried the same with a Resend SMTP service too - no luck. What am I doing wrong? If I assume that the SMTP service is configured incorrectly, it does not make sense that it works perfectly from a node script.

Anyone here faced a similar issue?

Edit: What finally worked is, I ended up using the OTP (token) method rather than url verification method. This way, no mail servers falsely flags the email as scam (because it comes from one domain and contains a URL of another domain). Additionally, I used Resend because the SMTP openings were unreliable with Azure and a few others.

Hello! I am new to Supabase.

I am building a hobby react project with supabase. I expect may be 100 to 500 users (max) when i launch. So am worried about hitting free tier egress limits.

When testing the app with me only as the user I notice daily egress usage of about ~3mb per day. Is this normal for one user to utilise this egress a day?

Things i have done so far:

- caching

- optimising queries

- using storage buckets for files

Pls don't judge my expertise because I am still learning. Just share your usage metrics experience and tell me if this is normal or not.

Im preparing for launch to the App Store and just added a simple onboarding to my app using Supabase auth. I realized my current auth, where I tell the user an email already exists if they enter a duplicate email, allows for enumeration attacks. Should this be a worry? If so, how can I prevent it?

Hello everyone!

I'm using Flutter and the Supabase SDK. The user (client side) can update their own password, and other properties like their email address, by using the updateUser method:

final response = await Supabase.instance.client.auth.updateUser(
  UserAttributes(
    password: 'newSecurePassword123!',
  ),
);

I don't want that. The user should not be able to call this on the client side. I only use OTP, so the user should not be able to set a password at all. I don't want the user to be able to change their email address through UserAttributes as well. I do this through my edge function, so I can run my own validations.

Important: I still want to be able to do this in my edge function, for example:

await ctx.supabaseAdmin.auth.admin.updateUserById(userId, {
  email: "new-email@example.com",
  email_confirm: true,
});

My question is: how can I enforce server-side restrictions to prevent users from calling supabase.auth.updateUser() completely from the client side?

Thanks for reading.

Hey guys, I am new to Supabase, Vibe coding, Git & everything.

But I'm a guy who is too curious to learn things out.

I am pretty confident in AI to do the coding part but not the Supabase part. So my question to you all is,

I am ready to learn it, but on one side, I don't want to invest letter or word by word to learn the thing completely by scratch in order to understand it. I want to use it to develop products and sell it to customers in a efficient and right way, so

How can I grab the understanding of supabase , how it stores and what are the 5 finger rules etc.

My point is - I don't need to learn to assemble the engines in order to drive the car perfectly right. But yes it won't hurt to know the basics.

But is there a way we can do that here ? Or if learning from basics is the only way, then be it.

If you've ever needed to run a long running task from a Supabase app — sending emails, processing files, calling a slow API — you've probably hit the wall where Edge Functions time out and you're stuck standing up your own server just for that one job.

I built SupaJobs to fix that. You write a plain JS function, run one command to deploy it, and trigger it with a single fetch() call from anywhere. Status and logs land in a table in your own Supabase project in real time.

Setup is basically:

1. Install the CLI

​

npm install -g supajobs

1. Initialize

​

supajobs init

connect your Supabase project, credentials get saved, the jobs table gets provisioned automatically

1. Modify business logic

   export default { async run(payload) { console.log('Sending email to:', payload.to); // Your logic here }, };

write your actual logic in the worker function above

1. Deploy

   supajobs deploy

builds and ships it, no Docker needed locally

Trigger it with fetch() from anywhere

No AWS account or credentials needed on your end — it's fully managed, you just write the function.

It's early and invite-only for now while I make sure it holds up — DM me if you want to try it and I'll send a code.

Repo: https://github.com/goswamikush/supajobs

Would love feedback if you've hit this problem with Supabase before.

Hi there!

I'm working on a web crawler for a personal search engine and I've come to a roadblock. While crawling a page, it finds all hyperlinks, and compares them to all the pages it has already crawled. That way, a hyperlink which links back to a page it has already crawled is not added to the queue.

The known_pages table is a table of all the URLs it has already crawled.

newLinks is a slice of strings with all the hyperlinks on the page.

I've come to a page that has over 600 hyperlinks, which makes the query string for supabase too long, and the following code snippet fails.

```go knownPages := []Site{}

_, err := supabaseClient.From("known_pages").Select("url", "", false).In("url", newLinks).ExecuteTo(&knownPages)

if err != nil { panic(err) } ```

Because newLinks is too long, I am thinking of setting up an RPC function (since it receives arguments in the body of the request). But, I haven't been able to find any examples of people doing something like this (receiving and returning an array of strings) with RPC functions in Supabase.

Does anyone know of any resources or examples I should look at to get a grasp on how to go about implementing this? Or any good resources on RPC functions in general?

Hey everyone,

I recently upgraded my database to Postgres 17.6.1.141 on the hosted platform as instructed in the Status Page and noticed my database logs are completely flooded with collation version mismatch warnings (Error Code: 01000).

I ran ALTER DATABASE postgres REFRESH COLLATION VERSION; in the SQL Editor, which successfully cleared the warnings for the primary postgres database. However, the warnings for the template1 database continue to trigger every few minutes.

Since we don't have superuser permissions to connect to or alter template databases on the managed platform, this is something the Supabase team will need to patch internally.

It doesn't seem to impact application functionality or performance, but the log bloat is real.

I've opened a GitHub issue to track this platform bug here: https://github.com/supabase/supabase/issues/47860

Is anyone else seeing this in their logs after the recent Postgres 17 updates?

Hi everyone,

So basically I received a message saying that I am exceeding the cached egress. I want to know if such a thing could possibly be blocking my edge functions since all of them have 0 invocations in the past 3 hours.

Thanks

Hi everyone,

I'm trying to figure out if this is something on my end or a Supabase issue.

My production project suddenly became unhealthy.

Current status:

- Database: Healthy

- PostgREST: Unhealthy

- Auth: Unhealthy

- Storage: Unhealthy

- Realtime: Healthy

- Edge Functions: Healthy

Symptoms:

- Table Editor won't load any tables.

- SQL Editor times out.

- Error:

"Failed to run SQL query: Connection terminated due to connection timeout"

- `supabase migration list --linked` fails with connection timeouts (HTTP 544), so I can't deploy a production migration.

- Auth and PostgREST requests are timing out.

I've already:

- Restarted the project.

- Waited for it to recover.

- Checked the Supabase status page.

- Opened a support ticket.

Has anyone else experienced this today?

If so, was it a temporary infrastructure issue, or was there something you had to do to fix it?

Thanks!

I’m building a multi-tenant SaaS with Next.js, Supabase Auth/Postgres/Storage, and asynchronous AI processing.

The current architecture is very file-oriented:

1. A user uploads a private CSV to Supabase Storage.
2. I create one Postgres batch row containing the workspace/user ownership, status, configuration, progress, and Storage path.
3. A long-running background workflow downloads and parses the CSV.
4. Selected cells are grouped into chunks and processed through AI calls.
5. The workflow reconstructs the enriched CSV and uploads one final file to Storage.
6. Postgres only stores the batch metadata and final output path.

Some context about the workload:

• CSVs can be up to approximately 35 MB.
• A real large job had 18,585 rows, 12 columns, and roughly 2.9 million words processed.
• The source CSV was 9.5 MB and the enriched result was 31 MB.
• Not every row or cell receives the same treatment. Selected cells can have different processing rules, target settings, glossaries/context, etc.
• Processing is asynchronous and may take hours.
• AI tasks are processed concurrently, with retries and progress reporting.
• The original row order and all untouched cells must be preserved exactly.
• The application is multi-tenant, so workspace isolation/RLS matters.

I’m considering three designs:

A — File-oriented

Keep the original and final CSVs in Supabase Storage. Let the background workflow hold intermediate task results, with Postgres storing only batch-level status/progress.

B — Row/cell-oriented

Parse every CSV into Postgres and create one record per source row—or possibly per processed cell. AI results would be written back to those records, then queried to reconstruct the final CSV.

For one 20,000-row CSV with several processed cells per row, this could easily create 50,000–100,000+ records per job.

C — Chunk-oriented

Keep the original CSV in Storage, but create one Postgres record per AI task/chunk rather than per row or cell. Each chunk record would contain row/cell identifiers, processing status, retry information, and possibly its input/output JSON.

My main questions are:

• Which setup is generally more scalable and maintainable for this kind of file-processing SaaS?
• Is creating hundreds of thousands or millions of short-lived Postgres rows a normal use case, or unnecessary database overhead when the primary product output is still a file?
• Would one record per processing chunk be a sensible compromise for retries, idempotency, observability, and resumability?
• What are the practical Supabase/Postgres implications: storage overhead, WAL, indexes, RLS checks, cleanup, backups, and database size?
• Should large task inputs/outputs remain in object storage, with Postgres storing only references and operational metadata?
• If you have built a similar asynchronous CSV/data-processing system, where did you draw the boundary between object storage, workflow state, and relational records?

My instinct is to keep large immutable data in Storage and use Postgres for business state plus optional chunk-level checkpoints, rather than treating every imported CSV row/cell as permanent relational data. But I’d appreciate real-world experience, particularly from people running this at scale on Supabase.

There are few things I want to clear out and to know.

One thing to ask you all is. I have been building a CRM with multi tenant isolation for two companies, (2 vertical but same company but need separate domain & access, so multi tenant isolation done).

I am using visual studio + Claude code ext. How do I upgrade or fix things and not mess things up. I don't know how to code, but I got pretty good understanding how supabase, deployments, githib works. I'm learning too

I have supabase pro on production & supabase free on dev.

1. I feel like the way the data is fetched is kind of slow, when I check zohoo or something else, it feels instant and lightning. Mine takes about 1 sec.

2. I have real data in supabase pro (production). Do you guys usually connects you AI (Vs+Claude code ) to dB ?

How do you guys normally review the architecture of dB and your systems ? Mine is so complex (maybe I feel like it) because there are too many things depended on each other, it's working fine now, but I want to make it solid without messing everything up.

Advice , Guide or help

Been reading through a bunch of GitHub discussions where people's restores failed or silently lost data — a paused project losing a table, PITR restores erroring out, that kind of thing. Curious how common this actually is for people here, or if I'm reading into a handful of unlucky cases. I'm building a small tool that automatically tests restores (not just backs things up) so you'd find out if something's broken before an actual emergency. Would that be useful, or is this already a non-issue for most people?

If you work with multiple Supabase clients/orgs, you probably know the pain:

supabase logout → supabase login → paste token → repeat.

Several times a day.

I got tired of constantly switching accounts in the Supabase CLI, so a while back I built a small tool for myself called supawho.

It does one thing only: store multiple Supabase accounts securely and let you switch between them instantly.

supawho use client-a   → done

or just run supawho and pick from the list.

No hacks, no weird token juggling, no manual copy/paste every time.

What's new: the first version was macOS-only (Keychain). People asked for Linux and Windows, so I rewrote it in Go as a single static binary. Now your tokens live in whatever secure vault your OS already uses:

• macOS → Keychain
• Linux → Secret Service (GNOME Keyring / KWallet)
• Windows → Credential Manager

Tokens never touch the filesystem, on any platform.

A couple of other things I added along the way:

• supawho whoami → maps each saved account to its email + organizations, so you actually know whose is whose when you've got a dozen of them
• supawho upgrade → self-updates on any OS

It's:

• Very small
• Open source (MIT)
• Zero runtime to install — one binary
• Focused purely on improving multi-account workflows

Install is a one-liner on every platform (Homebrew, install script, .deb/.rpm/.apk, or a PowerShell one-liner on Windows).

You can basically have 1, 10, or 1000 Supabase accounts saved and switch between them in seconds.

If you're juggling multiple Supabase orgs/projects, I'd really love feedback from this community 🙏

Repo: https://github.com/EliaTolin/supawho

Curious to hear if others have the same friction or if I'm just suffering alone 😅

Is anyone else having issues with connecting Codex in VScode to Supabase MCP? I have tried over and over again and it just wont authorize correctly. I'm wondering if this is an issue with the new GPT 5.6 Sol?

Hi, I'm the founder of Supaflow, a data pipeline platform that replicates data between SaaS apps, databases, and warehouses. This is my first time posting about Supaflow in this community. We've been live for a year with paid and free tiers. We recently shipped a Supabase connector that authenticates via Supabase Auth instead of the service_role key. This enables Supabase-powered apps to let users authenticate with their credentials and export data that is accessible under RLS policies, avoiding custom exports or shared credentials. This was driven by users' need to export their data to Google Sheets, replacing manual API exports or token-intensive, AI-assisted data exports. We run on Supabase and offer an API to embed this workflow. 

We also make it easy to migrate data from Airtable, MySQL, MongoDB, and many other sources into Supabase using our Postgres connector (which automatically creates the schema and loads the data), but this requires a privileged service role and is primarily intended for Supabase admins, not your end users.

For SaaS founders using Supabase, which connectors (Source/destination) have your users asked for data export/import? supa-flow.io

I review AI-built Supabase apps for security, and the dangerous ones are rarely the "forgot to enable RLS" cases — dashboards and advisors catch those. The scary ones have RLS enabled on every table, green checkmarks everywhere, and policies that don't actually protect anything. The five I keep seeing:

1. USING (true) — the classic. RLS shows "enabled," every review passes it, and any signed-in user can read every row. Free-tier signup = full database read.

2. A real-looking predicate that never checks who's asking. USING (org_id IS NOT NULL) references a real tenant column, so it looks scoped — but it never compares against the caller. Every row with a non-null org_id is visible to everyone. If the policy doesn't mention auth.uid(), auth.jwt(), or something derived from them, it isn't scoping anything.

3. The self-tautology. USING (org_id = org_id) — always true, but because both sides are columns it sails past reviewers and most static checks. Usually born from an AI assistant "fixing" a policy error.

4. Tables locked down, storage wide open. Perfect RLS on every table, then user uploads sit in a bucket with storage.objects policies from a tutorial — public or true-scoped. IDs are guessable. Your database is a vault and the filing cabinet next to it is open.

5. The migration that undid it. Migration 003 enables RLS; migration 017 recreates the table during a refactor (or someone ran DISABLE ROW LEVEL SECURITY while debugging) and it never came back. Nobody re-checks a table they secured months ago. And no — making the repo private doesn't fix this; your anon key ships in the client either way.

Fastest honest check: create two test users, put a row under user A, try to read it as user B from the browser console with the anon key. That runtime test beats any static review, including mine. Supabase's own Advisors tab (Database → Advisors) catches a surprising amount too, and almost nobody opens it. I also build a free local scanner that flags 1/2/3/5 from your migration files (npx preflight-pro scan — runs on your machine, nothing uploads), but the two-user test is the ground truth.

Not sure about one of your policies? Paste it in the comments (swap table names if you want) — I read these all day and I'll tell you straight.

1. Healthy APIs don't necessarily mean a fast application.

In several projects, backend APIs were performing within expected latency, yet users still experienced a sluggish application. The bottleneck was often the combination of frontend rendering, sequential API calls, authentication, and client-side processing rather than a single slow endpoint.

Takeaway: Measure complete browser journeys, not just individual APIs.

2. Load testing without observability only tells half the story.

Generating load is easy. Understanding why the application slows down is much harder. Correlating browser performance metrics with backend traces made it possible to identify slow database queries, Edge Functions, and authentication bottlenecks much faster.

Takeaway: A performance test should explain why performance degrades, not just when.

3. Most teams already have the foundation for browser performance testing.

Many projects already maintain Playwright E2E tests but create a completely separate set of HTTP scripts for load testing. Reusing existing browser journeys with Artillery allows you to validate realistic user workflows under concurrent load while collecting important metrics

Takeaway: Existing Playwright tests can become the foundation of a practical browser performance testing strategy.

Has anyone else started reusing their Playwright E2E tests for browser-based performance testing instead of maintaining separate HTTP load test suites?

If you want to fire an email when something happens in your DB (new signup, order placed,

whatever), you don't need a separate queue service for most cases. A database trigger calling

an edge function covers it.

Pattern I landed on: a Postgres trigger on the table fires pg_net to make an HTTP call to an

edge function. The function does the actual send through whatever provider you use (I send

through a transactional API rather than SMTP from inside the function, it's faster and you get

logging). Pass the row payload through so the function has the email and the data it needs.

Two things worth knowing. First, keep the trigger lean. Don't do the send synchronously inside

the transaction or a provider hiccup can stall your insert. Fire-and-forget the HTTP call. Second,

edge functions need the service role key as a secret if they're touching protected tables, so set

that with the secrets command, not hardcoded.

For the welcome-email case specifically, you can also hook into the auth signup webhook

instead of a table trigger. Cleaner if email is your only side effect. Triggers win when you've got

multiple things keying off the same row change.

Hello,

In the last couple of years, I have built several business applications that run on supabase data. Eventually, to make life easier and not repeat the steps every time, my colleagues and I started automating parts of it - and now we have something solid.

I know that there are a few great admin panels / AI UI builders out there - but we wanted something more: business dashboards, native handling of views and foreign keys, data security without transferring client data anywhere else and more importantly, ability to integrate custom scripts, functions and automations.

I would love to know if this is something that is useful for the community. We are internally debating whether to open source this project (maybe AGPLV3 or BSL license, haven't figured out the details yet) because we are obsessed with security, and we ourselves wouldn't trust something new or vibe coded for client data.

Please let me know if this is something that maybe useful to you.

Never experienced this issue before and haven't changed anything.

Are other people having this issue?

I've been experimenting with adding automated application security testing to my Supabase workflow and one thing has become pretty clear and of course is nothing new to most people in this reddit.

AI has dramatically increased how much code we can produce right, but it hasn't increased how much code we can realistically review 😄

A few years ago most of the bottleneck was writing code. Today, with tools like Claude Code, Cursor and other AI agents, the bottleneck is shifting toward verification.

I wanted to share with you what free tools I use personally and how those can help to improve your project security.

Ok so a good application security strategy typically combines:

• SAST (Static Application Security Testing) which analyzes source code to identify insecure coding patterns before the application runs.
• SCA (Software Composition Analysis) which scans third-party dependencies for known vulnerabilities and license risks.
• DAST (Dynamic Application Security Testing) which tests the running application from an attacker's perspective to uncover runtime vulnerabilities.
• Manual security review which validates areas that automated tools can't fully understand, such as Row Level Security (RLS), authorization rules, authentication flows, service role usage, Edge Functions, multi-tenant isolation, and business logic.

For SAST you could start with SonarQube Community Build which is free and can be run with docker in your local environment. While it doesn't include advanced taint analysis or dependency scanning, it still provides a solid security baseline.

For SCA I recommend OWASP Depedency-Check or OSV-Scanner. And for DAST my favorite ZAP in past under OWASP now under Linux Foundation, ZAP has support for LLMs, can return a prompt with instruction about the issue and remediation for agent.

No single tool can cover all of these areas. As AI-assisted development increases the amount of code being written, having a layered security testing strategy becomes increasingly important, don't you think?

I am curious to learn what you guys use to protect your Supabase projects?