Ultima actualizacion: 30 de marzo de 2026
Creemos que tienes derecho a saber como se protegen tus datos. Esta pagina detalla las medidas de seguridad especificas, los estandares de cifrado y las decisiones arquitectonicas que usamos para resguardar tu cuenta, informacion personal y contenido comprado. Aqui no hay humo -- te decimos exactamente como funciona todo por debajo del capo.
| Capa | Estandar | Detalles |
|---|---|---|
| Datos en Transito | TLS 1.3 / AES-256-GCM | Todo el trafico entre tu navegador y nuestros servidores esta cifrado usando TLS 1.3, el protocolo de seguridad de capa de transporte mas reciente. La suite de cifrado utiliza AES-256-GCM para cifrado simetrico, proporcionando una fortaleza de cifrado de 256 bits. Se aplica en el borde por Cloudflare con cabeceras HSTS (HTTP Strict Transport Security) para prevenir ataques de degradacion de protocolo. |
| Almacenamiento de Contrasenas | bcrypt / 12 rondas | Las contrasenas se cifran usando el algoritmo de hashing adaptativo bcrypt con un factor de costo de 12 (4,096 iteraciones). bcrypt es una funcion unidireccional -- las contrasenas no pueden revertirse ni descifrarse, ni siquiera por nosotros. Cada contrasena se sala con un salt unico y criptograficamente aleatorio para prevenir ataques de tablas rainbow. |
| Tokens de Sesion | HMAC-SHA256 | Los tokens de autenticacion (JWT) se firman usando HMAC-SHA256 con una clave secreta de 512 bits. Los tokens son validos por 7 dias y no pueden falsificarse sin la clave de firma. La clave de firma se almacena unicamente del lado del servidor y nunca se transmite. |
| Datos de Pago | PCI DSS Nivel 1 | Los datos de tarjetas de pago los maneja exclusivamente Stripe, un procesador de pagos certificado PCI DSS Nivel 1. Los numeros de tarjeta, CVVs y datos bancarios nunca tocan nuestros servidores. Solo recibimos confirmaciones de transacciones y metadatos. |
| Medida | Implementacion |
|---|---|
| Proteccion contra Fuerza Bruta | Las cuentas se bloquean por 15 minutos despues de 5 intentos consecutivos fallidos de inicio de sesion. Adicionalmente, los endpoints de autenticacion estan limitados a 10 solicitudes por ventana de 15 minutos por direccion IP. |
| Limitacion de Velocidad Global | Todos los endpoints de la API estan sujetos a un limite global de 100 solicitudes por ventana de 15 minutos por direccion IP para prevenir abuso y ataques de denegacion de servicio. |
| Requisitos de Contrasena | Minimo 8 caracteres. Validacion de formato de correo electronico. Nombres de usuario limitados a 100 caracteres para prevenir ataques de desbordamiento. |
| Expiracion de Tokens | Los tokens JWT expiran despues de 7 dias, requiriendo re-autenticacion. Los tokens se almacenan en el almacenamiento local del navegador y se eliminan al cerrar sesion. |
| Recurso | Metodo de Proteccion |
|---|---|
| Contenido de Video | Los videos nunca se sirven mediante URLs directas. Todo el contenido de video se transmite a traves de un proxy API autenticado que verifica la identidad del usuario y su registro de compra en cada solicitud. Las cabeceras Cache-Control previenen el almacenamiento en cache del navegador de los datos de video. |
| Archivos Descargables | Los archivos (conjuntos de datos, PDFs, guias) se almacenan en un directorio del servidor que no es accesible publicamente. Las descargas se sirven a traves de un endpoint autenticado que verifica la propiedad de la compra. Todas las descargas se registran con ID de usuario, producto, direccion IP y marca de tiempo. |
| Contenido del Curso | El contenido de las lecciones (texto, HTML) solo lo devuelve la API para usuarios que han comprado el curso o para lecciones explicitamente marcadas como contenido de vista previa. Las lecciones bloqueadas retornan contenido nulo. |
| Recorrido de Rutas (Path Traversal) | Todas las rutas de archivos se resuelven y validan para asegurar que permanezcan dentro del directorio de cargas designado. Las solicitudes que intentan acceder a archivos fuera del limite de cargas se bloquean y registran. |
| Amenaza | Mitigacion |
|---|---|
| Inyeccion SQL | Todas las consultas a la base de datos usan sentencias parametrizadas (sentencias preparadas) a traves de la biblioteca pg. La entrada del usuario nunca se concatena en cadenas SQL. Ni un solo query se arma con strings pegados -- todo parametrizado. |
| Cross-Site Scripting (XSS) | Todos los datos de las respuestas de la API se sanitizan usando una funcion de escape HTML antes de la insercion en el DOM. Las cabeceras de Politica de Seguridad de Contenido (CSP) restringen las fuentes de ejecucion de scripts. |
| Cross-Site Request Forgery (CSRF) | La autenticacion usa tokens Bearer en la cabecera Authorization, que no se envian automaticamente por el navegador como las cookies, proporcionando proteccion inherente contra CSRF. |
| Cabeceras de Seguridad | La aplicacion usa Helmet.js para establecer cabeceras HTTP de seguridad completas incluyendo: Content-Security-Policy, X-Content-Type-Options (nosniff), X-Frame-Options (deny), Strict-Transport-Security (HSTS), X-DNS-Prefetch-Control y X-XSS-Protection. |
| Validacion de Entradas | Todas las entradas del usuario se validan del lado del servidor: formato de correo electronico, longitud de contrasena, formato UUID para identificadores, longitud del cuerpo de comentarios (limite de 5,000 caracteres), longitud de nombre de usuario (limite de 100 caracteres) y limites de posicion de video (0-86,400 segundos). |
Si no lo necesitamos, no lo guardamos. Asi de simple.
En caso de un incidente de seguridad que resulte en acceso no autorizado a datos personales, nosotros:
Si descubres una vulnerabilidad de seguridad en el Servicio, genuinamente queremos saberlo. Esta es una operacion de una sola persona y me tomo la seguridad en serio -- si algo esta roto, quiero saberlo para poder arreglarlo. No te voy a echar la culpa por encontrar un hueco.
Reporta vulnerabilidades a:
Te pedimos que:
Publicamos un registro transparente de cada auditoria de seguridad realizada contra esta plataforma. Si se descubre un hallazgo, lo documentamos, lo arreglamos y lo listamos aqui.
| Fecha | Tipo | Hallazgos | Estado |
|---|---|---|---|
| 2026-04-12 | Auditoria interna (contra patron de pentest externo) | 1 -- credencial de base de datos hardcodeada encontrada en scripts auxiliares y documentacion. La credencial controlaba una base de datos vinculada solo a localhost en el servidor de la aplicacion (no accesible externamente), pero fue rotada de todas formas bajo nuestra politica "fuga = rotacion". | Arreglado + rotado el mismo dia |
La auditoria revisa: referencia directa insegura a objetos (IDOR) en endpoints de usuario, exposicion de hashes de contrasenas, fugas de direcciones IP, traversal de rutas en cargas de archivos, exposicion de codigo fuente por raices web mal configuradas, exposicion de directorios de control de versiones, claves API hardcodeadas en el frontend, y credenciales reales en archivos de plantilla de entorno. Todas las verificaciones pasaron excepto el hallazgo anterior, que ya fue remediado.
Seamos honestos -- no hay un programa de bug bounty con plata. Estoy pelao para pagarte. Pero si encuentras algo y lo reportas responsablemente, vas a recibir:
Si eres un investigador buscando bounties pagados, entiendo totalmente si sigues de largo. Sin rencores, pana. Pero si eres de los que reportan las vainas porque es lo correcto -- te veo, y te lo agradezco de verdad.