Muestras de mi trabajo / Auditoría de seguridad
Study case de
ciberseguridad:
Pawsi.
Detecté y corregí dos vulnerabilidades en el sistema de mensajes de mi aplicación. Preparé un laboratorio, probé los cambios y comprobé su funcionamiento en producción.
- Mi responsabilidad
- Desarrollo, auditoría y correcciones
- Alcance del caso
- Dos vulnerabilidades del sistema de mensajes
- Producto
- Web y Android con Capacitor
- Revisión de seguridad
- Octubre de 2026
Descripción y trayectoria
de Pawsi
Pawsi nació para ayudar a reunir mascotas con sus familias: publicar animales perdidos, compartir avistamientos y encontrar adopciones. La lancé como webapp en septiembre de 2025 y ganó la Hackathon del Milagro en Salta con su MVP web.
Lanzamiento de la webapp
Publicación y primeras personas utilizando Pawsi.
Llegada a Android
Publicación en Google Play con Capacitor y una base web compartida.
Auditoría y mejoras de seguridad
Laboratorio local, restauración selectiva y correcciones del sistema de mensajes.
También hubo que salir a contarlo.
Participé en más de 30 entrevistas para presentar el proyecto. Explicar su funcionamiento a personas sin conocimientos técnicos fue parte del trabajo de construirlo. La aplicación sigue funcionando, con menor actividad que durante su pico inicial.
Archivo de prensa y piezas de difusión del proyecto. Las imágenes se pueden ampliar.
Entender cómo se
conecta cada parte.
La interfaz usa React y TypeScript. Capacitor permite distribuirla en Android. Supabase aporta autenticación, PostgreSQL y funciones de backend; Cloudflare R2 y el CDN sirven las imágenes, y Firebase entrega las notificaciones push.
Los medios tienen un TTL de un año en Cloudflare y en el navegador. Al reemplazar o retirar una imagen hay que considerar las copias existentes: purgar el CDN no borra la caché del navegador.
La base de datos y los archivos necesitan recuperarse por separado. Recuperar un registro con la URL de una imagen no recupera el archivo al que apunta.
Un lugar para probar
antes de cambiar.
Preparé Supabase local con Docker y WSL y conecté el frontend a sus propias credenciales. Las integraciones externas se deshabilitaron o sustituyeron durante las pruebas.
El primer arranque mostró un problema concreto: las migraciones intentaban alterar una tabla que todavía no existía. Reconstruí el entorno mediante una restauración selectiva del respaldo PostgreSQL y comparé los conteos de tablas y registros.
Recuperación parcial de estructura y datos. Las pruebas posteriores usaron cuentas sintéticas y se comprobó que no dejaran registros de prueba.
Archivos de almacenamiento, sesiones y configuración completa de proveedores. El ensayo no demuestra una recuperación integral ni establece un RTO o RPO medido.
Tener un respaldo y saber qué permite recuperar son dos trabajos distintos.
Invocaciones no autorizadas
de notificaciones
El flujo anterior permitía solicitar notificaciones desde el cliente sin validar suficientemente la autorización del envío. Trasladé esa decisión a un evento generado por la base de datos al guardar un mensaje válido.
- El cliente autenticado guarda un mensaje bajo los controles de la base de datos.
- Un trigger crea el aviso interno y un evento privado con su destinatario.
- La base firma una solicitud con HMAC y una marca temporal.
- La Edge Function valida la firma y reclama el evento de forma atómica.
- Si corresponde el envío, llama a Firebase y registra el resultado.
El endpoint anterior conserva la compatibilidad con la app publicada, pero ya no envía notificaciones. No fue necesario exigir una nueva versión de Android.
Evitar duplicados y ráfagas
Agregué vencimiento de eventos, límites de frecuencia y un único intento por evento. Activar el envío no procesa mensajes históricos. Los eventos que exceden los límites se omiten y no quedan acumulados para después.
Ver las 23 comprobaciones del laboratorio
Resultados registrados el 20 de octubre de 2026. Auth, PostgreSQL, pg_net y Edge Runtime locales; proveedor push simulado.
- Instalar/reaplicar no genera avisos de mensajes anterioresAPROBADO
- INSERT crea aviso in-app aun con push desactivadoAPROBADO
- Activar push no procesa historial ni eventos desactivadosAPROBADO
- INSERT con cliente antiguo dispara webhook firmado y un pushAPROBADO
- 20 llamadas antiguas con identidades inventadas no producen avisosAPROBADO
- Marcar leído y editar mensaje no disparan nuevos avisosAPROBADO
- Repetir INSERT con mismo ID no duplica avisosAPROBADO
- Repetir webhook ya enviado no duplica pushAPROBADO
- Sin firma, con JWT de usuario o con clave pública: 401APROBADO
- Firma adulterada: 401APROBADO
- Firma de un evento no sirve para otro: 401APROBADO
- Firma de más de dos minutos: 401APROBADO
- Usuario no puede reclamar ni finalizar eventos por RPCAPROBADO
- Ráfaga de 15 mensajes al mismo destinatario no agrega pushAPROBADO
- Tope global alcanzado omite el push, sin cola de reintentosAPROBADO
- Proveedor falla: mensaje y aviso quedan guardadosAPROBADO
- Proveedor falla: repetición no reenvíaAPROBADO
- 10 reclamos concurrentes de evento nuevo hacen un solo envío con snapshot originalAPROBADO
- Evento viejo con firma reciente se descarta sin envíoAPROBADO
- Fallo de configuración no impide guardar mensaje ni avisoAPROBADO
- Error de INSERT del aviso no revierte mensaje; queda registradoAPROBADO
- ROLLBACK de mensaje tampoco deja aviso ni eventoAPROBADO
- Reaplicar parche no recorre mensajes existentesAPROBADO
La comprobación en producción
Durante el despliegue apareció un 503: el nombre del secreto no coincidía con el esperado por la función. Corregida la configuración, llegó la notificación a Android. Una llamada sin firma recibió 401 Unauthorized.
Un único intento reduce la duplicación, pero un fallo después de reclamar el evento puede perder el push. El aviso dentro de la aplicación y el push son mecanismos distintos.
Permisos excesivos
para modificar mensajes
La política RLS permitía al destinatario actualizar el mensaje para marcarlo como leído. Sin embargo, el permiso SQL de actualización alcanzaba todas las columnas: también podía cambiar el asunto o el contenido.
Reproduje el cambio de asunto en el laboratorio, retiré el permiso general y concedí únicamente la actualización de read_at. RLS sigue decidiendo qué mensajes puede modificar cada persona.
| Campo | Antes | Después |
|---|---|---|
| Asunto y contenido | Permitido | Denegado |
| Identificadores y otras fechas | Permitido | Denegado |
| Estado de lectura | Permitido | Permitido |
Ver las 15 comprobaciones de permisos
Resultados del 23 de octubre de 2026 con cuentas sintéticas. La primera comprobación reproduce el permiso excesivo antes de la corrección.
- Antes: destinatario podía cambiar asuntoAPROBADO
- Destinatario marca como leídoAPROBADO
- UPDATE denegado: idAPROBADO
- UPDATE denegado: sender_idAPROBADO
- UPDATE denegado: recipient_idAPROBADO
- UPDATE denegado: post_idAPROBADO
- UPDATE denegado: post_typeAPROBADO
- UPDATE denegado: subjectAPROBADO
- UPDATE denegado: contentAPROBADO
- UPDATE denegado: created_atAPROBADO
- UPDATE denegado: updated_atAPROBADO
- RLS rechaza marcar leído: remitenteAPROBADO
- RLS rechaza marcar leído: terceroAPROBADO
- Anónimo sin UPDATEAPROBADO
- Marcar leído no crea eventos adicionalesAPROBADO
En producción comprobé los permisos efectivos y que el estado de lectura persistiera entre dos cuentas. El frontend ya actualizaba solo ese campo, por lo que no necesitó cambios.
RLS limita las filas.
Los privilegios limitan las columnas.
De una intención
a un control verificable.
Las reglas del producto necesitaban quedar reflejadas en el backend: quién puede modificar un mensaje, qué campos puede tocar y qué evento habilita una notificación.
Documenté el problema, la decisión, las pruebas y sus límites. El caso presenta la detección y corrección de dos vulnerabilidades del sistema de mensajes, además de una recuperación parcial en laboratorio. Las comprobaciones no constituyen una certificación de seguridad de toda la aplicación.
El caso, para llevar.
Historia, arquitectura, decisiones y resultados en un documento de tres páginas.
Datos de contacto
Disponible para trabajo remoto o presencial, con disponibilidad para viajar. Podemos conversar en español o inglés.
Tel. +543875044912diegopuzio@gmail.com