Seguridad de 300 Startups Españolas: Análisis

¿Qué vería un atacante si mirara tu startup desde fuera? Sin entrar en tu red, sin credenciales, sin explotar nada. Solo observando lo que es público.

En Vulnerabbit hemos dedicado varias semanas a hacer exactamente eso: analizar la huella digital pública de más de 300 startups españolas. Empresas que han pasado por aceleradoras, que han levantado rondas, que presentan en eventos internacionales. No son proyectos en fase idea: tienen producto, clientes y datos reales.

El objetivo no era señalar a nadie. Era responder una pregunta que nos hacíamos internamente: ¿cuál es el estado real de la seguridad en el ecosistema startup español? Los resultados nos sorprendieron incluso a nosotros.

Origen de los Datos: Información de Dominio Público

Los datos presentados en este artículo se han obtenido exclusivamente mediante la agregación y análisis de información pública en internet. La recopilación se ha limitado a leer registros DNS, metadatos de dominios y cabeceras de respuestas públicas devueltas de manera estándar por los servidores en abierto, tal como las recibiría el navegador de cualquier visitante ordinario de la web.

Analizamos más de 300 dominios pertenecientes a startups de distintos sectores: HealthTech, FinTech, EdTech, AI, Movilidad, PropTech, Energía, Biotech y más. Las empresas provienen de aceleradoras, rankings de referencia del ecosistema español, eventos internacionales y rondas de financiación recientes.

En total, 300 dominios resultaron elegibles para el análisis (los 6 restantes tenían la web caída o aparcada). Toda la información evaluada es accesible de forma general y abierta, sin requerir ningún tipo de interacción especial o técnica agresiva, reflejando de forma precisa la huella digital pública de cada entidad en la actualidad.

El Panorama General: La Mitad Tiene Problemas Graves

El primer dato que salta a la vista es la distribución de severidad. Asignamos una puntuación a cada dominio combinando todos los problemas encontrados, y el resultado es contundente:

La mitad de las startups analizadas tienen severidad CRITICAL. Esto no significa que estén siendo atacadas ahora mismo, pero sí que tienen múltiples puertas abiertas que un atacante con conocimientos básicos podría aprovechar. Y cuando decimos "básicos", lo decimos en serio: nada de lo que encontramos requiere herramientas especiales ni conocimientos avanzados.

El 13% que está en LOW no es que sea perfecto, pero tiene la casa razonablemente en orden. Son startups que claramente han dedicado algo de tiempo a revisar su configuración externa. El problema es que representan una minoría.

Email: 1 de Cada 3 Startups Permite que Suplanten su Identidad

De todos los hallazgos, este es posiblemente el más preocupante por su impacto directo en el negocio. La suplantación de email (o email spoofing) consiste en que alguien envíe un correo que parece venir de tu empresa, pero no lo es. El destinatario ve tu nombre, tu dominio, tu dirección de email… pero el mensaje lo ha enviado un atacante.

¿Por qué es tan peligroso? Porque los ataques de ingeniería social basados en email siguen siendo, con diferencia, el vector más utilizado para comprometer empresas. Un email falso que parece venir de tu CEO pidiendo una transferencia urgente. Un correo a tu inversor comunicando "nuevos datos bancarios". Una factura falsa enviada a tu cliente más importante desde una dirección que parece legítima.

Vamos a desglosar esto porque los números son llamativos.

¿Qué son SPF y DMARC?

Imagina que el email funciona como el correo postal tradicional. Cualquiera puede escribir el remitente que quiera en un sobre. SPF y DMARC son como un sistema de verificación en la oficina de correos que comprueba si el sobre realmente viene de donde dice venir.

SPF (Sender Policy Framework) es una lista que publica tu empresa diciendo "estos son los servidores autorizados para enviar email en nuestro nombre". Si un email llega desde un servidor que no está en la lista, el receptor sabe que algo no cuadra.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) va un paso más allá: le dice al receptor qué hacer cuando llega un email sospechoso. Puede decirle "recházalo" (reject), "ponlo en cuarentena" (quarantine) o simplemente "anótalo pero déjalo pasar" (none).

Los datos del estudio

55 startups (18%) no tienen ni siquiera SPF configurado. Esto significa que no hay ninguna verificación del remitente: cualquier servidor del mundo puede enviar un email que diga venir de su dominio, y no hay forma de distinguirlo del legítimo.

118 startups (39%) no tienen DMARC configurado. Aunque tengan SPF, sin DMARC no hay instrucciones para el servidor receptor sobre qué hacer con emails sospechosos. La mayoría de proveedores de correo los deja pasar igualmente.

117 startups (39%) tienen DMARC pero en modo "none" (solo observar). Este modo fue diseñado para una fase de pruebas de unas semanas mientras verificas que tu configuración es correcta antes de activar el bloqueo. En la práctica, muchas empresas lo activan y nunca pasan al modo que realmente bloquea. Es como instalar una alarma pero dejarla en modo silencioso permanentemente.

Solo 23 startups (8%) tienen la protección completa: SPF correctamente configurado y DMARC en modo "reject" (rechazar emails falsos). El otro 92% está expuesto en mayor o menor grado.

Al observar detalladamente las políticas publicadas en sus registros DNS, los datos técnicos confirman el riesgo: las configuraciones de 119 de los dominios analizados permitirían que un email falso llegara a la bandeja de entrada del destinatario. Sin marcas de spam, sin advertencias. Un email perfectamente convincente enviado desde cualquier servidor del mundo, sin que los sistemas receptores tengan instrucciones para detenerlo.

¿Cuánto cuesta arreglarlo?

Este es uno de esos problemas que se arregla en una tarde. Configurar SPF y DMARC correctamente son cambios en los registros DNS de tu dominio (tu proveedor de hosting o dominio te permite editarlos). No requiere instalar nada, no tiene coste y protege toda la comunicación por email de tu empresa.

El proceso típico es: configurar SPF con los servidores que usas (Google Workspace, Microsoft 365, tu proveedor de email marketing), activar DMARC en modo "none" durante una o dos semanas para verificar que todo funciona, y luego pasar a "reject". Si usas Google Workspace o Microsoft 365, ambos tienen documentación paso a paso.

Cifrado Web: El 93% Usa Protocolos Obsoletos Desde 2020

El dato más extendido del estudio: 282 de las 300 startups (94%) aún aceptan conexiones con TLS 1.0 y TLS 1.1, protocolos de cifrado que fueron oficialmente retirados en 2020 por la IETF (el organismo que define los estándares de internet).

¿Qué son TLS 1.0 y TLS 1.1 y por qué importa?

Cuando visitas una web que empieza por "https", tu navegador y el servidor establecen una conexión cifrada para que nadie pueda interceptar lo que envías (contraseñas, datos de pago, información personal). TLS es el protocolo que gestiona ese cifrado.

TLS 1.0 se publicó en 1999. TLS 1.1 en 2006. Ambos tienen vulnerabilidades conocidas y documentadas que permiten a un atacante, en determinadas condiciones, interceptar o manipular la comunicación cifrada. Por eso se retiraron oficialmente y los navegadores modernos ya no los utilizan.

¿Entonces cuál es el problema? Que aunque los navegadores modernos ya no usan estos protocolos, el servidor los sigue aceptando. Esto significa que herramientas automatizadas, bots, clientes de API o dispositivos antiguos pueden conectar con un cifrado débil. Y en ciertos escenarios, un atacante puede forzar una conexión a usar el protocolo más débil disponible (lo que se conoce como "downgrade attack").

Es como si tu casa tuviera una cerradura moderna en la puerta principal, pero también una cerradura antigua oxidada en una puerta lateral que se puede forzar con un destornillador. La mayoría de visitas entra por la puerta principal, pero la lateral sigue ahí.

Cabeceras de Seguridad: La Protección que Casi Nadie Activa

Las cabeceras HTTP de seguridad son instrucciones que tu servidor web envía al navegador del visitante para activar protecciones adicionales. No requieren cambios en tu aplicación, solo configuración en el servidor. Y sin embargo, la mayoría de startups no las tiene.

El 78% de las startups no tiene Content Security Policy (CSP). Esta cabecera es la principal defensa contra ataques de inyección de código (XSS), que siguen siendo uno de los ataques web más comunes. Sin CSP, si un atacante encuentra una forma de inyectar un script en tu web (por ejemplo, a través de un campo de búsqueda o un comentario), ese script se ejecuta con todos los permisos, pudiendo robar sesiones de usuario, datos de formularios o redirigir a páginas falsas.

El 55% no tiene HSTS. Sin esta cabecera, la primera conexión de un usuario a tu web puede ser interceptada antes de que el navegador redirija a HTTPS. En redes Wi-Fi públicas (cafeterías, aeropuertos, coworkings), este tipo de interceptación es trivial.

La media de cabeceras de seguridad ausentes por startup fue de 2 de las principales, con algunas llegando a tener las 7 principales sin configurar.

Infraestructura: Bases de Datos y Servicios Internos Visibles Desde Internet

Aquí es donde los datos se ponen más serios. 66 startups tienen servicios críticos accesibles directamente desde internet que nunca deberían estar expuestos. Estamos hablando de puertos que dan acceso a bases de datos y servicios de transferencia de archivos.

Para ser claros: que un puerto esté abierto no significa que se pueda acceder sin contraseña. Pero el simple hecho de que una base de datos sea accesible desde internet ya es un problema de seguridad grave. Las bases de datos deben vivir en redes internas, accesibles solo desde los servidores de tu aplicación. Exponerlas a internet multiplica exponencialmente la superficie de ataque: un atacante puede intentar fuerza bruta de credenciales, explotar vulnerabilidades conocidas del motor de base de datos, o simplemente probar credenciales por defecto que no se cambiaron.

FTP en 2026

Un dato que llama especialmente la atención: más de 58 startups aún tienen FTP abierto a internet. FTP es un protocolo de los años 70 que transmite todo en texto plano, incluyendo las contraseñas. En 2026, no hay ningún motivo para usarlo cuando existen alternativas seguras como SFTP o SCP. Tener FTP abierto a internet es, literalmente, un servicio que envía tus credenciales sin cifrar.

Subdominios Huérfanos: La Superficie de Ataque que Nadie Vigila

El dato más sorprendente del estudio por su volumen: 218 startups (73%) tienen subdominios o dominios alternativos que apuntan a servicios abandonados, IPs de terceros o infraestructura que ya no controlan.

¿Qué es un subdominio huérfano y por qué debería importarte?

Cuando tu startup crece, vas creando subdominios para distintos usos: staging.tuapp.com, blog.tuapp.com, old-api.tuapp.com, test.tuapp.com. También registras dominios alternativos (el .es, el .io, el .app). Con el tiempo, algunos dejan de usarse pero los registros DNS siguen apuntando a algún sitio: un servidor que ya diste de baja, un servicio de hosting que ya no usas, una IP que ahora pertenece a otra persona.

Un atacante puede aprovechar esto de varias formas. La más directa es el "subdomain takeover": si tu subdominio apunta a un servicio cloud que ya no tienes (por ejemplo, una instancia de Heroku, GitHub Pages o S3 que eliminaste), un atacante puede reclamar ese recurso y servir su propio contenido bajo tu dominio. Desde ahí puede montar una página de phishing que parece legítima porque está bajo tu dominio real, alojar malware con tu reputación, o interceptar cookies de sesión si el subdominio comparte el dominio principal.

La media de subdominios por startup fue de 7, con alguna llegando a 60. Y 112 startups tenían más de 5 subdominios, lo que aumenta significativamente la probabilidad de que alguno esté huérfano o mal configurado.

¿Por Qué Pasa Esto?

Los datos pintan un panorama que puede parecer alarmante, pero el "por qué" es bastante comprensible cuando lo piensas desde la perspectiva de una startup.

Las startups crecen rápido. Se añaden servidores, se prueban dominios, se configura infraestructura "para ya" y se deja para revisar "cuando haya tiempo". Pero ese momento rara vez llega. Y con cada sprint, cada nueva feature, cada nuevo despliegue, se acumula lo que en seguridad llamamos "deuda técnica de seguridad": configuraciones temporales que se vuelven permanentes.

No hay equipo de seguridad dedicado. La inmensa mayoría de startups no tiene un CISO, un equipo de seguridad ni siquiera un desarrollador con formación específica en seguridad. La seguridad recae en el mismo equipo que está construyendo el producto, resolviendo bugs y atendiendo a clientes. Es comprensible que no sea la prioridad.

La seguridad se percibe como compleja y cara. Muchos fundadores asumen que "hacer seguridad bien" requiere consultoras caras, certificaciones interminables y meses de trabajo. Y sí, eso existe. Pero lo que muestran estos datos es que los problemas más graves se arreglan con cambios de configuración que llevan horas, no meses.

No hay visibilidad del problema. Este es quizá el punto más importante: la mayoría de estas startups no saben que están expuestas. Si no miras, no ves. Y si no ves, asumes que todo está bien. Hasta que pasa algo.

Lo Bueno: La Mayoría Se Puede Arreglar en Días, No en Meses

Aquí viene la parte que esperamos sea la más útil de este post. La mayoría de los problemas que hemos encontrado no requieren presupuesto, herramientas caras ni consultores externos. Son cambios de configuración que se pueden hacer en una tarde con documentación pública.

El coste total de arreglar los problemas más graves de este estudio es, literalmente, unas pocas horas de trabajo de alguien de tu equipo técnico y cero euros. Lo difícil no es arreglarlos. Lo difícil es saber que existen.

Checklist Rápido: ¿Tu Startup Está Expuesta?

Si quieres hacer una comprobación rápida de tu propia startup sin esperar a que alguien analice tu exposición pública, aquí tienes los cinco checks más importantes que puedes hacer en diez minutos:

Si no tienes un equipo técnico que pueda ejecutar estos comandos, también puedes usar herramientas web gratuitas como MXToolbox (para email), SSL Labs (para TLS) y SecurityHeaders.com (para cabeceras). No requieren instalación ni conocimientos técnicos.

Cómo Ayuda Vulnerabbit

Este estudio ilustra una parte de la visibilidad externa que proporcionamos en Vulnerabbit para nuestros clientes. La diferencia es que para nuestros clientes, de forma explícitamente autorizada, lo hacemos en profundidad y de manera continua: no con una observación pasiva puntual, sino con una monitorización constante que detecta cambios y nuevas exposiciones en tiempo real.

Vulnerabbit analiza tu superficie de ataque externa de forma automática y recurrente. Si alguien de tu equipo abre un puerto que no debería estar abierto, si un subdominio nuevo se crea sin las protecciones adecuadas, si tu configuración de email cambia a un estado inseguro, te avisamos antes de que un atacante lo encuentre.

Y lo hacemos sin tecnicismos innecesarios: cada hallazgo viene con una explicación clara de por qué es un problema, cuál es el riesgo real y los pasos exactos para arreglarlo, adaptados a tu stack y tu proveedor de cloud.

Si quieres saber qué vería un atacante mirando tu startup desde fuera, puedes lanzar un análisis gratuito en dos minutos. Sin tarjeta, sin compromiso. Solo la verdad sobre tu superficie de ataque.