Sitio web seguro: qué significa de verdad y cómo construirlo (guía completa)
Un sitio web seguro no es el que "parece" correcto, con el candado verde en la barra y un diseño cuidado. Es un sitio construido de forma que los datos de los usuarios sigan siendo privados, que nadie pueda acceder a funciones que no le corresponden y que una vulnerabilidad trivial no se convierta en un desastre. La diferencia es invisible hasta que pasa algo: una cuenta robada, una base de datos vaciada, una clave API en las manos equivocadas.
En esta guía vemos, sin jerga innecesaria, qué hace seguro a un sitio web, los pilares sobre los que se apoya, las amenazas más comunes y el caso particular de los sitios nacidos con IA. Es el artículo de referencia: desde aquí enlazamos a las profundizaciones prácticas.
Qué significa tener un sitio web seguro
La seguridad no es un interruptor que enciendes una vez: es una propiedad del sistema, la suma de muchas decisiones. Los expertos la resumen en tres principios, la tríada CIA:
- Confidencialidad: solo quien está autorizado puede ver un dato (contraseñas, pedidos, mensajes privados).
- Integridad: nadie puede alterar los datos sin permiso, desde el precio de un producto hasta el saldo de una cuenta.
- Disponibilidad: el sitio sigue accesible para quien lo necesita, incluso bajo ataque o tras una avería.
Un sitio es seguro cuando estos tres principios se mantienen incluso mientras alguien intenta, a propósito, romperlos. La seguridad se construye por capas: si un nivel cede, los demás contienen el daño, y la ausencia de un solo pilar puede bastar para hacerte daño.
Los pilares de un sitio web seguro
No hace falta implementarlos todos el mismo día, pero sí saber que existen y entender cuáles te faltan.
1. HTTPS y TLS: la conexión cifrada
El HTTPS cifra el tráfico entre el navegador del usuario y tu servidor. Sin él, cualquiera que esté en la misma red (el wifi de una cafetería) puede leer en claro contraseñas y datos. Hoy es el mínimo indispensable: los navegadores marcan como "No seguro" los sitios en HTTP simple y Google los penaliza.
Un certificado TLS válido, sin embargo, no basta. También debes forzar la redirección de HTTP a HTTPS, para que nadie se quede en la versión sin cifrar, y activar la cabecera HSTS, que obliga al navegador a usar siempre la conexión segura.
2. Autenticación y gestión de contraseñas
La autenticación responde a la pregunta "¿quién eres?". Es el punto más atacado de cualquier sitio, porque es la puerta de entrada. Las reglas mínimas:
- Las contraseñas de los usuarios deben guardarse con hashing (bcrypt, Argon2, scrypt), nunca en claro y nunca con algoritmos obsoletos como MD5.
- Hace falta protección contra los intentos repetidos de acceso (fuerza bruta): bloqueo temporal, retardos progresivos, captcha.
- La autenticación en dos pasos (2FA) debería estar disponible, al menos para las cuentas de administrador.
Una sola contraseña de administrador débil o reutilizada puede echar por tierra todo lo demás.
3. Autorización y control de accesos
Si la autenticación dice "quién eres", la autorización dice "qué puedes hacer". Aquí se esconde uno de los fallos más insidiosos: el usuario A que, cambiando un número en la URL, consigue ver el pedido del usuario B.
El principio guía es el privilegio mínimo: cada usuario, función y clave debe tener solo los permisos estrictamente necesarios. Cada endpoint que devuelve o modifica datos sensibles debe verificar, del lado del servidor, que quien lo llama tiene derecho a ello. No te fíes de las comprobaciones hechas solo en el frontend: se saltan en segundos.
4. Protección de datos y privacidad
Un sitio seguro protege los datos no solo mientras viajan (HTTPS) sino también mientras están guardados en la base de datos: cifrar los más sensibles, recoger solo lo que realmente hace falta (minimización) y tratarlos conforme al RGPD. La parte de privacidad la descuidan a menudo los makers, pero es parte integrante de la seguridad: banner de cookies conforme, información clara, consentimiento recogido correctamente. No es solo riesgo de multa, es confianza.
5. Cabeceras de seguridad HTTP
Las cabeceras de seguridad son instrucciones que el servidor envía al navegador para activar protecciones adicionales. Cuestan poco y bloquean clases enteras de ataques. Las principales:
| Cabecera | Para qué sirve |
|---|---|
Content-Security-Policy | Limita desde dónde se pueden cargar scripts y recursos, reduce el XSS |
Strict-Transport-Security | Impone el uso de HTTPS (HSTS) |
X-Content-Type-Options | Impide que el navegador "adivine" el tipo de archivo |
X-Frame-Options | Bloquea el clickjacking (tu sitio enmarcado en sitios maliciosos) |
Referrer-Policy | Controla qué información se pasa a otros sitios |
Muchos sitios generados con prisa salen online sin ninguna de estas cabeceras: una de las carencias más comunes y más fáciles de corregir.
6. Actualizaciones, parches y dependencias
Gran parte de los ataques no aprovecha trucos geniales, sino vulnerabilidades ya conocidas en librerías y componentes sin actualizar. Un plugin viejo o una dependencia con un fallo público son puertas abiertas anunciadas a todos. Mantén una lista de tus dependencias, actualízalas con regularidad y usa herramientas que te avisen cuando aparezca una vulnerabilidad conocida.
7. Copias de seguridad y restauración
La copia de seguridad no impide un ataque, pero es lo que te salva cuando todo lo demás ha fallado. Un sitio web seguro tiene copias automáticas, periódicas y probadas, guardadas separadas del servidor principal. La pregunta correcta no es "¿hago copias?" sino "¿cuánto tardo en volver a publicarlas si mañana desaparece el sitio?".
8. Rate limiting y protección de las API
El rate limiting pone un techo al número de peticiones que un solo usuario puede hacer en un tiempo dado. Sin él, un atacante puede probar miles de contraseñas por minuto, saturar el servidor o agotar tu presupuesto. Es esencial en accesos, formularios y API públicas.
9. Gestión de secretos y claves API
Las claves API, las contraseñas de la base de datos y los tokens de acceso son las llaves de tu casa. No deben acabar nunca en el código público, en el repositorio de GitHub ni, peor aún, en el JavaScript que descarga el navegador del usuario. Van en variables de entorno o en gestores de secretos, con permisos mínimos. Una clave expuesta es uno de los problemas más graves y frecuentes, y muchas veces nadie se da cuenta hasta que llega la factura.
Las amenazas más comunes, explicadas de forma sencilla
Estas son las amenazas que más golpean a los sitios de makers y pymes.
- Cross-Site Scripting (XSS): el atacante inyecta código (normalmente JavaScript) en una página, que después se ejecuta en el navegador de otros usuarios para robar sesiones o datos. Nace de mostrar la entrada de los usuarios sin "limpiarla". Defensa: validar toda entrada y usar la Content-Security-Policy.
- Inyección SQL: comandos maliciosos introducidos en los campos del sitio los ejecuta la base de datos, permitiendo leer o borrar datos. Defensa: usar siempre consultas parametrizadas.
- Datos y credenciales expuestos: claves API en el código, archivos de configuración accesibles, endpoints demasiado generosos, paneles de administración sin protección. A menudo no hace falta un ataque sofisticado: basta mirar en el sitio adecuado. Es la categoría que más pesa en la práctica.
- Credenciales débiles y reutilizadas: contraseñas como "admin123", cuentas sin 2FA, credenciales recicladas de servicios ya vulnerados. La forma más barata de entrar, sin conocimientos técnicos.
El caso de los sitios hechos con IA (vibe coding)
Construir un sitio o una aplicación escribiendo prompts a un asistente de IA, el llamado vibe coding, ya es normal: rápido, potente, al alcance de cualquiera. Pero hay un problema recurrente: la IA optimiza para "hacer que la cosa funcione", no para que sea segura.
El resultado es que muchísimos sitios generados con IA salen online con los mismos fallos estándar: claves API escritas en el código o en el frontend, endpoints que devuelven datos sin comprobar quién los pide, ningún rate limiting en formularios y accesos, cabeceras de seguridad ausentes, cookies y privacidad no conformes.
No es culpa tuya si no las conocías: el código "funciona", el sitio se ve, todo parece correcto. El problema es que estos fallos no se ven desde la página de inicio. Por eso existen herramientas como Appurai, que escanean un sitio o una aplicación y muestran dónde están los agujeros —claves expuestas, endpoints abiertos, cabeceras que faltan, problemas de RGPD— incluso cuando el proyecto ha nacido entero de prompts de IA. Si has construido así, merece la pena profundizar en los riesgos específicos en nuestra guía del vibe coding.
Cómo hacer seguro un sitio: por dónde empezar
Para quien no tiene un equipo dedicado, el orden sensato es este:
- Haz una foto del estado actual. Antes de corregir hay que saber qué está roto: un test de seguridad del sitio web te da la lista concreta de problemas.
- Cierra lo grave y rápido. Claves expuestas, endpoints sin autenticación, HTTPS ausente: alto impacto, poco esfuerzo.
- Añade las capas que faltan. Cabeceras de seguridad, rate limiting, 2FA para los administradores.
- Monta la rutina. Copias automáticas, actualización de dependencias, revisiones periódicas.
- Comprueba que lo has resuelto de verdad. Repite el test: la guía sobre cómo comprobar la seguridad de un sitio te explica cómo asegurarte de que los fallos están cerrados.
La seguridad no es un proyecto con fecha de fin: es un hábito. Pero el primer escaneo honesto es el que más mueve la aguja.
Preguntas frecuentes
¿Basta el HTTPS para tener un sitio web seguro?
No. El HTTPS cifra la conexión y es imprescindible, pero solo protege los datos en tránsito. Un sitio puede tener el candado verde y a la vez exponer claves API o ser vulnerable a inyección SQL. Es un pilar, no la casa entera.
¿Cuánto cuesta hacer seguro un sitio?
Muchas correcciones importantes —forzar el HTTPS, añadir cabeceras, mover las claves a variables de entorno, activar el rate limiting— no cuestan nada en licencias, solo tiempo. El coste real es saber qué corregir: por eso el escaneo inicial es el que más rinde.
Mi sitio es pequeño, ¿de verdad le puede interesar a alguien?
Sí. La mayoría de los ataques son automáticos: bots que escanean internet buscando fallos conocidos, sin importarles qué es tu sitio. Un sitio pequeño con una clave expuesta es un objetivo igual que uno grande.
¿Un sitio hecho con IA es menos seguro?
En la práctica, a menudo sí. Los asistentes de IA generan código que funciona sin aplicar necesariamente las buenas prácticas de seguridad, así que muchos proyectos nacidos de prompts salen con fallos recurrentes. Y todo parece correcto porque el sitio se ve: eso es justo lo que lo hace traicionero.
¿Cada cuánto hay que revisar la seguridad de un sitio?
Idealmente de forma continua, y en todo caso en cada cambio importante: nuevas funciones, dependencias y endpoints introducen nuevos riesgos. Una revisión periódica automática gana a una comprobación puntual que envejece deprisa. Si sospechas que ya te han atacado, la prioridad cambia: lee qué hacer si el sitio ha sido hackeado.
En resumen
Un sitio web seguro es el resultado de varias capas trabajando juntas, desde lo fundamental como HTTPS y autenticación hasta las copias de seguridad, el rate limiting y la gestión de secretos. Ninguna, por sí sola, te pone a salvo. La buena noticia es que no hace falta ser experto para empezar: solo hay que saber dónde mirar. Un escaneo automático como el de Appurai te muestra gratis dónde están los problemas de tu sitio, desde las claves expuestas hasta el RGPD, y si quieres te explica paso a paso cómo arreglarlos.