Seguridad
Qué protege tu cartera, en concreto
Las garantías genéricas no valen nada en una página como esta. Abajo está lo que el sistema hace realmente, descrito con suficiente precisión como para que puedas hacer una pregunta difícil sobre cualquiera de sus líneas.
Tu conexión con el bróker no puede operar
Esta es la propiedad que más importa, y es estructural, no una política. vest101 pide credenciales de API limitadas a leer posiciones, transacciones e histórico de dividendos. En el producto no hay código de envío de órdenes que explotar, configurar mal o activar por error.
- Acceso de API de solo lectura a Trading 212 e Interactive Brokers.
- Ninguna llamada de orden, transferencia o retirada en toda la base de código.
- Revocar la clave en tu bróker surte efecto de inmediato; a partir de ahí la fuente se informa como fallo de sincronización en lugar de mostrar una cifra desactualizada.
Las credenciales y las direcciones se cifran en reposo
Las claves de API del bróker y las direcciones de Bitcoin se cifran en la base de datos con AES-GCM. Como AES-GCM usa un IV aleatorio, dos cifrados del mismo valor son distintos — lo que rompe las búsquedas por igualdad y las restricciones de unicidad que necesita una base de datos —, así que las búsquedas pasan por un índice ciego con clave en lugar de descifrar filas para buscar en ellas.
- Cifrado AES-GCM para credenciales de bróker y direcciones de Bitcoin.
- Índice ciego con clave para las búsquedas: encontrar una fila nunca exige descifrar otras.
- El descifrado ocurre en la frontera del repositorio; ninguna capa por encima maneja el texto cifrado ni la clave.
Tus datos están aislados por usuario, en el sistema de tipos
Cada tabla con datos de usuario lleva una referencia al usuario, y cada función de repositorio que toca una recibe el identificador de usuario como argumento obligatorio. Es deliberado y lo impone el compilador: una consulta sin ese ámbito no compila, así que no puede escribirse por accidente y pasar una revisión.
- Identificador de usuario obligatorio en cada ruta de acceso a datos — si falta, el build falla.
- Sin sobrecargas «de conveniencia» opcionales que permitan saltarse el requisito.
- La API interna que llama la capa de IA valida el mismo requisito en lugar de confiar en quien la invoca.
El origen solo responde a Cloudflare
El servidor que ejecuta vest101 no es direccionable de forma directa. Está detrás de Cloudflare con Authenticated Origin Pulls activado, de modo que un handshake TLS que no presente el certificado de cliente de Cloudflare se rechaza antes de leer ninguna petición.
- TLS mutuo entre Cloudflare y el origen; las conexiones directas se rechazan en el handshake.
- HSTS, nosniff, bloqueo de framing y una política de referrer estricta en cada respuesta, también en los errores.
- Límites de tasa por IP en el borde para los endpoints de credenciales, con la dirección real del visitante, más el limitador de la propia aplicación por detrás.
- La API interna de servicio no está enrutada desde internet en absoluto — solo es accesible entre contenedores del mismo host.
Los datos de pago no llegan hasta nosotros
El checkout se ejecuta en la página alojada por Stripe. vest101 guarda el estado resultante de la suscripción y nada más: ni número de tarjeta, ni caducidad, ni CVC, ni nada que pudiera usarse para cobrarte.
- Los datos de la tarjeta se introducen en Stripe y nunca pasan por vest101.
- El acceso se evalúa en cada petición contra el periodo que realmente has pagado, no contra una marca de estado, así que un webhook perdido no puede ampliar ni revocar el acceso en silencio.
- Un proceso de conciliación horario vuelve a comprobar el estado de la suscripción contra Stripe para corregir cualquier desviación.
Las copias de seguridad están cifradas, y su restauración está ensayada
La base de datos se respalda de forma programada en archivos cifrados y protegidos con contraseña, guardados aparte de las credenciales de la propia aplicación. Una copia que nadie ha restaurado nunca es una esperanza, no una copia, así que restaurarla es un procedimiento escrito y no una suposición.
- Copias de seguridad cifradas y programadas, con su propia contraseña.
- Sumas de verificación de datos activadas en Postgres, para que la corrupción silenciosa aparezca mientras aún existe una copia buena.
- La restauración es un simulacro documentado, no un script sin probar.
Un despliegue mal configurado se niega a servir
El fallo del que más se cuida este sistema no es una caída: es un despliegue que tiene éxito y está discretamente mal. Para eso hay dos barreras independientes: una antes de construir nada, y otra como primera instrucción que ejecuta el servidor, antes incluso de contactar con la base de datos.
- Un arranque en producción con un ajuste ausente o inseguro lanza un error y entra en bucle de reinicio en lugar de servir.
- Informa de todos los problemas a la vez en vez de fallar en el primero, así que una mala configuración se arregla de una sola pasada.
- Los ajustes cuyo valor por defecto en desarrollo es cómodo pero catastrófico en producción — un captcha desactivado, una ruta de correo que informa de éxito sin enviar nada — se rechazan de forma explícita.
Qué no afirmamos
vest101 es un producto pequeño y de gestión independiente. Ser preciso con los límites forma parte de la misma promesa que el resto de esta página.
- No hay ninguna auditoría de seguridad ni test de penetración de terceros que enseñar.
- No hay certificación SOC 2, ISO 27001 ni equivalente.
- No hay un programa formal de recompensas por errores — pero un aviso enviado a la dirección de abajo lo lee y lo responde la persona que escribió el código.
- Ningún sistema es inviolable. Usa una contraseña única y mantén también en el bróker tus claves de API limitadas a solo lectura.
Reportar una vulnerabilidad
Si has encontrado algo, por favor comunícalo en privado antes de hacerlo público. Recibirás respuesta.