01 Tres principios que orientan las decisiones
Una buena seguridad no es una lista de tecnologías; es un puñado de decisiones repetidas con disciplina. Las nuestras son estas:
- La regla vive en el servidor, no en la pantalla. Esconder un botón no protege nada: quien llama directamente a nuestra interfaz de programación pasa por encima de la pantalla. Toda decisión que importa — quién ve qué, quién es suscriptor, cuánto se ha usado — se toma en el servidor.
- Fallar cerrado. Cuando el sistema no consigue confirmar un permiso, deniega. Liberar a ciegas es el error más caro que puede cometer un servicio con datos de salud.
- No guardar lo que no hace falta. El dato más seguro es el que no existe. La foto del documento es el ejemplo central: cumple su función y se descarta.
02 Protección de tu cuenta
- Las contraseñas se almacenan solo como hash criptográfico — no tenemos forma de leer tu contraseña, ni siquiera para ayudar en el soporte.
- El registro se confirma con un código enviado a tu correo, lo que impide crear una cuenta con una dirección ajena.
- El restablecimiento de contraseña usa un enlace o código de validez corta y un solo uso.
- La sesión de la app usa tokens de acceso de corta duración con renovación automática: un token capturado tiene una ventana de utilidad pequeña.
- Al cerrar sesión, la sesión también se cierra en los servicios conectados, como el de suscripción.
03 Aislamiento por cuenta, aplicado en la base de datos
Cada tabla de Boopet tiene seguridad a nivel de fila (Row Level Security) activada. En la práctica: la consulta que hace la app llega a la base de datos ya atada a la identidad del usuario conectado, y la base solo devuelve filas que le pertenecen.
Un ejemplo concreto del principio "la regla vive en el servidor": el usuario tiene permiso de lectura sobre su propia fila de suscripción y ningún permiso de escritura sobre ella. Sin eso, "soy suscriptor" estaría a una edición de fila de distancia. Quien escribe esa información es exclusivamente el servicio que recibe la confirmación de la tienda.
04 Cifrado
- En tránsito: toda comunicación entre la app, el sitio y nuestros servidores usa HTTPS/TLS. No existe ningún camino en texto abierto.
- En reposo: la base de datos y el almacenamiento de archivos están cifrados en el proveedor de infraestructura.
- En el dispositivo: guardamos localmente solo preferencias y el token de sesión, en el almacenamiento protegido del sistema operativo. Ningún dato sensible queda en un archivo abierto.
05 Fotos de las mascotas y archivos
Las fotos están en un bucket privado, no público. La diferencia importa: un bucket público significa una dirección adivinable por quien conozca el formato de la ruta.
- Cada archivo se graba en una carpeta identificada por su dueño, y la política de acceso comprueba esa correspondencia en cada lectura, envío, sustitución o eliminación.
- El acceso a la imagen se hace por enlace temporal firmado, generado bajo demanda y con caducidad. Nunca guardamos URLs permanentes.
- Cambiar la foto de la mascota borra la anterior — los archivos huérfanos no se acumulan en el almacenamiento.
- Hay límite de tamaño y de tipo de archivo aceptado, verificado en el servidor.
06 Fotos de documentos: qué pasa y qué no se queda
Este es el punto que más dudas genera, así que vale el detalle:
| Etapa | Qué pasa | ¿Se guarda? |
|---|---|---|
| 1. Captura | La imagen se reduce en el propio dispositivo antes del envío | No |
| 2. Envío | Viaja por conexión cifrada hasta nuestro servidor | No |
| 3. Lectura | El servidor la envía al proveedor de IA y recibe los campos extraídos | No |
| 4. Revisión | Los campos vuelven a la app para que revises y confirmes | Solo lo que confirmes |
| 5. Registro | Guardamos fecha, tipo de documento, resultado y modelo utilizado | Sí — sin imagen |
La extracción se envía a la app en estado de pendiente de revisión. Nada se convierte en alarma de medicamento sin pasar por tu aprobación — una decisión de seguridad tanto como de producto.
07 Los secretos nunca están dentro de la app
Una app instalada en el móvil puede ser desmontada por cualquiera. Todo lo que va incrustado en ella debe considerarse público. Por eso:
- Las claves de los proveedores de inteligencia artificial viven solo en el servidor, como secretos de entorno, y jamás se incrustan en la app.
- La lectura por foto la ejecuta una función en el servidor. La app solo pide — no sabe qué proveedor responde ni con qué credencial.
- Las únicas claves presentes en la app son públicas por definición (identificador del proyecto, clave anónima de la base de datos protegida por seguridad a nivel de fila, clave pública de la tienda de suscripciones).
- Las configuraciones operativas, como proveedor, modelo y límites, se cambian en el servidor, sin republicar la app.
08 El plan se verifica en el servidor
La pantalla decide qué dibujar; el servidor decide qué ejecutar. La función de lectura por foto comprueba la suscripción por su cuenta y rechaza la llamada de quien no tiene plan activo, aunque la petición venga con una credencial legítima de usuario.
Sin esa verificación en el servidor, tanto el costo como la cuota serían, en la práctica, opcionales para quien supiera llamar a la interfaz directamente.
09 Cuotas y protección contra abusos
- Toda lectura se contabiliza antes de la llamada al modelo, incluidas las que fallan — así nadie esquiva el límite forzando errores.
- La cuota es mensual, anclada al ciclo de la suscripción, y separada por tipo de documento.
- Hay límite de tamaño de imagen aceptado, verificado en el servidor.
- Los registros de consumo no pueden ser alterados ni borrados por el usuario.
10 Moderación de imágenes
Antes de extraer cualquier información, la imagen se evalúa en cuanto a contenido inapropiado. El orden es intencional: lo primero que hace el sistema es decidir si debe continuar.
Cuando una imagen se rechaza, registramos solo la categoría y el número de ocurrencias de la cuenta. No guardamos la imagen ni ninguna descripción de lo que contenía — una descripción sería, en sí misma, un registro del contenido que decidimos no guardar.
11 Recepción de las confirmaciones de suscripción
Las confirmaciones de compra llegan por una dirección dedicada en el servidor, que es el único camino capaz de escribir el estado de suscripción de una cuenta. Está protegido por varias capas:
- Autenticación obligatoria: sin el secreto configurado, la dirección lo rechaza todo. Fallar cerrado es mejor que aceptar cualquier petición que afirme "esta persona es suscriptora".
- Firma criptográfica (HMAC) de la entrega, incluida la hora de envío, lo que impide reutilizar una petición antigua.
- Ventana de tiempo: las entregas demasiado antiguas se rechazan.
- Idempotencia: cada evento tiene un identificador único y se registra antes de procesarse. Las reentregas no duplican efectos, y un fallo a mitad de camino se rehace con seguridad.
12 Qué registramos — y qué no
| Registramos | No registramos |
|---|---|
| Fecha, tipo y resultado de las lecturas por foto | La imagen enviada |
| Categoría de rechazo por contenido inapropiado | Descripción del contenido rechazado |
| Errores técnicos y fallos de ruta | Contenido del historial en registros de diagnóstico |
| Registros de acceso exigidos por ley | Identificadores de publicidad |
| Eventos de suscripción recibidos de la tienda | Datos de tarjeta o de pago |
13 Copias de seguridad y continuidad
La base de datos está alojada en infraestructura gestionada, con copias de seguridad automáticas periódicas mantenidas por el proveedor y redundancia de almacenamiento. Los cambios de esquema de la base se versionan y se aplican de forma controlada, lo que permite auditar exactamente qué cambió, cuándo y por qué.
Las copias de seguridad sirven para la recuperación ante desastres. No se usan para consultar datos de cuentas eliminadas, y caducan dentro del ciclo normal de retención del proveedor.
14 Respuesta a incidentes
Ningún sistema es inviolable, y prometer lo contrario sería deshonesto. Si ocurre un incidente de seguridad que pueda acarrear riesgo o daño relevante a los titulares:
- contenemos el incidente y preservamos evidencias;
- evaluamos qué datos y qué cuentas se vieron afectados;
- comunicamos a los titulares afectados y a la Autoridad Nacional de Protección de Datos de Brasil (ANPD) en un plazo razonable, conforme al artículo 48 de la LGPD;
- informamos las medidas de corrección adoptadas y lo que puedes hacer para protegerte;
- revisamos lo que permitió el incidente y corregimos la causa, no solo el síntoma.
15 ¿Encontraste una vulnerabilidad?
Agradecemos los reportes responsables. Escribe a contact@boopet.app con el asunto "Seguridad", describiendo el problema y los pasos para reproducirlo.
16 Lo que te toca a ti
Parte de la seguridad está de tu lado, y vale decirlo sin rodeos:
- usa una contraseña exclusiva para Boopet, que no reutilices de otros servicios;
- mantén el bloqueo de pantalla activo en el dispositivo — quien desbloquea el móvil, desbloquea la app;
- no compartas la cuenta, ni siquiera con quien también cuida del animal;
- mantén la app y el sistema del dispositivo actualizados;
- al cambiar o vender el dispositivo, cierra sesión antes;
- guarda los documentos originales de tus animales — la app organiza, pero no sustituye el archivo en papel.
¿Alguna duda sobre seguridad?
Preguntas técnicas, reportes de vulnerabilidad o solicitudes de aclaración sobre protección de datos.
Oakboo · Brasil · Los reportes de seguridad tienen prioridad en la cola de atención.