Diario de seguridad.

Revisión interna antes del lanzamiento del programa

El 15 de julio de 2026 iniciamos una revisión de seguridad interna de CreateYourVPN. Las correcciones que hemos completado y vuelto a verificar se publican a continuación; seguirán más a medida que se desplieguen y confirmen.

Añadida una salvaguarda contra una configuración cross-origin insegura

La configuración de production actual no permitía orígenes arbitrarios, pero el código permitía una combinación peligrosa de parámetros si un operador la configuraba mal. Esa combinación ahora se rechaza en el arranque y está cubierta por una prueba automatizada.

Reducida la superficie pública de la API de production

La documentación técnica interactiva de la API era accesible sin autenticación. No daba acceso a datos protegidos, pero facilitaba el estudio de la estructura interna de la API. En production la documentación ahora está desactivada, y sigue disponible en un entorno aislado para el desarrollo.

Claves criptográficas de la plataforma separadas por finalidad

Una revisión interna detectó que un mismo secreto se usaba para dos tareas criptográficas distintas. Esto no creaba ninguna elusión directa, pero ampliaba el alcance de una compromisión de la clave. Las dos finalidades se han separado y cada una se rota ahora de forma independiente.

Garantizado el borrado de la clave de gestión tras eliminar un servidor

El borrado de la clave de gestión cifrada se ejecutaba después de operaciones de red en segundo plano y podía no repetirse si esas operaciones fallaban. Desacoplamos el borrado de la clave de la cascada de red y añadimos un reintento garantizado. Los escenarios de servidor inaccesible y de proceso interrumpido están cubiertos por pruebas.

Eliminada una vía de autorización de la API de socios que no se usaba

La API admitía una vía de autorización adicional basada en cookie que la arquitectura server-side actual no necesitaba. No se encontró ningún ataque entre sitios en production, pero la vía adicional ampliaba la superficie para errores futuros. La API ahora usa un único método de autorización definido explícitamente, cubierto por pruebas negativas.

Se restringió el acceso al panel de gestión de la infraestructura

Un investigador externo informó de que una interfaz administrativa de gestión de la infraestructura respondía desde internet. La interfaz estaba protegida por autenticación y no se encontraron indicios de acceso no autorizado. El informe se aceptó y el acceso se restringió.

Ahora la interfaz solo es accesible desde direcciones autorizadas, se reforzaron los requisitos de autenticación y se actualizaron los componentes implicados. El resultado se verificó desde fuera de nuestra red. Además, revisamos nuestra superficie pública y añadimos una comprobación periódica. La recompensa se pagó en el nivel más alto.

Las direcciones de correo de los usuarios de las tiendas ya no se guardan

Una persona escribe su correo para entrar en la tienda de un partner, pero la dirección no se queda con nosotros: el correo con el código sale y la dirección se elimina de inmediato. La cuenta se reconoce por una huella irreversible de la que no se puede recuperar la dirección, y el nombre de la cuenta tampoco la contiene.

Cada usuario puede restablecer su enlace de suscripción

Un enlace de suscripción es un secreto: quien lo tiene obtiene el mismo acceso que su propietario. El usuario puede restablecerlo por su cuenta desde su perfil: el enlace anterior deja de funcionar y las credenciales asociadas se emiten de nuevo. Un enlace cerrado así permanece cerrado, incluso si se restauran datos desde una copia de seguridad.

Encabezados de seguridad en las páginas de las tiendas

Las tiendas de los partners no enviaban los encabezados de seguridad que el panel y la API ya enviaban, entre ellos el que impide a otros sitios mostrar la página en un iframe. Por esta vía no se podían leer datos de cuenta ni sesiones. Ahora el conjunto completo acompaña a cada respuesta de las tiendas, y la afirmación SR-15 nombra cada frontend que alojamos.

Gestión de sesiones y envío de códigos de acceso

A raíz de los informes de un investigador externo, revisamos dos áreas contiguas: el ciclo de vida de una sesión de socio y el recorrido del correo con el código de acceso. Ninguno de los hallazgos daba acceso a cuentas, datos de socios ni tráfico de usuarios.

Mayor protección para el formulario público de soporte

El investigador de seguridad 0xVicky descubrió que nuestro formulario público de soporte podía utilizarse para enviar un número excesivo de solicitudes. Añadimos límites por visitante y para el tráfico total, protegimos el canal interno de envío del formulario y reforzamos la validación de adjuntos. Gracias por el informe responsable.

Enabled DNSSEC

A researcher found that DNSSEC was not enabled for createyourvpn.com. We signed the DNS zone, published the DS record in .com, and verified the chain of trust.

Las sesiones de partners ya se pueden revocar por completo

Un investigador de seguridad descubrió que una copia del token de una sesión de partner podía seguir activa después de cerrar sesión si se había renovado por separado. Migramos las sesiones a una única identidad del lado del servidor: ahora el cierre de sesión normal revoca toda la sesión actual, mientras que «Cerrar sesión en todos los dispositivos» finaliza todas las sesiones activas.

MTA-STS e informes TLS activados

Un investigador de seguridad descubrió que MTA-STS y los informes TLS no estaban configurados para el correo entrante de createyourvpn.com. Publicamos una política MTA-STS y activamos los informes TLS. Al principio, la política funciona en modo de prueba mientras verificamos la ruta de reenvío de un tercero; activaremos la aplicación después de recibir informes sin errores.

Aplicación de DMARC activada

Un investigador de seguridad descubrió que la política DMARC de createyourvpn.com funcionaba únicamente en modo de supervisión y no exigía rechazar los mensajes que no superaban la validación. Activamos p=reject para el dominio principal y sp=reject para sus subdominios que no envían correo. El correo transaccional continúa aislado en subdominios de envío separados con sus propias políticas SPF, DKIM y DMARC.