Cómo revisar la seguridad de tu sitio web sin hackear nada

Revisiones pasivas de seguridad para tiendas en línea: certificado TLS, HSTS, CSP, nosniff, cookies, contenido mixto, jQuery obsoleto, security.txt y DMARC.

Equipo editorial de FixReports12 min de lectura

Puedes revisar gran parte de la configuración de seguridad de una tienda en línea desde afuera, leyendo lo que el sitio ya envía a cada visitante: su certificado TLS, sus redirecciones, sus encabezados de respuesta HTTP, sus cookies, los scripts que carga y sus registros DNS públicos. Estas revisiones pasivas no envían tráfico de ataque ni requieren iniciar sesión, así que no le generan a la tienda más carga que una visita normal. Detectan fallas de configuración como un certificado a punto de vencer, la falta de HSTS, cookies inseguras, contenido mixto o una versión de jQuery con fallas conocidas. No son una prueba de penetración y no pueden demostrar que una tienda sea segura.

Puntos clave

  • Los certificados TLS de confianza pública emitidos desde el 15 de marzo de 2026 pueden tener una validez máxima de 200 días, que bajará a 100 días en marzo de 2027 y a 47 días en marzo de 2029 (CA/Browser Forum (se abre en una pestaña nueva)).
  • Los navegadores ignoran el encabezado HSTS cuando se envía por HTTP sin cifrar (MDN (se abre en una pestaña nueva)).
  • La directiva frame-ancestors de CSP no funciona en una etiqueta <meta>; tiene que enviarse como encabezado de respuesta (MDN (se abre en una pestaña nueva)).
  • Las versiones de jQuery anteriores a 3.5.0 están afectadas por dos vulnerabilidades XSS, y CISA agregó una de ellas, CVE-2020-11023, a su catálogo de vulnerabilidades explotadas conocidas (Known Exploited Vulnerabilities) el 23 de enero de 2025 (NVD (se abre en una pestaña nueva)).
  • Un archivo security.txt debe contener los campos Contact y Expires y estar publicado en /.well-known/security.txt (RFC 9116 (se abre en una pestaña nueva)).

¿Qué se considera una revisión de seguridad pasiva?

Una revisión pasiva solo lee lo que el sitio o su DNS devuelven ante una solicitud normal.

Eso significa cargar páginas públicas, leer el certificado y los encabezados de respuesta, listar las cookies y los scripts que establece una página y consultar los registros DNS públicos. Una revisión pasiva no adivina contraseñas, no envía cargas de inyección, no sondea las URL de administración ni escanea puertos. Todo lo que sigue se puede hacer con un navegador, curl, openssl y dig.

¿Cómo revisar tu certificado TLS y su fecha de vencimiento?

Lee directamente las fechas y los nombres del certificado, y asegúrate de que la renovación esté automatizada.

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

Verifica que notAfter esté bastante lejos en el futuro, que el certificado cubra tanto example.com como www.example.com si usas ambos (el visor de certificados del navegador muestra los nombres) y que el navegador no muestre advertencias. La vigencia de los certificados se está acortando según los Baseline Requirements del CA/Browser Forum (sección 6.3.2, versión 2.3.1 a octubre de 2026), a raíz de la votación SC-081v3 (se abre en una pestaña nueva) (Ballot SC-081v3), aprobada el 11 de abril de 2025:

Certificado emitidoValidez máxima
Antes del 15 de marzo de 2026398 días
Del 15 de marzo de 2026 al 14 de marzo de 2027200 días
Del 15 de marzo de 2027 al 14 de marzo de 2029100 días
Desde el 15 de marzo de 202947 días

Con vigencias tan cortas, la renovación manual es riesgosa, así que confirma que tu proveedor de hosting o tu herramienta de certificados los renueve automáticamente. Confirma también que HTTP sin cifrar redirija a HTTPS:

curl -sI http://example.com/ | grep -i -E "^HTTP|^location"

Lo que buscas es una respuesta 301 (o 308) con un encabezado location que empiece con https://.

¿Qué encabezados de seguridad debe enviar una tienda en línea?

Un pequeño conjunto de encabezados de respuesta bloquea ataques comunes del lado del navegador casi sin costo.

EncabezadoQué haceValor típicoFuente
Strict-Transport-SecurityIndica a los navegadores que usen solo HTTPS e impide que los usuarios ignoren los errores de certificadomax-age=31536000; includeSubDomainsMDN (se abre en una pestaña nueva)
Content-Security-Policy: frame-ancestorsControla qué sitios pueden incrustar tus páginas, lo que protege contra el clickjackingframe-ancestors 'self'MDN (se abre en una pestaña nueva)
X-Frame-OptionsControl de marcos más antiguo; OWASP dice que frame-ancestors lo vuelve obsoleto en los navegadores compatiblesDENY o SAMEORIGINOWASP (se abre en una pestaña nueva)
X-Content-Type-OptionsEvita el MIME sniffing y bloquea los scripts y las hojas de estilo servidos con el tipo incorrectonosniffMDN (se abre en una pestaña nueva)
Referrer-PolicyLimita qué parte de tus URL se envía a otros sitiosstrict-origin-when-cross-originOWASP
X-XSS-ProtectionEncabezado del filtro XSS del navegador; OWASP dice que puede crear vulnerabilidades XSS en sitios que de otro modo serían segurosNo lo configures, o usa 0OWASP

Revisa qué envía tu tienda:

curl -sI https://example.com/

Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Security-Policy: frame-ancestors 'self'
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin

Dos advertencias. includeSubDomains bloquea cualquier subdominio que solo funcione por HTTP, así que revisa primero tus subdominios. La precarga de HSTS requiere un max-age de al menos 31536000 e includeSubDomains, así que agrega preload solo cuando todos los subdominios estén listos para HTTPS. Vale la pena tener una CSP completa que restrinja los scripts, pero OWASP señala que es compleja de configurar y de mantener, y las tiendas con muchas apps deben probarla con cuidado.

¿Tus cookies tienen los atributos Secure, HttpOnly y SameSite?

Las cookies de sesión y de carrito deben llevar los tres atributos, y puedes verlos en los encabezados de respuesta Set-Cookie.

AtributoEfecto (según MDN (se abre en una pestaña nueva))Dónde importa
SecureSolo se envía por HTTPS; los sitios en HTTP sin cifrar no pueden establecerloTodas las cookies de una tienda con HTTPS
HttpOnlyJavaScript no puede leerla mediante document.cookie, lo que ayuda contra XSSSesiones de usuario y carritos
SameSite=Lax o StrictLimita cuándo se envía la cookie en solicitudes entre sitiosSesiones; Strict es adecuado para las cookies de autenticación y de carrito
SameSite=NoneSe envía en solicitudes entre sitios; debe combinarse con SecureSolo funciones incrustadas de terceros que lo necesiten

Si no se establece ningún atributo SameSite, los navegadores tratan la cookie como Lax. Las cookies que tus propios scripts necesitan leer no pueden ser HttpOnly, así que concéntrate en las que identifican a un cliente con sesión iniciada o a un administrador.

curl -sI https://example.com/ | grep -i "^set-cookie"

Las herramientas para desarrolladores del navegador muestran la misma información, incluidas las cookies que los scripts establecen después de que se carga la página.

¿Cómo encontrar contenido mixto?

El contenido mixto es cualquier recurso cargado por HTTP en una página servida por HTTPS, y la consola del navegador lo muestra.

MDN (se abre en una pestaña nueva) lo divide en dos grupos. Las imágenes, el audio y el video son “actualizables” (upgradable): los navegadores los solicitan automáticamente por HTTPS. Los scripts, las hojas de estilo, los iframes, las fuentes y las solicitudes fetch() son “bloqueables” (blockable): los navegadores los bloquean, lo que rompe todo lo que dependía de ellos. Las solicitudes actualizadas que apuntan directamente a una dirección IP también se bloquean.

Para encontrarlo, abre la consola en tus plantillas clave (inicio, colección, producto, carrito) y busca http:// en el código de tu tema, el contenido de las páginas y la configuración de las apps. El centro de ayuda de Shopify indica que cualquier página de la tienda con un recurso que no se entregue por HTTPS se considera insegura (se abre en una pestaña nueva), y recomienda alojar los recursos en Shopify o servirlos por HTTPS. En WooCommerce, revisa el contenido de entradas antiguas y las opciones del tema si el sitio alguna vez funcionó con http://.

¿Cómo detectar bibliotecas de JavaScript desactualizadas con CVE conocidas?

Haz una lista de las bibliotecas que carga cada página, revisa sus versiones y compáralas con la National Vulnerability Database (NVD).

Empieza por jQuery. En la consola del navegador, $.fn.jquery devuelve la versión cargada (API de jQuery (se abre en una pestaña nueva)). Versiones que debes marcar:

CVEVersiones afectadasProblemaPuntuación NVD (v3.1)
CVE-2020-11022 (se abre en una pestaña nueva)De 1.12.0 hasta antes de 3.5.0Pasar HTML no confiable a métodos como .html() o .append() puede ejecutar código6.1, media
CVE-2020-11023 (se abre en una pestaña nueva)De 1.0.3 hasta antes de 3.5.0Lo mismo, con HTML que contiene elementos <option>; en el catálogo KEV de CISA desde el 23 de enero de 20256.1, media
CVE-2019-11358 (se abre en una pestaña nueva)Anteriores a 3.4.0Contaminación de prototipos (prototype pollution) mediante jQuery.extend(true, ...)6.1, media

Ambos problemas de 2020 están corregidos en jQuery 3.5.0. Una versión vulnerable significa que el código defectuoso está presente; que se pueda explotar depende de cómo el sitio le pasa los datos. WordPress incluye jQuery 3.5.1 desde la versión 5.6 (se abre en una pestaña nueva), así que un jQuery antiguo en una tienda WooCommerce indica un WordPress desactualizado o un tema o plugin que carga su propia copia. En Shopify, revisa los archivos de tu tema y las apps que insertan scripts.

¿Qué es security.txt y tu tienda necesita uno?

Es un archivo de texto plano que les indica a los investigadores de seguridad cómo reportarte una vulnerabilidad.

El RFC 9116 (se abre en una pestaña nueva) (abril de 2022, un RFC informativo, así que seguirlo es voluntario) establece que el archivo debe servirse por HTTPS en /.well-known/security.txt como text/plain. Contact y Expires son obligatorios, y el RFC recomienda que la fecha de Expires esté a menos de un año.

Contact: mailto:security@example.com
Expires: 2027-09-30T23:00:00.000Z
Preferred-Languages: en
Policy: https://example.com/security-policy

En WooCommerce puedes colocar el archivo en tu servidor. En una plataforma alojada, revisa si puedes publicar un archivo en esa ruta; si no, un contacto de seguridad claramente identificado en tu página de contacto también ayuda.

¿Cómo protege DMARC a tu tienda de la suplantación de correo?

DMARC te permite pedir a los proveedores de correo que pongan en cuarentena o rechacen los mensajes que usan tu dominio en la dirección del remitente (From) sin pasar SPF o DKIM alineados.

Un registro con p=none solo recopila informes; no detiene el correo suplantado. Los clientes esperan confirmaciones de pedido y restablecimientos de contraseña desde tu dominio, así que vale la pena bloquear un mensaje de phishing que muestre exactamente tu dominio. Revisa tu política con dig +short TXT _dmarc.example.com y consulta el RFC 9989 (se abre en una pestaña nueva) para ver la especificación. DMARC no cubre los dominios parecidos, solo el dominio que publica el registro.

¿Qué administra Shopify y qué controlas tú en WooCommerce?

Shopify opera los servidores de sus tiendas, mientras que una tienda WooCommerce autoalojada deja la configuración del servidor en tus manos y en las de tu proveedor de hosting.

RevisiónShopifyWooCommerce (autoalojado)
Certificado TLSGratis para todos los dominios agregados a Shopify (se abre en una pestaña nueva); puede tardar hasta 48 horas en dominios de tercerosTu proveedor de hosting o tu propia configuración
Redirección de HTTP a HTTPSPlataformaConfiguración del servidor web, de la CDN o del hosting
Encabezados de seguridadLos envían los servidores de ShopifyServidor web, CDN o un plugin
Atributos de cookiesLas cookies propias de Shopify las define la plataforma; las cookies de las apps y del tema son tu responsabilidadNúcleo de WordPress, plugins y servidor
Contenido mixto y bibliotecas JSTu tema, tu contenido y tus appsTu tema, tu contenido y tus plugins
security.txt y DMARCTu dominio y tu DNSTu dominio y tu DNS

Cuando revisamos varias tiendas alojadas en Shopify en octubre de 2026, sus respuestas incluían HSTS con un max-age de unos 91 días, X-Content-Type-Options: nosniff y una CSP con upgrade-insecure-requests, mientras que frame-ancestors variaba de una tienda a otra. Shopify afirma que cuenta con la certificación PCI DSS de nivel 1 (se abre en una pestaña nueva). Tu tema y las apps que instales siguen siendo tu responsabilidad.

En WooCommerce, la guía de protección (hardening) (se abre en una pestaña nueva) de WordPress recomienda mantener WordPress y los plugins actualizados, eliminar los plugins que no usas y preguntarle a tu proveedor de hosting qué medidas de seguridad toma.

¿Por qué esto no es una prueba de penetración?

Una prueba de penetración intenta ataques de forma activa; las revisiones pasivas solo observan.

NIST SP 800-115 define la prueba de penetración como una prueba de seguridad en la que los evaluadores imitan ataques reales para encontrar formas de eludir las funciones de seguridad de un sistema (glosario del NIST (se abre en una pestaña nueva)). Las revisiones pasivas no pueden ver fallas del lado del servidor en los plugins, contraseñas de administrador débiles o reutilizadas, la falta de autenticación de dos factores, controles de acceso defectuosos ni código vulnerable que nunca aparece en el código fuente de la página. Úsalas como una base que puedes repetir en cualquier momento. Para un nivel de garantía mayor, contrata una prueba de penetración con un alcance por escrito, en sistemas que sean tuyos o que tengas autorización para probar.

Un análisis gratuito hace una primera revisión de tu tienda. El Informe de Seguridad Web cubre las revisiones pasivas de este artículo, desde TLS y redirecciones hasta encabezados, cookies, contenido mixto, bibliotecas desactualizadas, security.txt y DMARC, con correcciones para cada hallazgo. Como cualquier revisión pasiva, no puede garantizar que una tienda sea segura.

Preguntas frecuentes

¿Las revisiones de seguridad pasivas ponen en riesgo mi tienda?

No más que una visita normal. Solicitan las mismas páginas públicas y los mismos registros DNS que pediría cualquier navegador o servidor de correo, y no intentan iniciar sesión ni enviar cargas de ataque.

¿Puedo agregar encabezados de seguridad en Shopify?

Los encabezados de respuesta de la tienda provienen de los servidores de Shopify, así que contacta al soporte de Shopify si falta alguno que necesitas. Una etiqueta <meta> de CSP en tu tema puede agregar algunas directivas, pero MDN señala que frame-ancestors no es compatible con <meta>.

¿Una versión antigua de jQuery significa que hackearon mi tienda?

No. Significa que se carga código con vulnerabilidades conocidas, lo que aumenta el riesgo si el sitio pasa HTML no confiable a los métodos afectados. Actualízalo o elimina el tema o el plugin que lo carga.

¿Cuánto tiempo puede ser válido hoy un certificado TLS?

Los certificados de confianza pública emitidos desde el 15 de marzo de 2026 pueden tener una validez máxima de 200 días. El límite baja a 100 días a partir del 15 de marzo de 2027 y a 47 días a partir del 15 de marzo de 2029.

¿Es obligatorio tener un archivo security.txt?

El RFC 9116 es un RFC informativo, así que publicar el archivo es voluntario según el estándar. Publicarlo cuesta poco y les da a los investigadores una forma clara de contactarte.

¿Un análisis pasivo sin hallazgos significa que mi tienda es segura?

No. Muestra que la configuración pública se ve bien. Las vulnerabilidades del lado del servidor, la seguridad de las cuentas y las fallas en la lógica de negocio requieren otro tipo de pruebas.

Fuentes

Todas las guías