Informe de preparación para producción

Impacto. Cualquiera que abra el sitio puede copiar la llave que se saltea todas las reglas de seguridad y leer, cambiar o borrar todos los datos de todos los negocios.

Ubicación

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

Estándar

V13 Configuración (gestión de secretos) · V8 Autorización

Qué está mal

El panel de admin crea un cliente de Supabase con la clave service_role leída de una variable VITE_. Vite incrusta toda variable VITE_ en el JavaScript público, así que la clave le llega a cada visitante. El .env que la contiene está commiteado. La ruta /admin no tiene ningún chequeo en el servidor; solo se oculta el link del menú.

Evidencia (salida real de las pruebas)

Build de producción de la app original (npx vite build) y búsqueda en el resultado:
$ grep -o 'eyJ[A-Za-z0-9._-]*service_role_key_full_access' dist/assets/*.js
dist/assets/index-D4vCh4Ci.js: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJyb2xlIjoic2VydmljZV9yb2xlIi...
# El payload del JWT es {"role":"service_role"}. Misma búsqueda en el build corregido: sin resultados.

Cómo reproducirlo

# 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>"

Comportamiento esperado

La clave service_role existe solo en el servidor. Los datos de admin los entrega una función de servidor que verifica que quien llama sea admin (un dato que el usuario no puede editar).

Corrección (extracto del diff)

- 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);

Controles de este hallazgo

Impacto. Con una cuenta gratis alcanza para sumarse a cualquier clínica o peluquería como staff y desde ahí ver y cambiar su agenda, clientes, pagos, precios y documentos.

Ubicación

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

Estándar

V8 Autorización

Qué está mal

La política de INSERT sobre staff es WITH CHECK (true). Todos los demás permisos de la app preguntan "¿este usuario está en staff de este negocio?", así que quien puede escribir en staff tiene la llave de todos los negocios. Los IDs de negocio se leen sin login desde la tabla pública de servicios.

Evidencia (salida real de las pruebas)

Cómo reproducirlo

-- 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');

Comportamiento esperado

Solo el dueño de un negocio puede agregarle staff.

Corrección (extracto del diff)

-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));

Controles de este hallazgo

Impacto. Con un solo pedido una cuenta normal pasa a ser admin. Hoy eso habilita el menú de admin; cualquier función de admin que se agregue después quedaría abierta para todos.

Ubicación

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

Estándar

V8 Autorización (acceso a nivel de campo)

Qué está mal

La política de UPDATE de perfiles limita bien al usuario a su propia fila, pero no a ciertas columnas. is_admin y role están en esa misma fila, así que el usuario puede reescribirlos.

Evidencia (salida real de las pruebas)

Cómo reproducirlo

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

Comportamiento esperado

El usuario puede editar su nombre y teléfono; role e is_admin solo cambian desde el servidor.

Corrección (extracto del diff)

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

Controles de este hallazgo

Impacto. Cualquiera puede mandar un pedido que marca un turno como pagado y confirmado sin pagar, o llenar la facturación de un negocio con pagos inventados.

Ubicación

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

Estándar

V2 Validación y lógica de negocio · V4 API y servicios web

Qué está mal

El webhook corre con la clave service_role y toma estado, monto, turno y negocio del cuerpo del pedido, sin verificar la firma de Mercado Pago ni consultar el pago a Mercado Pago. Si no viene estado, asume "approved". Además, el staff podía insertar pagos "paid" directo desde el navegador, y nada impedía registrar el mismo pago dos veces. La prueba mostró también el problema inverso: un aviso real de Mercado Pago (que solo trae el id del pago) se rechazaba con "missing appointment", así que los pagos reales nunca confirmaban turnos.

Evidencia (salida real de las pruebas)

Cómo reproducirlo

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"

Comportamiento esperado

Los pedidos sin firma reciben 401 y no cambian nada. Estado y monto salen de la API de Mercado Pago, el monto tiene que coincidir con el precio del turno, y cada pago se registra una sola vez.

Corrección (extracto del diff)

-    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);

Controles de este hallazgo

Impacto. Sin cuenta, cualquiera puede bajar todos los turnos de cualquier negocio, con nombre y teléfono de cada cliente, servicio y precio.

Ubicación

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

Estándar

V8 Autorización

Qué está mal

La función es SECURITY DEFINER (se saltea la seguridad por filas) y filtra solo por el id de negocio que recibe, sin verificar que quien llama pertenezca a ese negocio. La puede ejecutar anon. Los escáneres gratuitos no la marcan porque tiene search_path fijo.

Evidencia (salida real de las pruebas)

Cómo reproducirlo

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>"}'

Comportamiento esperado

Solo los miembros del negocio pueden leer su agenda; las llamadas anónimas se rechazan.

Corrección (extracto del diff)

+  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;

Controles de este hallazgo

Impacto. Cualquiera que se registre puede bajar la cartera completa de clientes de todas las clínicas y peluquerías: nombre, email, teléfono y notas privadas, que pueden incluir datos de salud.

Ubicación

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

Estándar

V8 Autorización · V14 Protección de datos

Qué está mal

La política de SELECT es USING (auth.role() = 'authenticated'), que es verdadero para cualquier usuario logueado. Las otras políticas de clients chequean bien la membresía; esta no.

Evidencia (salida real de las pruebas)

Cómo reproducirlo

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

Comportamiento esperado

Cada usuario ve solo los clientes de los negocios a los que pertenece.

Corrección (extracto del diff)

-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));

Controles de este hallazgo

Impacto. Un desconocido puede cancelar todo el día de un negocio o marcar turnos impagos como confirmados. Los ids de turno quedan expuestos por F-05.

Ubicación

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

Estándar

V8 Autorización · V2 Validación y lógica de negocio

Qué está mal

Función SECURITY DEFINER que actualiza cualquier turno por id, sin chequear membresía ni validar el nuevo estado. La puede ejecutar anon.

Evidencia (salida real de las pruebas)

Cómo reproducirlo

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

Comportamiento esperado

Solo los miembros del negocio del turno pueden cambiarlo, y solo a un estado conocido.

Corrección (extracto del diff)

+  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;

Controles de este hallazgo

Impacto. Cualquier usuario logueado puede listar y descargar DNI, estudios médicos y consentimientos de los clientes de todos los negocios, y meter archivos en carpetas de otros negocios.

Ubicación

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

Estándar

V5 Manejo de archivos · V8 Autorización

Qué está mal

Las políticas de storage solo chequean bucket_id = 'client-docs', no la carpeta del negocio en la ruta (<business_id>/<client_id>/archivo). El bucket no tiene límite de tamaño y acepta cualquier tipo de archivo.

Evidencia (salida real de las pruebas)

Cómo reproducirlo

-- 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

Comportamiento esperado

Solo los miembros del negocio de la primera carpeta de la ruta pueden listar, subir o borrar; las subidas se limitan a PDF/JPEG/PNG de hasta 10 MB.

Corrección (extracto del diff)

-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';

Controles de este hallazgo

Impacto. Una reserva se puede mandar con cualquier precio (por ejemplo 1 centavo). El código AMIGO50 de 50% y los otros cupones los puede leer cualquiera en el código de la página.

Ubicación

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

Estándar

V2 Validación y lógica de negocio

Qué está mal

El navegador calcula el total (con cupones) y create-booking guarda price_cents y business_id tal como llegan. En la app original la seguridad por filas igual bloquea inserts de no miembros, así que hoy el precio lo falsifica una cuenta de staff, y cualquiera combinándolo con F-02.

Evidencia (salida real de las pruebas)

Cómo reproducirlo

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}'

Comportamiento esperado

Precio, duración y negocio salen de la base; los cupones se validan en el servidor contra una tabla que los usuarios no pueden leer.

Corrección (extracto del diff)

-      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()

Controles de este hallazgo

Impacto. Cualquiera en internet puede bajar la lista de usuarios registrados con email, teléfono y quién es admin: material para spam, phishing o ataques dirigidos.

Ubicación

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

Estándar

V8 Autorización · V14 Protección de datos

Qué está mal

Política de SELECT USING (true) sin restricción de rol, así que también aplica a anon.

Evidencia (salida real de las pruebas)

Cómo reproducirlo

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

Comportamiento esperado

Cada usuario lee solo su propio perfil.

Corrección (extracto del diff)

-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());

Controles de este hallazgo

Impacto. Cualquier cuenta puede subir una página de phishing o malware que queda servida desde la dirección pública de storage de tu proyecto, sin límite de tamaño ni de tipo.

Ubicación

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

Estándar

V5 Manejo de archivos

Qué está mal

Pese al nombre, la política de subida solo chequea bucket_id = 'marketing'. El bucket es público (por diseño, para logos y banners) y no tiene límite de tamaño ni lista de tipos.

Evidencia (salida real de las pruebas)

Cómo reproducirlo

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

Comportamiento esperado

Solo miembros del negocio suben, dentro de su carpeta, solo imágenes, hasta 2 MB. La lectura pública queda como estaba.

Corrección (extracto del diff)

+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';

Controles de este hallazgo

Impacto. Dos clientes pueden quedarse con el mismo horario, y la página de reservas ofrece horarios que ya pasaron. Molesto para los clientes, costoso para el negocio.

Ubicación

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

Estándar

V2 Validación y lógica de negocio

Qué está mal

La disponibilidad solo oculta horarios cuyo inicio es exactamente igual al de una reserva existente, y nada en la base impide superposiciones.

Evidencia (salida real de las pruebas)

Cómo reproducirlo

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

Comportamiento esperado

La base rechaza reservas superpuestas para el mismo servicio; la disponibilidad excluye superposiciones y horarios pasados.

Corrección (extracto del diff)

+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, '[)'))

Controles de este hallazgo

Impacto. Un pedido mal formado devuelve stack traces y mensajes crudos de la base que le ayudan a un atacante a mapear el sistema.

Ubicación

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

Estándar

V16 Registro de seguridad y manejo de errores

Qué está mal

El webhook devuelve {error, stack}; las otras funciones devuelven error.message de la base tal cual.

Evidencia (salida real de las pruebas)

Cómo reproducirlo

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

Comportamiento esperado

Errores genéricos hacia el cliente; el detalle solo en los logs del servidor.

Corrección (extracto del diff)

-    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);

Controles de este hallazgo

Impacto. Las funciones aceptan llamadas cross-origin de cualquier sitio, y una además declara que acepta credenciales, una combinación inválida e insegura.

Ubicación

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

Estándar

V3 Seguridad del frontend web

Qué está mal

Access-Control-Allow-Origin: * en todas las funciones; get-availability agrega Access-Control-Allow-Credentials: true.

Evidencia (salida real de las pruebas)

Cómo reproducirlo

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

Comportamiento esperado

Solo se permiten los dominios propios de la app (ALLOWED_ORIGINS); nunca credenciales con comodín. El webhook no manda CORS (es servidor a servidor).

Corrección (extracto del diff)

-  "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;

Controles de este hallazgo