Seguridad
Cómo protegemos tu cuenta y tu contenido, qué decisiones técnicas hay detrás y cómo avisarnos si encuentras un fallo.
Actualizado el 5 de septiembre de 2026
El principio: que la base diga que no
La decisión de seguridad más importante de Kanbanly es dónde se comprueban los permisos. No se comprueban en la pantalla, ni en el código que consulta la base de datos: se comprueban en la base de datos misma, con políticas de seguridad a nivel de fila.
La diferencia es enorme y conviene entenderla. Si los permisos se comprueban en las consultas, hay que acordarse en cada una de ellas: en las más de cien que lee esta aplicación, olvidarse en una es cuestión de tiempo, y la que se olvide no dará ningún error —enseñará datos que no debía, y se descubrirá cuando alguien se queje—. Con políticas en la base, la comprobación se aplica a todas las lecturas por definición, sin que ninguna consulta tenga que acordarse. Una consulta mal escrita devuelve menos de lo que esperaba, no más.
Sobre esa base están construidos los roles de tablero —administrar, editar, comentar, observar—, la visibilidad de los espacios de trabajo, el acceso de los invitados a un tablero suelto y qué campos de tu perfil ve cada quién.
Tu cuenta y tu contraseña
Las contraseñas las custodia el sistema de autenticación de Supabase, cifradas con funciones de derivación pensadas para eso. Kanbanly no guarda contraseñas en su propia base de datos, y ni el código de la aplicación ni quien la administra pueden leer la tuya. Cuando la olvidas no te la podemos decir: solo podemos darte una vía para poner otra.
También puedes entrar con Google, en cuyo caso la contraseña ni siquiera existe por nuestra parte: quien te identifica es Google y nosotros recibimos la confirmación.
La recuperación de contraseña se hace por un enlace enviado a tu correo, con caducidad. Mientras una recuperación está a medias, la aplicación te lleva de vuelta a terminarla en lugar de dejarte a medio camino con una sesión en un estado raro.
Los pagos no pasan por nosotros
El número de tu tarjeta, su fecha de caducidad y su código de seguridad no llegan nunca a Kanbanly. Los introduces en el formulario de Wompi, que es quien los procesa y quien está sujeto a los estándares de la industria de medios de pago.
De vuelta guardamos lo justo para poder enseñarte qué se cobró y con qué: el identificador de la transacción, el importe, la moneda, el estado, la marca de la tarjeta y sus cuatro últimos dígitos. Con eso no se puede cobrar nada.
Cada cobro lleva una referencia única generada por nosotros, y es esa unicidad la que impide cobrar dos veces el mismo periodo. Los avisos que la pasarela nos manda cuando un cobro cambia de estado vienen firmados, y se comprueba la firma antes de hacerles caso: sin esa comprobación, cualquiera que conociera la dirección del aviso podría declarar aprobado un cobro que no existió.
Cifrado
Todo el tráfico entre tu navegador y Kanbanly va cifrado con HTTPS, sin excepción y sin posibilidad de conectarse de otra forma. Lo mismo vale para el tráfico entre la aplicación y la base de datos, y entre la aplicación y los proveedores de correo y de pagos.
Los datos guardados están cifrados en reposo por la infraestructura de la base de datos y del almacenamiento de archivos.
Los archivos que subes
Los archivos adjuntos de las tarjetas se guardan en un almacenamiento separado de la base de datos, y el listado de adjuntos de una tarjeta está protegido por las mismas políticas de acceso que la tarjeta: quien no puede abrir la tarjeta no ve sus adjuntos.
Hay un límite de tamaño por archivo, y además un tope por plan: un archivo que exceda el tope de tu plan se rechaza y se elimina del almacenamiento en lugar de quedarse ahí ocupando sitio sin que nadie vuelva a mirarlo.
Lo que hemos aprendido rompiendo cosas
Esta sección no es habitual en una página de seguridad, y está aquí a propósito: creemos que decir qué fallos hemos encontrado y cómo los cerramos dice más de la seguridad de un producto que una lista de adjetivos.
- Los permisos por defecto de la base
- PostgreSQL deja ejecutar las funciones a todo el mundo salvo que se le diga lo contrario, y de ese «todo el mundo» hereda el rol público con el que habla el navegador. Una auditoría encontró medio centenar de funciones abiertas así, dos de ellas capaces de cambiar el plan de un espacio de trabajo sin pagar. Se cerraron todas, y se cambió el permiso por defecto para que las funciones nuevas nazcan cerradas: arreglar el caso concreto habría dejado el mismo agujero esperando a la siguiente función.
- Comparar contra un valor que no existe
- Una comprobación del tipo «si el dueño no es quien pregunta, corta» no corta nada cuando no hay nadie preguntando, porque comparar con un valor nulo no da ni verdadero ni falso. El fallo se encontró una vez, se explicó bien, y aun así reapareció tres migraciones después en las dos funciones que mueven dinero. Ahora se comparan de una forma que sí distingue el caso vacío.
- Reemplazar una función y crear dos
- En PostgreSQL, «reemplazar» una función con una lista de argumentos distinta no la reemplaza: crea una segunda con el mismo nombre, y las llamadas antiguas siguen yendo a la vieja sin fallar y sin avisar. Ahora se borra explícitamente la versión anterior, y hay pruebas que comprueban que solo queda una.
Límites contra el abuso
Las funciones que pueden generar correo desde una cuenta con sesión tienen topes por persona y por ventana de tiempo, comprobados en la base de datos y no solo en la pantalla. Sin ellos, un formulario que manda correo es un grifo abierto: alguien con mala idea llena el buzón de soporte y, de paso, quema la cuota del proveedor para todo lo demás que manda Kanbanly.
Las ventanas son móviles y no se cortan a medianoche, precisamente para que no se puedan gastar dos cupos completos con dos minutos de diferencia.
Cómo trabajamos
Cada cambio en la base de datos es una migración numerada, con su explicación escrita de por qué se hace y qué fallo concreto arregla, y con pruebas que se ejecutan contra un PostgreSQL de verdad: se comprueba que quien no debe ver algo no lo ve, y no solo que quien debe verlo lo ve. Comprobar solo la mitad buena es lo que deja pasar la mitad del fallo.
El código lleva pruebas automáticas que se ejecutan antes de publicar nada. Varias de ellas son guardianes: no comprueban que algo funcione, sino que una regla no se ha roto sin que nadie se diera cuenta. Cada guardián se rompe a propósito al escribirlo, para comprobar que salta.
Las claves de acceso a los proveedores viven en variables de entorno del servidor y no viajan al navegador. Las que sí tienen que ser públicas son públicas por diseño, y detrás de ellas están las políticas de la base que impiden hacer nada indebido con ellas.
Si encuentras un fallo de seguridad
Cuéntanoslo. No hace falta que sepas explicarlo en términos técnicos ni que demuestres nada: si algo te ha dejado ver lo que no deberías, o te ha parecido raro, queremos saberlo.
Escríbenos por el canal de asistencia de la aplicación y descríbelo con el detalle que puedas: qué hiciste, qué esperabas y qué pasó en su lugar. Si puedes adjuntar una captura, mejor.
Te pedimos dos cosas a cambio: que nos des un margen razonable para arreglarlo antes de contarlo en público, y que no accedas a datos de otras personas más allá de lo mínimo para comprobar que el fallo existe. A quien avisa de buena fe no le vamos a ir detrás.
Lo que todavía no hacemos
Ser honestos sobre los límites es parte de esto. Kanbanly no ofrece todavía autenticación en dos pasos, ni inicio de sesión único corporativo, ni certificaciones de cumplimiento auditadas por terceros. No hay un programa de recompensas por fallos.
Si algo de eso es imprescindible para tu organización, dínoslo por la Ayuda: saber quién lo necesita y para qué es lo que decide en qué orden se hacen las cosas.