Production Readiness Report

Impact. Anyone who opens the site can copy the key that skips every security rule and read, change or delete all data of every business.

Location

src/integrations/supabase/admin.ts · .env (VITE_SUPABASE_SERVICE_ROLE_KEY) · src/pages/AdminPage.tsx

Standard

V13 Configuration (secret management) · V8 Authorization

What is wrong

The admin panel creates a Supabase client with the service_role key read from a VITE_ variable. Vite inlines every VITE_ variable into the public JavaScript bundle, so the key ships to every visitor. The .env file holding it is committed. The /admin route has no server-side check; the menu link is only hidden.

Evidence (real test output)

Production build of the original app (npx vite build), then searching the output:
$ grep -o 'eyJ[A-Za-z0-9._-]*service_role_key_full_access' dist/assets/*.js
dist/assets/index-D4vCh4Ci.js: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJyb2xlIjoic2VydmljZV9yb2xlIi...
# JWT payload decodes to {"role":"service_role"}. Same search on the fixed build: no match.

Reproduction

# 1. Open the live site, DevTools > Sources, search the main .js file for "service_role"
# 2. Use the key against the REST API — every row of every table comes back:
curl "https://<project>.supabase.co/rest/v1/clients?select=*" \
  -H "apikey: <service_role key from the bundle>" \
  -H "Authorization: Bearer <service_role key from the bundle>"

Expected behavior

The service_role key exists only on the server. Admin data is served by a server function that verifies the caller is an admin (a flag users cannot edit).

Fix (diff excerpt)

- src/integrations/supabase/admin.ts          (deleted)
- VITE_SUPABASE_SERVICE_ROLE_KEY=eyJ...        (.env, removed; .env added to .gitignore)
--- a/src/pages/AdminPage.tsx
-      const { data } = await adminClient.from("businesses").select("id, name, slug, owner_id");
+      const { data, error } = await supabase.functions.invoke("admin-overview");
+++ b/supabase/functions/admin-overview/index.ts  (new)
+  const { data: { user } } = await admin.auth.getUser(token);
+  if (!user) return json({ error: "unauthorized" }, 401);
+  const { data: profile } = await admin.from("profiles").select("is_admin").eq("id", user.id).single();
+  if (!profile?.is_admin) return json({ error: "forbidden" }, 403);

Controls for this finding

Impact. A free account is enough to join any clinic or salon as staff and then see and change its agenda, clients, payments, prices and documents.

Location

supabase/migrations/0002_rls.sql · policy "staff can be added" on public.staff

Standard

V8 Authorization

What is wrong

The INSERT policy on staff is WITH CHECK (true). Every other permission in the app is "is this user in staff for this business?", so whoever can write to staff holds the keys to every tenant. Business IDs are readable without login from the public services table.

Evidence (real test output)

Reproduction

-- as any logged-in user (role authenticated, own JWT)
insert into public.staff (business_id, user_id, role, display_name)
values ('<business A id>', auth.uid(), 'owner', 'x');

Expected behavior

Only the owner of a business can add staff to it.

Fix (diff excerpt)

-create policy "staff can be added" on public.staff
-  for insert to authenticated
-  with check (true);
+create policy "owners add staff" on public.staff
+  for insert to authenticated
+  with check (public.is_business_owner(business_id));

Controls for this finding

Impact. One request turns a normal account into an admin. Today that unlocks the admin menu; every admin feature built later would be open to everyone.

Location

supabase/migrations/0002_rls.sql · policy "users update own profile" · src/components/Layout.tsx

Standard

V8 Authorization (field-level access)

What is wrong

The profile UPDATE policy correctly limits users to their own row, but not to specific columns. is_admin and role live in the same row, so users can rewrite them.

Evidence (real test output)

Reproduction

-- as any logged-in user
update public.profiles set is_admin = true, role = 'admin' where id = auth.uid();

Expected behavior

Users can edit their name and phone; role and is_admin change only from the server.

Fix (diff excerpt)

+revoke insert, update on public.profiles from anon, authenticated;
+grant update (full_name, phone) on public.profiles to authenticated;

Controls for this finding

Impact. Anyone can send one request that marks a booking as paid and confirmed without paying, or fills a business's revenue with invented payments.

Location

supabase/functions/payments-webhook/index.ts · 0002_rls.sql policy "members insert payments"

Standard

V2 Validation and Business Logic · V4 API and Web Service

What is wrong

The webhook runs with the service_role key and takes status, amount, appointment and business from the request body without checking Mercado Pago's signature or asking Mercado Pago about the payment. If no status is sent it assumes "approved". Separately, staff could insert "paid" rows straight from the browser, and nothing stopped the same payment being recorded twice. The run also showed the opposite problem: a real Mercado Pago notification (which only carries the payment id) was rejected with "missing appointment", so genuine payments never confirmed bookings.

Evidence (real test output)

Reproduction

curl -X POST "https://<project>.supabase.co/functions/v1/payments-webhook" \
  -H "Content-Type: application/json" \
  -d '{"metadata":{"appointment_id":"<id>","business_id":"<id>"},"amount":1}'
# -> 200 {"ok":true}; payment stored as "paid", appointment set to "confirmed"

Expected behavior

Unsigned requests get 401 and change nothing. Status and amount come from Mercado Pago's API, the amount must equal the booking price, and a payment id is recorded once.

Fix (diff excerpt)

-    const status = event.data?.status ?? event.status ?? "approved";
-    const amount = event.data?.transaction_amount ?? event.amount ?? 0;
+    const valid = await verifyMpSignature({
+      xSignature: req.headers.get("x-signature"),
+      xRequestId: req.headers.get("x-request-id"),
+      dataId, secret: Deno.env.get("MP_WEBHOOK_SECRET") ?? "" });
+    if (!valid) return json({ error: "invalid_signature" }, 401);
+    const mpRes = await fetch(`https://api.mercadopago.com/v1/payments/${encodeURIComponent(dataId!)}`, ...);
+    const paid = payment.status === "approved" && amountCents === appt.price_cents;
+    await supabase.from("payments").upsert({ ... }, { onConflict: "provider,provider_ref" });
-- migration 0005
+drop policy if exists "members insert payments" on public.payments;
+alter table public.payments add constraint payments_provider_ref_unique unique (provider, provider_ref);

Controls for this finding

Impact. Without an account, anyone can pull every appointment of any business, with each client's name, phone, service and price.

Location

supabase/migrations/0003_functions.sql · function public.get_business_appointments

Standard

V8 Authorization

What is wrong

The function is SECURITY DEFINER (it skips row-level security) and filters only by the business id it receives, without checking that the caller belongs to that business. It is executable by anon. Free scanners do not flag it because search_path is set.

Evidence (real test output)

Reproduction

curl "https://<project>.supabase.co/rest/v1/rpc/get_business_appointments" \
  -H "apikey: <public anon key>" -H "Content-Type: application/json" \
  -d '{"p_business_id":"<business A id>"}'

Expected behavior

Only members of the business can read its agenda; anonymous calls are refused.

Fix (diff excerpt)

+  if not public.is_business_member(p_business_id) then
+    raise exception 'forbidden' using errcode = '42501';
+  end if;
+revoke execute on function public.get_business_appointments(uuid, timestamptz, timestamptz) from public, anon;

Controls for this finding

Impact. Anyone who signs up can download the full client list of every clinic and salon: name, email, phone and private notes, which can include health data.

Location

supabase/migrations/0002_rls.sql · policy "read clients" on public.clients

Standard

V8 Authorization · V14 Data Protection

What is wrong

The SELECT policy is USING (auth.role() = 'authenticated'), which is true for every logged-in user. The other client policies correctly check business membership; this one does not.

Evidence (real test output)

Reproduction

-- as any logged-in user
select full_name, email, phone, notes from public.clients;

Expected behavior

Users see only the clients of businesses they belong to.

Fix (diff excerpt)

-create policy "read clients" on public.clients
-  for select to authenticated
-  using (auth.role() = 'authenticated');
+create policy "members read clients" on public.clients
+  for select to authenticated
+  using (public.is_business_member(business_id));

Controls for this finding

Impact. A stranger can cancel a business's whole day or mark unpaid bookings as confirmed. Appointment ids are exposed by F-05.

Location

supabase/migrations/0003_functions.sql · function public.update_appointment_status

Standard

V8 Authorization · V2 Validation and Business Logic

What is wrong

SECURITY DEFINER function that updates any appointment by id, with no membership check and no validation of the new status value. Executable by anon.

Evidence (real test output)

Reproduction

-- as anon (no login)
select public.update_appointment_status('<appointment id>', 'cancelled');

Expected behavior

Only members of the appointment's business can change it, and only to a known status.

Fix (diff excerpt)

+  if p_status is null or p_status not in ('pending','confirmed','cancelled','done','no_show') then
+    raise exception 'invalid status' using errcode = '22023';
+  end if;
+  select a.business_id into v_business from public.appointments a where a.id = p_appointment_id;
+  if v_business is null or not public.is_business_member(v_business) then
+    raise exception 'forbidden' using errcode = '42501';
+  end if;
+revoke execute on function public.update_appointment_status(uuid, text) from public, anon;

Controls for this finding

Impact. Any logged-in user can list and download the ID cards, medical studies and consent forms of every business's clients, and drop files into other businesses' folders.

Location

supabase/migrations/0004_storage.sql · policies on storage.objects (bucket client-docs)

Standard

V5 File Handling · V8 Authorization

What is wrong

The storage policies only check bucket_id = 'client-docs', not the business folder in the path (<business_id>/<client_id>/file). The bucket has no size limit and accepts any file type.

Evidence (real test output)

Reproduction

-- as any logged-in user
select name from storage.objects where bucket_id = 'client-docs';
-- with the listed path, supabase.storage.from('client-docs').createSignedUrl(path, 60) downloads it

Expected behavior

Only members of the business in the first folder of the path can list, upload or delete; uploads are limited to PDF/JPEG/PNG up to 10 MB.

Fix (diff excerpt)

-create policy "read client docs" on storage.objects
-  for select to authenticated using (bucket_id = 'client-docs');
+create policy "members read client docs" on storage.objects
+  for select to authenticated
+  using (bucket_id = 'client-docs' and public.is_member_of_folder(name));
+update storage.buckets set file_size_limit = 10485760,
+  allowed_mime_types = array['application/pdf','image/jpeg','image/png'] where id = 'client-docs';

Controls for this finding

Impact. A booking can be sent with any price (for example 1 cent). The 50% code AMIGO50 and the other coupons can be read by anyone in the page source.

Location

supabase/functions/create-booking/index.ts · src/lib/pricing.ts · src/pages/BookingPage.tsx

Standard

V2 Validation and Business Logic

What is wrong

The browser computes the total (coupons included) and create-booking stores price_cents and business_id exactly as sent. Row-level security still blocks inserts from non-members in the original app, so the price is forged by staff accounts today, and by anyone combined with F-02.

Evidence (real test output)

Reproduction

curl -X POST "https://<project>.supabase.co/functions/v1/create-booking" \
  -H "Authorization: Bearer <user JWT>" -H "Content-Type: application/json" \
  -d '{"service_id":"<id>","business_id":"<other id>","starts_at":"...","ends_at":"...","price_cents":1}'

Expected behavior

Price, duration and business come from the database; coupons are validated on the server against a table users cannot read.

Fix (diff excerpt)

-      business_id: body.business_id,
-      price_cents: body.price_cents,
+    const { data: service } = await supabase.from("services")
+      .select("id, business_id, duration_min").eq("id", body.service_id).eq("active", true).single();
+    const { data: price } = await supabase.rpc("quote_price", { p_service_id: service.id, p_coupon: body.coupon });
+        business_id: service.business_id,
+        price_cents: price,
-- migration 0005: table public.coupons (RLS on, no client access) + function public.quote_price()

Controls for this finding

Impact. Anyone on the internet can download the list of registered users with email, phone and who is admin: material for spam, phishing or targeted attacks.

Location

supabase/migrations/0002_rls.sql · policy "profiles are viewable"

Standard

V8 Authorization · V14 Data Protection

What is wrong

SELECT policy USING (true) with no role restriction, so it also applies to anon.

Evidence (real test output)

Reproduction

curl "https://<project>.supabase.co/rest/v1/profiles?select=email,phone,is_admin" -H "apikey: <public anon key>"

Expected behavior

Each user reads only his own profile.

Fix (diff excerpt)

-create policy "profiles are viewable" on public.profiles
-  for select using (true);
+create policy "users read own profile" on public.profiles
+  for select to authenticated using (id = auth.uid());

Controls for this finding

Impact. Any account can upload a phishing page or malware that is then served from your project's public storage address, with no size or type limit.

Location

supabase/migrations/0004_storage.sql · bucket marketing · policy "members upload marketing"

Standard

V5 File Handling

What is wrong

Despite its name, the upload policy only checks bucket_id = 'marketing'. The bucket is public (by design, for logos and banners) with no size limit or type allowlist.

Evidence (real test output)

Reproduction

-- as any logged-in user
insert into storage.objects (bucket_id, name, owner) values ('marketing', 'login-verify.html', auth.uid());

Expected behavior

Only business members upload, inside their own folder, images only, up to 2 MB. Public reading stays as designed.

Fix (diff excerpt)

+create policy "members upload marketing" on storage.objects
+  for insert to authenticated
+  with check (bucket_id = 'marketing' and public.is_member_of_folder(name));
+update storage.buckets set file_size_limit = 2097152,
+  allowed_mime_types = array['image/png','image/jpeg','image/webp'] where id = 'marketing';

Controls for this finding

Impact. Two customers can get the same slot, and the booking page offers times that already passed. Annoying for customers, costly for the business.

Location

supabase/migrations/0003_functions.sql · get_available_slots · table public.appointments

Standard

V2 Validation and Business Logic

What is wrong

Availability only hides slots whose start time is exactly equal to an existing booking, and nothing in the database prevents overlaps.

Evidence (real test output)

Reproduction

select to_char(slot,'HH24:MI') from public.get_available_slots('<service>', current_date + 7);
-- an existing booking 10:15-10:45 still leaves 10:00 and 10:30 on offer

Expected behavior

Overlapping bookings for the same service are rejected by the database; availability excludes overlaps and past times.

Fix (diff excerpt)

+alter table public.appointments add constraint appointments_no_overlap
+  exclude using gist (service_id with =, tstzrange(starts_at, ends_at, '[)') with &&)
+  where (status <> 'cancelled');
+  where g.slot > now()
+    and not exists (... tstzrange(a.starts_at, a.ends_at, '[)') && tstzrange(g.slot, g.slot + duration, '[)'))

Controls for this finding

Impact. A malformed request returns stack traces and raw database messages that help an attacker map the system.

Location

payments-webhook/index.ts (catch) · create-booking/index.ts · get-availability/index.ts

Standard

V16 Security Logging and Error Handling

What is wrong

The webhook returns {error, stack}; the other functions return error.message from the database as is.

Evidence (real test output)

Reproduction

curl -X POST "https://<project>.supabase.co/functions/v1/payments-webhook" -d '{not json'

Expected behavior

Generic error bodies to the client; details only in server logs.

Fix (diff excerpt)

-    return new Response(JSON.stringify({ error: String(err), stack: (err as Error).stack }), {
+    console.error("payments-webhook failed", err);  // details stay in server logs
+    return json({ error: "internal_error" }, 500);

Controls for this finding

Impact. The functions accept cross-origin calls from any website, and one of them also declares it accepts credentials, an invalid and unsafe combination.

Location

get-availability/index.ts · create-booking/index.ts · payments-webhook/index.ts

Standard

V3 Web Frontend Security

What is wrong

Access-Control-Allow-Origin: * on every function; get-availability adds Access-Control-Allow-Credentials: true.

Evidence (real test output)

Reproduction

curl -i -X OPTIONS "https://<project>.supabase.co/functions/v1/get-availability" -H "Origin: https://evil.example"

Expected behavior

Only the app's own origins (ALLOWED_ORIGINS) are allowed; never credentials with a wildcard. The webhook sends no CORS headers (server-to-server).

Fix (diff excerpt)

-  "Access-Control-Allow-Origin": "*",
-  "Access-Control-Allow-Credentials": "true",
+// supabase/functions/_shared/cors.ts
+  if (ALLOWED_ORIGINS.includes(origin)) headers["Access-Control-Allow-Origin"] = origin;

Controls for this finding