Preferimos enseñártelo a decirte «confía en nosotros». Aquí abajo: qué pasa cuando conectas un banco, quién se encarga de qué, qué hacemos en nuestro código y qué se revisa con cada cambio.
La respuesta corta: la contraseña de tu banco se queda en tu banco, y ClassKasa solo puede leer la cuenta. No puede mover dinero.
Todo lo que hay en esta página lo podemos señalar. Si todavía no lo hemos probado, no lo decimos.
Cuando conectas un banco
Solo el tesorero de la clase conecta una cuenta de la clase, y es una función Premium. Los padres nunca inician sesión en un banco a través de ClassKasa.
1
La contraseña de tu banco se queda en tu banco
Inicias sesión en la propia página de tu banco, a la que llegas a través de Enable Banking. ClassKasa nunca ve ni guarda tu usuario ni tu contraseña del banco.
2
Enable Banking Oy obtiene los datos
Enable Banking Oy es un proveedor de servicios de información sobre cuentas registrado en la Autoridad de Supervisión Financiera de Finlandia (FIN-FSA). Pide a tu banco los datos que tú permites y se los pasa a ClassKasa.
3
Qué leemos: cuenta, saldo, movimientos
El nombre, la moneda y el número de la cuenta, el saldo y los movimientos (importe, fecha, ordenante y concepto). Es solo de lectura: con esto no se puede iniciar ningún pago ni mover dinero.
4
Por cuánto tiempo: hasta 90 días
Pedimos a tu banco 90 días de acceso, y tu banco puede fijar un límite más corto. Miramos la cuenta hasta cuatro veces al día. Cuando el acceso esté a punto de caducar, ClassKasa te avisa para que vuelvas a conectar.
5
Desconecta cuando quieras
Pulsa «Desconectar el banco» al final de la pantalla Banco. ClassKasa deja de leer y pide a Enable Banking que cierre la sesión. Los bancos suelen mostrar también en la banca online los accesos que has dado, y allí puedes quitarlos. Las transferencias ya importadas se quedan en la clase hasta que el tesorero borre el historial del banco.
ClassKasa se apoya en unos pocos proveedores conocidos. Abajo está lo que cada uno dice de sí mismo en sus propias páginas. Son sus afirmaciones, no las nuestras.
1
Enable Banking (conexión con el banco)
Dice en su web que es un proveedor de servicios de información sobre cuentas registrado y regulado por la FIN-FSA. No encontramos allí una lista pública de certificados, así que no le atribuimos ninguno.
Estos certificados son de nuestros proveedores. La propia ClassKasa no tiene ningún certificado ISO ni SOC.
Qué hacemos en nuestro propio código
1
Cada endpoint tiene una regla por escrito
Cada endpoint que envía o recibe datos tiene una entrada en una tabla de permisos, y el código la comprueba en cada petición. Nuestra compilación falla si llega un endpoint nuevo sin entrada.
2
Las otras clases no existen para ti
Si pides algo que pertenece a otra clase, recibes «no encontrado», la misma respuesta que con algo que no existe. Pruebas automáticas lo intentan a propósito.
3
Ningún número de tarjeta en nuestro lado
Los pagos con tarjeta pasan por Stripe. ClassKasa nunca guarda números de tarjeta.
4
El acceso al banco solo puede mirar
Solo le pedimos a tu banco que nos muestre la cuenta, nunca que haga un pago. A través de ClassKasa no se puede mover dinero.
5
Solo HTTPS, más reglas del navegador
ClassKasa indica a los navegadores que usen siempre HTTPS y que no permitan mostrarla dentro de marcos de otras webs.
Qué se revisa con cada cambio
Estas revisiones automáticas se ejecutan con cada cambio en el código de la app. Cada una bloquea la compilación cuando encuentra un problema nuevo.
1
Un pentest autorizado y un segundo ataque
En mayo de 2026 (versiones v3.27.0 y v3.27.1, ambas del 2026-05-29) el propietario hizo un pentest autorizado de ClassKasa con Claude Code y el kit de código abierto pentest-ai-agents. Dio lugar a 8 correcciones, 3 de ellas calificadas como High. Después se repitió cada ataque: las correcciones aguantaron, y en 3 sitios más con el mismo tipo de fallo se encontró y cerró el hueco, cada uno con una prueba automática que antes fallaba y ahora pasa.
Un escáner de la comunidad OWASP prueba una copia en funcionamiento de la app en cada pull request que cambia código, y bloquea la compilación ante hallazgos nuevos.
Busca patrones de código arriesgados. Un hallazgo grave bloquea la compilación.
4
Revisión de librerías
npm audit bloquea la compilación ante vulnerabilidades críticas en las librerías que usamos, y OSV-Scanner la bloquea ante vulnerabilidades conocidas nuevas.
5
Actualizaciones de dependencias
Cada semana Dependabot abre pull requests agrupados con las actualizaciones de dependencias que ha encontrado. Las actualizaciones de parche y las de seguridad se integran automáticamente en cuanto pasan las revisiones obligatorias; las actualizaciones mayores siempre esperan a una persona. Una rutina semanal reúne en un único pull request lo que sigue abierto y trabaja en él hasta que pasan todas las revisiones que bloquean.
6
Detección de secretos
Gitleaks revisa todo el historial de cada pull request en busca de contraseñas y claves que no deberían estar ahí, y TruffleHog lo revisa en busca de secretos activos y verificados. Un hallazgo bloquea la compilación.
7
Pruebas entre clases
49 archivos de pruebas automáticas intentan leer y cambiar datos de otras clases. Tienen que recibir un no.
Nada de esto es un certificado. Aparte del pentest de arriba, son revisiones automáticas.
¿Has encontrado algo? Cuéntanoslo
Escribe a tomek@classkasa.com. Con una nota breve y los pasos para reproducirlo basta. Por favor, no pruebes con las clases de otras personas. Nuestro contacto también está en un archivo legible por máquinas, security.txt.