Future React/Supabase patterns

[noelsaw1]

`rules:

• id: supabase-n-plus-one-query
  message: >
  Performance Alert: Potential "N+1" query detected.
  You are executing a Supabase query inside a loop (map/forEach).
  Instead of looping to fetch related data, use Supabase "embedding"
  to fetch children in the parent query (e.g., .select('*, posts(*)')).
  severity: WARNING
  languages: [ts, tsx, js, jsx]
  patterns:

  • pattern-inside: |
    $ARR.map(async ($ITEM) => { ... })
  • pattern: |
    await $CLIENT.from(...)

• id: supabase-service-role-leak
  message: >
  CRITICAL SECURITY: Service Role key usage detected in client-side code.
  Service Role keys bypass Row Level Security (RLS).
  Only use anon keys in React/Vite components.
  Move this logic to a Supabase Edge Function or backend server.
  severity: ERROR
  languages: [ts, tsx, js, jsx]
  patterns:

  • pattern-either:
    • pattern: |
      createClient(..., process.env.$KEY)
    • pattern: |
      createClient(..., import.meta.env.$KEY)
  • metavariable-regex:
    metavariable: "$KEY"
    regex: ".(SERVICE_ROLE|SECRET)."

• id: supabase-unbounded-select
  message: >
  Performance Warning: Unbounded .select('*') detected.
  Fetching all columns without a .limit(), .range(), or .single()
  can cause performance issues on large tables.
  Consider specifying columns or adding a limiter.
  severity: INFO
  languages: [ts, tsx, js, jsx]
  patterns:

  • pattern: |
    $CLIENT.from(...).select('*')
  • pattern-not-inside: |
    $CLIENT.from(...).select('*').limit(...)
  • pattern-not-inside: |
    $CLIENT.from(...).select('*').range(...)
  • pattern-not-inside: |
    $CLIENT.from(...).select('*').single(...)
  • pattern-not-inside: |
    $CLIENT.from(...).select('*').maybeSingle(...)

• id: react-dangerously-set-inner-html
  message: >
  Security Risk: Usage of dangerouslySetInnerHTML.
  This exposes the application to Cross-Site Scripting (XSS) attacks.
  Ensure the content is sanitized (e.g., using DOMPurify) before rendering.
  severity: WARNING
  languages: [ts, tsx, js, jsx]
  pattern: |
  <... dangerouslySetInnerHTML={...} ...>

• id: hardcoded-jwt-token
  message: >
  Security Risk: Hardcoded JWT or API Key detected.
  Do not commit secrets to the repo. Use environment variables.
  severity: ERROR
  languages: [ts, tsx, js, jsx]
  patterns:

  • pattern-regex: "eyJ[a-zA-Z0-9-]+\.[a-zA-Z0-9-]+\.[a-zA-Z0-9-_]+"`

[noelsaw1]

Here are 10 prevalent anti-patterns in the Vite/React/Supabase stack, focusing on security holes and performance killers that go beyond the standard N+1 issue.

1. Security: Trusting user_metadata for Authorization

Many developers store roles (e.g., is_admin: true) in user_metadata because it's easy to access on the client.

• Why it's bad: user_metadata is writable by the user. A malicious user can simply call supabase.auth.updateUser({ data: { is_admin: true } }) from the browser console and grant themselves admin rights.
• The Fix: Store sensitive roles in app_metadata (read-only for users) or a separate public.profiles table protected by RLS.
• GREP Signature:

grep -r "user_metadata" . | grep -E "role|admin|permission"

2. Performance: The "Exact Count" Tax

Using { count: 'exact' } forces Postgres to scan the entire table to get a row count, which kills performance on large datasets.

• Why it's bad: It disables internal optimizations (like "soft" limits). It is often used on every page load just to show "Total Items: 15,402".
• The Fix: Use { count: 'estimated' } (if acceptable) or cache the count in a separate table/Redis if accuracy is critical.
• GREP Signature:

grep -r "count: ['\"]exact['\"]" .

3. Logic: The useEffect Auth Death Spiral

A classic React/Supabase infinite loop. You put the auth listener inside a useEffect, but setting state inside the listener triggers the effect again.

• The Fix: Ensure the onAuthStateChange listener is initialized once (empty dependency array []) or outside the render cycle.
• Semgrep Pattern:

patterns:
  - pattern-inside: |
      useEffect(() => { ... }, [$DEP])
  - pattern: |
      supabase.auth.onAuthStateChange(...)

4. Security: getSession() vs. getUser()

Using supabase.auth.getSession() to gate critical routes or server-side actions.

• Why it's bad: getSession retrieves the token from the local store (localStorage/cookie). It is fast but does not validate if the user has been banned or deleted on the server since the token was issued.
• The Fix: Use supabase.auth.getUser() for critical gates (like "Admin Dashboard"), as it makes a network call to validate the token against the Auth server.

5. Performance: The "Double Dip" Insert

Inserting a row and then immediately making a second request to fetch it.

• The Anti-Pattern:

await supabase.from('todos').insert({ task: 'New' });
const { data } = await supabase.from('todos').select('*'); // 2nd Network Call

• The Fix: Use .select() chained to the insert to return the data immediately.

const { data } = await supabase.from('todos').insert({ task: 'New' }).select();

• GREP Signature: Look for .insert calls that end without .select().

6. Performance: Realtime "Firehose"

Subscribing to * events on the public schema.

• Why it's bad: Your client will receive every single Insert/Update/Delete happening in the entire database (that RLS allows). This creates massive WebSocket traffic and CPU usage.
• The Fix: Always filter subscriptions by table and preferably by filter (e.g., user_id=eq.123).
• GREP Signature:

grep -r "channel(.*).on(.*schema: 'public')" .

7. Performance: Client-Side Text Search (.like())

Using .like('%term%') or .ilike() on a large text column.

• Why it's bad: This forces a "Sequential Scan" (Postgres reads every single row) because standard B-Tree indexes cannot index the middle of a string.
• The Fix: Use Postgres Full Text Search. Create a tsvector column and use .textSearch().
• GREP Signature:

grep -r "\.ilike(" .

8. Security: Public Buckets ≠ Public RLS

Setting a Storage Bucket to "Public" so users can download avatars, but forgetting that "Public" also means "Listable".

• Why it's bad: A "Public" bucket often bypasses RLS for the list operation. Attackers can iterate through your bucket to scrape all files.
• The Fix: Keep buckets "Private" and use RLS policies to allow SELECT (download) for anon users, but deny LIST.

9. Architecture: Client-Side "Waterfall" Authorization

Fetching the user, checking a role in JavaScript, and then fetching the data.

• The Anti-Pattern:

const user = await getUser();
if (user.role === 'admin') {
   const data = await fetchData(); // Data is theoretically accessible to anyone who skips the JS check
}

• Why it's bad: A savvy user can simply call fetchData() manually in the console.
• The Fix: Move the "Admin Check" into Postgres RLS. The query should just be fetchData(), and the Database decides if you get 0 rows or 100 rows.

10. Performance: RLS Join Killers

Writing an RLS policy that joins another large table without an index.

• The Anti-Pattern:

-- Policy: "Users can see posts from their organization"
(select organization_id from profiles where profiles.id = auth.uid()) = organization_id

• Why it's bad: For every single row displayed in the posts table, Postgres has to run a sub-query against the profiles table. If listing 50 posts, that's 50 sub-queries.
• The Fix: Store critical claims (like organization_id) directly in the JWT (app_metadata) using a Database Hook/Trigger on login, so the RLS policy becomes a simple constant comparison (auth.jwt() ->> 'org_id').

Quick Reference: Detectable Patterns

ID	Anti-Pattern	Severity	Search Pattern
1	User Metadata Auth	Critical	user_metadata near role/admin
2	Exact Count	High Perf	count: 'exact'
5	Blind Insert	Med Perf	.insert(...) (without .select)
6	Realtime Firehose	High Perf	schema: 'public' (inside channel)
7	ILike Search	High Perf	.ilike(
4	getSession Gate	Med Security	getSession (in guarded routes)