Última actualización: 22 de septiembre de 2026
Este documento se enfoca en los controles técnicos. Para qué datos recopilamos y cómo los usamos, mirá la Política de Privacidad.
Esta política describe los controles técnicos y organizativos que protegen los datos de los usuarios de Capo.
requireAuth) antes de ejecutar cualquier lectura o escritura: no hay endpoints de datos accesibles sin autenticación, salvo el tablero de invitado, que no llega a tocar el servidor, y la vista de un tablero compartido con link público, que es de solo lectura y requiere el token del link.Cada cuenta puede tener hasta 5 tableros independientes, con un máximo de 6 columnas por tablero. El aislamiento se refuerza en el servidor con tres guards (requireBoardAccess, requireColumnAccess, requireTaskAccess) que verifican, antes de cada operación, que el tablero, columna o tarea pertenezca al usuario autenticado (comparando userId contra la sesión); si no coincide, la operación se rechaza como "No autorizado". No existe un endpoint que permita listar datos de otra cuenta.
Tableros compartidos: el dueño puede dar acceso de solo lectura a un tablero con un link público o invitando hasta 4 emails. Cada link usa un token aleatorio de 192 bits (crypto.randomBytes) y la vista no se indexa en buscadores. Los links por email solo funcionan si la sesión tiene ese email. Un link inexistente y uno desactivado responden igual, sin revelar que existió. Las notas se quitan en el servidor y nunca llegan al Invitado. Solo el dueño puede crear, desactivar, regenerar o quitar accesos.
Los datos de cuentas registradas persisten en PostgreSQL (Prisma Postgres / Prisma Accelerate) a través de Prisma ORM. Las credenciales de base de datos, el secreto de autenticación (AUTH_SECRET) y las claves de GitHub OAuth se manejan como variables de entorno, nunca en el código del repositorio. El modo invitado (sin cuenta) no usa el servidor: sus datos quedan solo en el localStorage del navegador.
El archivo histórico (hasta 60 días, 30 tareas por día) permite auditorías de productividad, pero no se purga automáticamente por tiempo: al llenarse hay que vaciarlo manualmente. Los registros de sesión guardan IP y user-agent como rastro de accesos. Los errores no manejados del servidor y del cliente se reportan a Sentry para diagnóstico; los errores de negocio esperados (ej. "columna llena") se excluyen a propósito para no generar ruido.
Capo es un proyecto open source (licencia MIT, código en github.com/CiroMirkin/Capo). Si encontrás una vulnerabilidad:
Capo se distribuye bajo licencia MIT, "tal cual" y sin garantías de ningún tipo, como es habitual en software open source. Los controles descritos en este documento reflejan el diseño técnico actual del proyecto (autenticación con better-auth, validación de propiedad por recurso, hash de contraseñas, rate limiting), pero no constituyen una certificación de seguridad formal ni sustituyen una auditoría independiente.
Nota para revisión legal/técnica: el SDK de Sentry está inicializado con su configuración por defecto; más allá de excluir los errores de negocio esperados, no hay una regla adicional que filtre datos personales de los reportes de error antes de enviarlos. Conviene revisar esto si se maneja información sensible en el contenido de las tareas.
Límites conocidos de los tableros compartidos: el registro con email no verifica el email, así que si una persona invitada todavía no tiene cuenta, alguien con el link podría registrarse con ese email y ver el tablero. Además, el límite de vistas de los links públicos se cuenta en memoria por instancia del servidor, así que no es un límite global exacto.
Esta política se actualizará a medida que cambien los controles técnicos del proyecto. Para reportar incidentes de seguridad o hacer consultas: ciromirkin@gmail.com o issues del repositorio.