Seguridad básica de un sitio web: HTTPS, cabeceras y scripts

En un sitio público, el primer paso de seguridad es comprobar lo que cualquier visitante (o atacante) ve desde fuera: si todo acceso va a HTTPS, si el servidor acepta solo TLS 1.2 y 1.3 con un certificado válido, si están presentes las cabeceras de seguridad, si la página carga algo por HTTP, si hay archivos como .env, .git o copias de seguridad accesibles, si el CMS y los plugins están actualizados, qué scripts de terceros se ejecutan en la página y cómo se guardan las cookies. Estos puntos cubren configuración y exposición. No dicen si el código tiene fallos, si las contraseñas están bien guardadas ni si el panel de administración resiste ataques.

Esta guía sirve para sitios y tiendas en línea que se usan desde el navegador, con las normas y recomendaciones vigentes en octubre de 2026. Cada sección explica el punto, cómo comprobarlo y dónde profundizar. Los detalles de cada cabecera están en el artículo sobre cabeceras HTTP de seguridad, y las reglas para scripts en páginas de pago están en el texto sobre PCI DSS 4.0 y los requisitos 6.4.3 y 11.6.1.

Qué ve y qué no ve una verificación externa

Una verificación externa hace peticiones al sitio como lo haría un navegador y analiza las respuestas: estado HTTP, redirecciones, cabeceras, certificado, HTML y los recursos que pide la página. HTTP Observatory, la herramienta gratuita de Mozilla, sigue esa línea. Su propia documentación dice que la prueba se centra en datos HTTP y no busca versiones desactualizadas de software, inyección SQL, plugins vulnerables de CMS ni almacenamiento inadecuado de contraseñas (FAQ de HTTP Observatory).

Por eso una nota alta en una herramienta externa muestra que las protecciones básicas de configuración están en su sitio. No certifica que el sitio sea seguro. Mozilla hace la misma advertencia: quien tiene buena nota no debe dejar de lado los problemas que la herramienta no prueba (FAQ de HTTP Observatory).

Una salvedad antes de empezar: leer cabeceras y certificado es lo que hace cualquier navegador. Buscar archivos ocultos o forzar protocolos antiguos ya es una prueba activa, y solo debe hacerse en sitios que administras o con autorización del responsable.

HTTPS y la redirección de http a https

HTTPS es HTTP dentro de una conexión cifrada con TLS (Transport Layer Security), el protocolo que protege los datos entre el navegador y el servidor. Todo el sitio debe responder en HTTPS, y quien llega por http:// debe ser redirigido a la misma dirección en https://. La indicación de Mozilla es que, en el puerto 80, el servidor solo redirija al mismo recurso en HTTPS. Si el dominio final es otro (por ejemplo, sin y con www), el primer salto debe ir a HTTPS en el mismo host, y solo después al otro host (MDN: guía práctica de TLS). HTTP Observatory penaliza el caso en que el primer salto ya cambia de host (FAQ de HTTP Observatory).

Para comprobarlo en la terminal, pide solo las cabeceras de la versión http:

curl -sI http://ejemplo.com/

La respuesta esperada es un 301 o 308 con Location: https://ejemplo.com/. Un 200 en http significa que el sitio todavía sirve contenido sin cifrar. Las API y las áreas que no son para el público pueden directamente desactivar HTTP (MDN: guía práctica de TLS). Las cadenas largas de redirecciones también retrasan la página; el artículo sobre redirecciones, cadenas y bucles trata ese aspecto.

Versión de TLS y validez del certificado

La IETF declaró obsoletos TLS 1.0 y TLS 1.1 en 2021: el RFC 8996 dice que ninguno de los dos debe usarse ni negociarse (RFC 8996). OWASP ASVS 5.0, el estándar de verificación de seguridad de aplicaciones, pide que solo estén activas las versiones recomendadas, como TLS 1.2 y TLS 1.3, con la más nueva como preferida (ASVS 5.0, requisito 12.1.1), y que los servicios expuestos usen certificados emitidos por autoridades de confianza pública (requisito 12.2.2).

Para ver si el servidor todavía acepta TLS 1.1 y cuándo vence el certificado, basta con OpenSSL:

# debe fallar si TLS 1.1 está desactivado
openssl s_client -connect ejemplo.com:443 -servername ejemplo.com -tls1_1 </dev/null

# fechas de inicio y fin del certificado
openssl s_client -connect ejemplo.com:443 -servername ejemplo.com </dev/null 2>/dev/null \
  | openssl x509 -noout -dates

La validez de los certificados se está acortando. En abril de 2025 el CA/Browser Forum, que reúne a autoridades de certificación y navegadores, aprobó reducir de forma gradual la validez máxima de 398 a 47 días, entre marzo de 2026 y marzo de 2029 (Ballot SC-081v3). Según el calendario publicado por DigiCert, el límite es de 200 días para certificados emitidos a partir del 15 de marzo de 2026, 100 días a partir del 15 de marzo de 2027 y 47 días a partir del 15 de marzo de 2029 (DigiCert). Con plazos así, renovar a mano se convierte en riesgo de tener el sitio caído por un certificado vencido. Recomendación: automatizar la renovación y tener una alerta independiente para el vencimiento.

HSTS

La redirección por sí sola deja un hueco: la primera petición en http todavía viaja sin cifrar. La cabecera Strict-Transport-Security (HSTS) le dice al navegador que use solo HTTPS en ese dominio durante el tiempo definido en max-age, y a partir de ahí el navegador convierte por su cuenta los enlaces http y no deja que el usuario ignore errores de certificado (MDN: Strict-Transport-Security). ASVS pide como mínimo un año de max-age (ASVS 5.0, requisito 3.4.1). Antes de incluir subdominios o pedir la entrada en la lista de precarga de los navegadores, comprueba que todos los subdominios funcionan en HTTPS; los detalles están en el artículo sobre cabeceras HTTP de seguridad.

Cabeceras de seguridad, en una visión general

Las cabeceras de respuesta HTTP le dicen al navegador qué puede hacer con la página: de dónde cargar scripts, si la página puede mostrarse dentro de otra, qué información enviar a otros sitios. No corrigen fallos del código, pero reducen lo que un atacante puede hacer con ellos. La tabla resume las principales.

Mozilla mantiene guías prácticas para cada punto, en un orden de implantación sugerido según el impacto y la dificultad, y HTTP Observatory remite a la guía de cada problema que encuentra (MDN: guías prácticas de seguridad). ASVS 5.0 también incluye estas cabeceras entre los requisitos de front-end (ASVS 5.0, capítulo V3). Los valores recomendados, ejemplos y lo que cada una puede romper están en el artículo sobre cabeceras HTTP de seguridad.

Contenido mixto

Hay contenido mixto cuando una página cargada en HTTPS pide recursos por HTTP. Esos recursos se pueden leer o alterar por el camino. Los navegadores actuales convierten a HTTPS las imágenes, el audio y el vídeo pedidos por http y bloquean los demás tipos, como scripts, hojas de estilo, iframes, fuentes y llamadas fetch() (MDN: contenido mixto). En la práctica, el síntoma más común es una parte de la página que desaparece o deja de funcionar sin un error visible.

Para encontrarlo, abre la consola del navegador: ahí aparecen los avisos de contenido mixto. La corrección es cambiar las direcciones a https o a rutas relativas. La directiva upgrade-insecure-requests de la CSP hace que el navegador convierta esas peticiones a HTTPS, pero no sustituye a HSTS y solo funciona si el recurso existe en HTTPS (MDN: guía de CSP). En un CMS, las direcciones en http suelen estar guardadas en la base de datos, en entradas antiguas o en la configuración del tema.

Archivos expuestos y listado de directorios

Un sitio puede exponer sin querer archivos que no deberían estar en la carpeta pública: copias como login.php.old, archivos .zip o .tar.gz de copia de seguridad, copias automáticas de editores (como archivo~), archivos de configuración y carpetas de control de versiones. La guía de pruebas de OWASP recoge este problema (WSTG-CONF-04) y explica el riesgo: una copia con otra extensión puede entregarse como texto, con el código fuente y a veces credenciales de la base de datos (OWASP WSTG, WSTG-CONF-04). El robots.txt no oculta estos archivos: solo pide a los robots que no rastreen una ruta, y cualquier persona puede leerlo (RFC 9309).

ASVS 5.0 tiene requisitos directos para esto (ASVS 5.0, sección V13.4):

• La aplicación pasa a producción sin metadatos de control de versiones, como las carpetas .git y .svn, o con esas carpetas inaccesibles (13.4.1).

• El servidor no muestra el listado de directorios, la página automática con los archivos de una carpeta, salvo que sea intencionado (13.4.3).

• El servidor entrega solo archivos con extensiones concretas, para no filtrar configuración y código fuente (13.4.7).

El archivo .env merece atención aparte: muchos frameworks usan ese nombre para guardar contraseñas de base de datos, claves de API y otros secretos en texto plano. Debe quedar fuera de la carpeta pública. En tu propio sitio, una comprobación rápida es pedir esas rutas y ver el estado:

for p in .env .git/HEAD backup.zip wp-config.php.bak; do
  printf '%s ' "$p"; curl -s -o /dev/null -w '%{http_code}\n' "https://ejemplo.com/$p"
done

Lo esperado es 403 o 404. Cuidado con los sitios que responden 200 para cualquier dirección con una página de error propia: en ese caso, revisa el contenido devuelto, no solo el estado. La lista de arriba es un punto de partida, no un inventario completo; el nombre de las copias de seguridad cambia según el plugin o el panel del hosting.

Versiones de software, CMS y plugins

Los componentes desactualizados siguen entre los riesgos centrales de OWASP. En el Top 10 de 2025, la categoría A03, fallos en la cadena de suministro de software, amplía la antigua categoría de componentes vulnerables y desactualizados e incluye el caso de no seguir las versiones de todo lo que se usa, en el servidor y en el navegador (OWASP Top 10:2025, A03). Las recomendaciones incluyen mantener un inventario de los componentes, quitar dependencias y funciones sin uso, obtener componentes solo de fuentes oficiales y aplicar parches según el riesgo, sin esperar a un ciclo mensual o trimestral.

En un sitio con CMS, esto significa actualizar el núcleo, el tema y los plugins, borrar los plugins desactivados (el código desactivado sigue en el servidor) y seguir los avisos de seguridad de los proveedores. Desde fuera, una revisión solo ve la versión que el sitio anuncia, en cabeceras como Server y X-Powered-By o en metaetiquetas del HTML. OWASP recomienda quitar esas cabeceras (OWASP Secure Headers Project, lista de cabeceras a quitar), y ASVS recuerda que ocultar la versión no elimina la necesidad de actualizar (ASVS 5.0, sección V13.4). Dicho de otro modo, no ver la versión desde fuera no significa que esté al día.

Scripts de terceros como riesgo de cadena de suministro

Cada script cargado desde otro dominio (chat, analítica, píxel de anuncios, gestor de etiquetas, widget de reseñas) se ejecuta con los mismos permisos que los scripts del propio sitio. Si el proveedor sufre un ataque o cambia el archivo, el código nuevo se ejecuta en tu página sin ningún cambio en tu servidor. PCI DSS describe este riesgo en la guía del requisito 6.4.3: scripts en apariencia inofensivos pueden usarse para cargar código malicioso que lee los datos de la tarjeta y los envía fuera (PCI DSS v4.0.1, requisito 6.4.3).

Las medidas básicas son tres. La primera es tener un inventario: qué scripts carga cada página, de dónde y por qué. La segunda es verificar la integridad cuando se pueda: el atributo integrity (SRI, Subresource Integrity) hace que el navegador rechace un archivo cuyo contenido no coincide con el hash declarado, y ASVS pide SRI para recursos estáticos y versionados alojados fuera (ASVS 5.0, requisito 3.6.1; MDN: SRI). La tercera es limitar los orígenes con una CSP. SRI no sirve para scripts que el proveedor actualiza sin cambiar la dirección, y ahí es donde entran el inventario y la monitorización. En las páginas de pago esto dejó de ser solo una buena práctica: consulta el artículo sobre los requisitos 6.4.3 y 11.6.1 de PCI DSS. Esos mismos scripts también envían datos de los visitantes a terceros, algo que en Brasil entra en la LGPD (Lei Geral de Proteção de Dados, la ley brasileña de protección de datos), tema del artículo sobre píxeles y scripts de terceros.

Formularios y cookies

Los formularios de contacto, login y checkout deben servirse y enviarse por HTTPS. Un formulario en una página HTTPS que envía a una dirección http expone los datos en el envío.

Las cookies de sesión y de login necesitan tres atributos (MDN: Set-Cookie):

Sin SameSite, algunos navegadores aplican Lax por defecto, de forma algo más permisiva que el Lax explícito (MDN: Set-Cookie; web.dev: SameSite cookies explained). Lo más seguro es declarar el valor. ASVS 5.0 va más allá y pide los prefijos __Host- o __Secure- en el nombre de las cookies, que hacen que el navegador rechace la cookie si no tiene Secure y, en el caso de __Host-, si tiene atributo Domain o una ruta distinta de / (ASVS 5.0, requisitos 3.3.1 a 3.3.4).

Para comprobarlo, abre el panel de cookies de DevTools (pestaña Application en Chrome) después de iniciar sesión y mira las columnas Secure, HttpOnly y SameSite de cada cookie. Las cookies de herramientas de terceros las graban esas herramientas, y no siempre se pueden cambiar sus atributos.

Por dónde empezar

Un orden práctico, de lo más sencillo y con más efecto a lo más laborioso, inspirado en la secuencia de las guías de Mozilla (MDN: guías prácticas de seguridad). Es una recomendación, no una regla; un e-commerce con checkout propio debería adelantar el paso de los scripts.

1. Servir todas las páginas en HTTPS, con la redirección de http a https en el mismo host.

2. Desactivar TLS 1.0 y 1.1 y automatizar la renovación del certificado, con alerta de vencimiento.

3. Buscar y quitar archivos expuestos (.env, .git, copias de seguridad) y desactivar el listado de directorios.

4. Actualizar el CMS, el tema y los plugins y borrar lo que no se usa.

5. Corregir el contenido mixto y activar HSTS, primero con un max-age corto.

6. Revisar los atributos de las cookies de sesión.

7. Añadir las cabeceras sencillas (nosniff, Referrer-Policy, frame-ancestors) y empezar la CSP en modo de informe.

8. Hacer el inventario de los scripts de terceros y quitar los que no tienen motivo para estar ahí.

Cómo verificar tu sitio

Para cabeceras y redirección, HTTP Observatory de Mozilla es gratuito y explica cada punto. En WebVyze, el verificador de redirecciones, gratuito, muestra la cadena de saltos de una URL; pruébalo con la dirección en http:// para ver si el primer salto va a HTTPS en el mismo host. La auditoría de WebVyze, que el plan gratuito ejecuta una vez cada 30 días, revisa HTTPS, la validez del certificado TLS, HSTS, si otros sitios pueden incrustar la página, la presencia y el efecto de la CSP, los atributos Secure, HttpOnly y SameSite de las cookies, el atributo integrity en bibliotecas de CDN públicas, X-Content-Type-Options, Referrer-Policy, la versión de software que expone el servidor y los plugins o temas con vulnerabilidades conocidas. Para tiendas, los planes de pago mantienen un inventario de los scripts de las páginas de checkout, ligado a los requisitos 6.4.3 y 11.6.1 de PCI DSS 4.0. WebVyze solo lee páginas públicas y nunca modifica el sitio, así que ve lo que está en la tabla de la primera sección y nada más. Ninguna de estas herramientas sustituye una prueba de intrusión ni la revisión del código.