SeenSecure Help
EspañolEnglishDeutschFrançais

Headers de Seguridad HTTP

Los headers HTTP son instrucciones que tu sitio envía al navegador para protegerse contra clickjacking, XSS, robo de datos y más. Configúralos desde el panel de SeenSecure.

🛡️ X-Frame-Options — Protección contra Clickjacking

🎯 ¿Qué hace?

Controla si tu sitio puede ser mostrado dentro de un <iframe> en otro sitio web. Impide que páginas externas incrusten tu contenido sin permiso.

⚠️ ¿Por qué importa?

Sin esta protección, un atacante puede cargar tu sitio en un iframe transparente y engañar a los usuarios para que hagan clics sin saberlo (clickjacking). Esto puede exponer credenciales, autorizar pagos o modificar configuraciones.

⚙️ Opciones de configuración

  • DENY (recomendado): Bloquea cualquier intento de mostrar tu sitio en un iframe, sin excepciones.
  • SAMEORIGIN: Solo permite iframes del mismo dominio. Útil si usas iframes legítimos propios.
🎯 Ejemplo real: un atacante crea una página que imita un sorteo o encuesta inofensiva, y coloca tu panel de administración de WordPress (wp-admin) dentro de un <iframe> transparente, superpuesto exactamente sobre el botón "Participar". La víctima —que tiene sesión iniciada como administrador en otra pestaña— cree que hace clic en "Participar", pero en realidad el clic cae sobre el botón real de wp-admin oculto debajo, como "Eliminar usuario" o "Instalar plugin". Sin X-Frame-Options, el navegador permite que tu web se cargue dentro de ese iframe ajeno. Con X-Frame-Options: DENY, el navegador se niega directamente a mostrar tu sitio dentro de cualquier iframe externo, y la página del atacante muestra un hueco en blanco donde debería estar el señuelo.
✅ Recomendación: Usa DENY a menos que tengas una razón específica para necesitar iframes propios, en cuyo caso usa SAMEORIGIN.

📝 X-Content-Type-Options — Prevención de MIME Sniffing

🎯 ¿Qué hace?

Le dice al navegador que NO adivine el tipo de archivo (MIME sniffing). Obliga a respetar exactamente el tipo declarado en la cabecera Content-Type.

⚠️ ¿Por qué importa?

Sin este header, un navegador puede interpretar un archivo de texto como JavaScript y ejecutarlo. Esto permite a atacantes subir un archivo con extensión .txt pero con código malicioso que el navegador ejecutará.

⚙️ Configuración

El único valor válido es nosniff. Se recomienda activarlo siempre. No tiene efectos secundarios negativos.

🎯 Ejemplo real: un formulario de subida de archivos mal validado (en un plugin de terceros, por ejemplo) permite a un atacante subir un archivo llamado imagen.jpg que en realidad contiene código JavaScript disfrazado de imagen. Si el navegador de un visitante intenta "adivinar" el tipo de contenido en vez de confiar en la cabecera que declara el servidor, puede llegar a interpretar ese archivo como un script y ejecutarlo en el contexto de tu web, en vez de mostrarlo como una imagen inofensiva. Con X-Content-Type-Options: nosniff, el navegador se limita estrictamente al tipo que el servidor declaró (imagen), y se niega a ejecutarlo como código aunque su contenido interno sugiera otra cosa.
✅ MUY RECOMENDADA: Actívalo sin dudar. Es uno de los headers más seguros y con menos impacto. No rompe nada y protege contra una vulnerabilidad común.

🔒 X-XSS-Protection — Por Qué Ya No Lo Enviamos

🎯 ¿Qué era?

Un header que activaba un filtro anti-XSS incorporado en navegadores antiguos (Internet Explorer, versiones viejas de Chrome y Safari), pensado para detectar y bloquear intentos de inyección de scripts reflejados.

⚠️ Por qué lo hemos quitado

Chrome lo eliminó por completo en 2019 —no que dejara de tener efecto, sino que Google lo consideró más un riesgo que una ayuda, porque el propio filtro tenía fallos de seguridad documentados y era bastante fácil saltárselo. Firefox nunca llegó a implementarlo. Microsoft dejó de dar soporte a Internet Explorer en 2022. Mantener un header que ya no protege nada real, y que en su día pudo introducir sus propios problemas, no tenía sentido.

✅ ¿Se pierde protección al quitarlo? No. En Internet Explorer, el único navegador donde este header llegó a importar, el filtro venía activado por defecto incluso sin que el sitio enviara ningún header — la cabecera solo servía para que un sitio pudiera cambiar ese comportamiento (forzar bloqueo total, o desactivarlo si causaba falsos positivos). Al no enviar el header, IE simplemente sigue con su comportamiento de fábrica: no se apaga nada que antes estuviera encendido.
🎯 La protección real, hoy: el ataque que este filtro intentaba parar (XSS reflejado: una URL manipulada que hace que un buscador o campo mal escapado devuelva código ejecutable al navegador de quien pulsa un enlace preparado) hoy lo cubren dos capas que funcionan igual en cualquier navegador, viejo o nuevo: el WAF del firewall, que bloquea el patrón de inyección a nivel de petición antes de que el HTML llegue al navegador, y la Content-Security-Policy, que impide que el navegador ejecute scripts no autorizados aunque el código malicioso ya esté insertado en la página. Ninguna de las dos depende de que el navegador tenga un filtro heurístico propio.

🔗 Referrer-Policy — Control de Fuga de Información Referer

🎯 ¿Qué hace?

Controla cuánta información de la URL de origen se envía en la cabecera Referer cuando los usuarios hacen clic en un enlace o cargan un recurso externo.

⚠️ ¿Por qué importa?

Sin control, la URL completa (incluyendo parámetros como tokens, IDs de sesión o datos personales) puede filtrarse a sitios externos. Esto viola la privacidad del usuario y puede exponer datos sensibles.

⚙️ Opciones de configuración

  • no-referrer: No envía nunca el Referer. Máxima privacidad, pero puede romper analytics.
  • same-origin: Solo envía Referer dentro del mismo dominio. No envía a sitios externos.
  • strict-origin: Envía solo el origen (dominio), nunca la URL completa. Solo en conexiones HTTPS a HTTPS.
  • strict-origin-when-cross-origin (recomendada): Envía URL completa dentro del mismo dominio, y solo el origen a sitios externos. El mejor balance entre funcionalidad y privacidad.
🎯 Ejemplo real: un usuario ha iniciado sesión y navega a una página con una URL que incluye un token sensible como parámetro (por ejemplo, un enlace de restablecimiento de contraseña recién generado). Si esa página incluye un recurso cargado desde un dominio externo —una fuente tipográfica, un banner publicitario, un widget de terceros—, el navegador podría enviar esa URL completa, token incluido, como cabecera Referer al servidor externo, sin que el usuario ni el propietario del sitio externo lo pidan expresamente. Con Referrer-Policy: strict-origin-when-cross-origin, el navegador solo comparte el dominio de origen con sitios externos, nunca la ruta completa con el token, y los enlaces dentro de tu propio dominio siguen funcionando con normalidad.
💡 Recomendación: Usa strict-origin-when-cross-origin. Es el valor por defecto en navegadores modernos y ofrece el mejor equilibrio entre funcionalidad y privacidad.

🔐 HSTS — Forzar Conexión HTTPS

🎯 ¿Qué hace?

Obliga a los navegadores a conectar exclusivamente mediante HTTPS, incluso si el usuario escribe http:// o hace clic en un enlace HTTP. El navegador lo recuerda según el max-age configurado.

⚠️ ¿Por qué importa?

Sin HSTS, un atacante en la misma red (Wi-Fi público, por ejemplo) puede interceptar la primera conexión HTTP y redirigir al usuario a un sitio falso (ataque man-in-the-middle). HSTS elimina esta ventana de vulnerabilidad.

⚙️ Configuración: max-age

  • max-age=0: Desactiva HSTS. Fuerza a los navegadores a olvidar la política.
  • max-age=3600 (1 hora): Para pruebas. Bajo riesgo, los navegadores lo olvidan rápido.
  • max-age=63072000 (2 años, recomendado): Para producción. Los navegadores recordarán forzar HTTPS por 2 años.
🎯 Ejemplo real: un cliente se conecta al wifi gratuito de una cafetería y escribe de memoria tu dominio en la barra de direcciones, sin el https:// delante. El navegador intenta primero la conexión insegura por HTTP. Un atacante en esa misma red wifi puede interceptar esa primera petición HTTP y devolver una copia falsificada de tu web para robar credenciales, antes de que se complete la redirección normal a HTTPS (esto se conoce como ataque de intermediario o "man-in-the-middle"). Con HSTS activo y habiendo visitado el sitio una vez antes por HTTPS, el navegador ni siquiera intenta la conexión insegura: fuerza HTTPS directamente en local, en el propio dispositivo, sin darle al atacante esa ventana de intercepción.
🚨 ADVERTENCIA CRÍTICA: Si activas HSTS con un max-age alto y luego desactivas HTTPS en tu servidor, los navegadores bloquearán el acceso a tu sitio hasta que expire el max-age. No hay forma de revocarlo antes. Usa un valor bajo primero para pruebas.

🎯 Content-Security-Policy (CSP) — La Policía del Contenido

🎯 ¿Qué hace?

Define exactamente qué fuentes están autorizadas para cargar scripts, estilos, imágenes, fuentes y otros recursos en tu sitio. Cualquier recurso no autorizado es bloqueado automáticamente por el navegador.

⚠️ ¿Por qué importa?

CSP es la defensa más potente contra XSS. Incluso si un atacante logra inyectar un script malicioso, CSP lo bloquea porque el script no proviene de una fuente autorizada. Es tu última línea de defensa.

🎯 Ejemplo real: un comentario o campo de formulario mal filtrado permite a un atacante inyectar una etiqueta <script> que carga código desde un dominio ajeno en una página de tu web (un fallo típico cuando un plugin no escapa correctamente la entrada del usuario). Sin CSP, el navegador de cualquier visitante que cargue esa página ejecutaría ese script sin preguntar, y el código podría robar cookies de sesión, redirigir a una web de phishing o capturar pulsaciones de teclado. Con una CSP que restringe script-src a tu propio dominio (y a las fuentes concretas que hayas autorizado explícitamente), el navegador detecta que ese dominio externo no está en la lista permitida y se niega a cargar y ejecutar el script, aunque el código malicioso ya esté insertado en el HTML de la página.

⚙️ Configuración

CSP usa un editor de texto libre donde escribes la política directamente. No hay botones de plantilla de un clic.

🚨 El valor por defecto NO es una política completa — es solo una línea mínima: la primera vez que activas CSP, el campo de texto viene relleno únicamente con default-src 'self';. Esa única directiva se aplica como reserva a TODOS los tipos de recurso que no tengan su propia directiva explícita (scripts, estilos, imágenes, fuentes...), y como no incluye 'unsafe-inline' ni ningún dominio externo, bloqueará los estilos y scripts en línea que casi cualquier tema o plugin de WordPress escribe directamente en el HTML, además de cualquier recurso cargado desde un CDN externo (Google Fonts, jQuery, YouTube, etc.). No actives el interruptor CSP con este valor sin editarlo antes: prácticamente romperá la apariencia y funcionalidad de un WordPress real.
💡 Qué hacer en su lugar: antes de activar el interruptor de CSP, abre tu sitio con la consola del navegador (F12) y añade manualmente al campo de texto los dominios que tu tema, plugins y scripts de terceros necesitan (Google Fonts, YouTube, tu proveedor de analíticas, etc.), siguiendo la sintaxis de directivas explicada más abajo. Empieza siempre con el firewall en modo Monitoring para poder revisar los errores en consola sin arriesgarte a dejar tu sitio inutilizable en producción.
¿Por qué no hay una plantilla "seguro para WordPress" de un clic? Se probó a fondo antes de plantearla: no existe una única política de CSP que funcione sin romper nada en los miles de combinaciones distintas de tema + plugins + servicios de terceros que corren sobre este plugin — siempre hay algún caso que necesita unsafe-inline, un dominio de CDN concreto o un permiso que otro sitio no necesita. Por eso el campo se deja en blanco (con la reserva mínima default-src 'self';) para que la construyas tú mismo según lo que tu sitio realmente carga, en vez de ofrecer un botón que invite a activarla a ciegas.
⚠️ Riesgo de CSP: Una política mal configurada puede romper tu sitio (bloquear scripts, estilos, imágenes o recursos esenciales). Prueba siempre primero con el firewall en modo Monitoring y revisando la consola del navegador. Ve añadiendo únicamente lo que tu sitio necesite de verdad, directiva por directiva.
💡 Consejo: Si después de activar CSP algo deja de funcionar, abre la consola del navegador (F12). Los errores te dirán exactamente qué recurso fue bloqueado y desde qué dominio. Simplemente añade ese dominio a las directivas correspondientes.

✍️ Cómo se escribe una política CSP (sintaxis básica)

Aunque parezca un bloque de texto intimidante, la CSP sigue una estructura muy simple, siempre igual:

directiva1 valor1 valor2 valor3; directiva2 valor1; directiva3 valor1 valor2;
  • Cada directiva termina en punto y coma (;). Es lo que separa una regla de la siguiente — si te olvidas uno, la directiva siguiente puede quedar «pegada» a la anterior y dejar de funcionar.
  • Dentro de una directiva, los valores van separados por espacios (nunca comas): script-src 'self' https://ejemplo.com https://otro.com; autoriza tres fuentes distintas para scripts.
  • Las palabras clave especiales van entre comillas simples: 'self' (tu propio dominio), 'none' (nada, prohibido del todo), 'unsafe-inline' (permite código escrito directamente en el HTML). Los dominios normales nunca llevan comillas: https://fonts.googleapis.com, no 'https://fonts.googleapis.com'.
  • Puedes autorizar un dominio completo con comodín: https://*.googleapis.com permite cualquier subdominio de googleapis.com, en vez de tener que listar cada uno.
✏️ Cómo añadir un permiso nuevo, paso a paso: localiza la directiva que corresponda (por ejemplo script-src si es un script) dentro del texto ya escrito en el campo, y añade el nuevo dominio justo antes del punto y coma de esa directiva, separado por un espacio del valor anterior. Ejemplo: si tenías script-src 'self' 'unsafe-inline'; y necesitas autorizar https://widget.ejemplo.com, lo dejas así: script-src 'self' 'unsafe-inline' https://widget.ejemplo.com;. No borres nada de lo que ya había, solo añade.

📚 Las directivas que vas a usar (cuántas hay y para qué sirve cada una)

La especificación CSP define más de 20 directivas en total, pero en un sitio WordPress normal solo vas a necesitar tocar estas 12 — son las que aparecen ya en el valor por defecto o las que más se piden al añadir un servicio nuevo:

Directiva Para qué sirve (qué controla) Cuándo la tocas
default-srcValor de reserva: se aplica a cualquier tipo de recurso que no tenga su propia directiva específica más abajo.Casi nunca — sirve de red de seguridad
script-srcDe dónde se puede cargar y ejecutar JavaScript (<script>, código en atributos onclick, etc.)Al instalar un chatbot, un pixel de tracking, un widget de reseñas...
style-srcDe dónde se pueden cargar hojas de estilo CSS y estilos escritos directamente en el HTMLAl añadir una fuente tipográfica externa (Google Fonts, Adobe Fonts...)
img-srcDe dónde se pueden cargar imágenesSi usas un CDN de imágenes, avatares externos (Gravatar), mapas embebidos...
font-srcDe dónde se pueden cargar archivos de tipografía (.woff, .ttf...)Casi siempre va de la mano de style-src para el mismo servicio de fuentes
connect-srcA qué dominios puede conectarse el JavaScript de la página (peticiones fetch, XMLHttpRequest, WebSockets)Al integrar analíticas, un chat en vivo, cualquier servicio que envíe datos en segundo plano
frame-srcQué páginas externas se pueden incrustar dentro de un <iframe> en tu webAl incrustar un vídeo de YouTube/Vimeo, un mapa de Google Maps, un formulario de otro servicio
media-srcDe dónde se pueden cargar archivos de audio y vídeo reproducidos con <audio>/<video>Si alojas podcasts o vídeo propio fuera de tu dominio (ej. en un CDN aparte)
object-srcControla <object>, <embed> y <applet> (Flash y plugins antiguos del navegador)Nunca — déjalo siempre en 'none', es tecnología obsoleta e insegura
base-uriQué URLs puede usar la página como base para resolver enlaces relativos (etiqueta <base>)Casi nunca — 'self' es correcto en el 99% de los casos
form-actionA qué URLs se puede enviar (action=) un formulario de tu webSi un formulario envía datos a un dominio externo (ej. una pasarela de pago con redirección)
frame-ancestorsQuién puede incrustar TU web dentro de un <iframe> (protección anti-clickjacking)Casi nunca — 'self' ya cubre la mayoría de casos
upgrade-insecure-requestsFuerza a que cualquier recurso pedido por HTTP se recargue automáticamente por HTTPS (no lleva valores, va sola)Déjala siempre activada si tu sitio usa HTTPS (lo normal hoy en día)

🔍 Cómo saber qué valor buscar cuando algo se rompe

Tienes tres formas de averiguar exactamente qué dominio le falta autorizar a tu CSP, de la más rápida a la más completa:

  1. Consola del navegador (F12 → pestaña «Console»): es el método más directo. Cada recurso bloqueado aparece como una línea roja que dice literalmente «Refused to load/execute... because it violates the following Content Security Policy directive: "script-src ..."» — la parte final te dice la directiva exacta, y justo antes aparece la URL completa del recurso bloqueado. Copia el dominio de esa URL y añádelo a esa directiva.
  2. Pestaña «Network» del navegador (F12 → «Network»): útil cuando quieres ver, antes incluso de activar CSP, de qué dominios depende realmente tu página. Recarga la página con esa pestaña abierta y verás cada petición con su dominio de origen — así sabes de antemano qué vas a tener que autorizar.
  3. Documentación del propio servicio externo: si instalas un chat en vivo, un formulario de pago o un widget de terceros conocido, busca en su web de ayuda «CSP» o «Content Security Policy» — la mayoría de servicios serios (Stripe, Intercom, HubSpot, etc.) publican exactamente qué dominios necesitas autorizar y en qué directiva, porque es una duda muy habitual entre sus propios clientes.
🧩 Ejemplo completo, paso a paso: instalas un widget de chat de un proveedor externo y, tras activar CSP, deja de aparecer. Abres la consola (F12) y ves: Refused to load the script 'https://widget.proveedorchat.com/loader.js' because it violates the following Content Security Policy directive: "script-src 'self' 'unsafe-inline'". Localizas script-src en el campo de texto y le añades el dominio: pasa de script-src 'self' 'unsafe-inline'; a script-src 'self' 'unsafe-inline' https://widget.proveedorchat.com;. Guardas, recargas la página con F12 abierto otra vez — si el chat carga y ya no sale ningún error nuevo relacionado, está resuelto. Si el chat, una vez cargado, también necesita conectarse a otro dominio para enviar mensajes, verás un segundo error apuntando a connect-src y repites el mismo proceso con esa directiva.

📖 Dónde consultar la referencia completa

Con las 12 directivas de la tabla de arriba resuelves prácticamente cualquier caso real en WordPress. Si algún día necesitas una directiva más específica que no está aquí (hay más de 20 en total, algunas muy poco usadas fuera de aplicaciones web complejas), la referencia oficial y más completa es la documentación de MDN Web Docs (Mozilla), que mantiene la lista entera con ejemplos y compatibilidad por navegador — busca «MDN Content-Security-Policy» en cualquier buscador. Es la misma fuente que usan los propios desarrolladores de navegadores.

🛠️ También dentro del propio plugin: en esta misma pestaña de Headers, la sección «Logging y Diagnóstico» te deja activar el registro de qué cabeceras se envían realmente y mostrarlas en un panel de diagnóstico — útil para confirmar que la política que has guardado es la que de verdad está llegando al navegador de tus visitantes, sin depender solo de mirar el código fuente.

🔌 Permissions-Policy — Control de APIs del Navegador

🎯 ¿Qué hace? (explicación sencilla)

Imagina que tu web es una casa y cada visitante entra con su móvil. Este \"permiso\" le dice al navegador: \"esta web no necesita saber dónde estás, ni verte la cara, ni escucharte\". Así, aunque alguien malicioso logre colar un script en tu web, el navegador no le prestará la cámara, el micrófono ni la ubicación.

⚠️ ¿Por qué importa? (caso real)

Piensa en esto: tienes una tienda online. Un hacker encuentra un fallo en un plugin que instalaste hace 2 años y logra inyectar un script. Ese script podría, en silencio, encender la cámara del visitante que está viendo tus productos, o sacar su ubicación exacta, o grabar con el micrófono. Sin Permissions-Policy, el navegador no le dirá que no. Con esto activado, aunque el script malicioso lo intente, el navegador responderá: \"Lo siento, esta web no tiene permiso para usar la cámara\". Y el visitante nunca se entera del intento.

🧠 Entiéndelo así: Es como si le dijeras a un empleado: \"Tú trabajas en mostrador, no necesitas las llaves de la caja fuerte\". Aunque alguien robe su identidad y entre a la tienda, no podrá abrir la caja porque ese empleado nunca tuvo acceso. Permissions-Policy hace exactamente eso: le dice al navegador \"esta web no necesita la cámara, no le des acceso aunque te lo pida\".

🧩 ¿Qué cosas bloquea exactamente?

Son funciones del teléfono o del ordenador que una web normal NO necesita para funcionar. Si tu web es un blog, una tienda o un sitio corporativo, no tienes por qué usar ninguna de estas:

📡 Ubicación

Ejemplo: Una web de repostería no necesita saber dónde vives para mostrarte un bizcocho. Riesgo: Un script espía podría rastrear a tus visitantes. Bloqueado ✅

🎥 Cámara

Ejemplo: Una web de recetas no necesita verte para enseñarte a cocinar. Riesgo: Espiar a visitantes grabándolos sin que lo sepan. Bloqueado ✅

🎤 Micrófono

Ejemplo: Un periódico digital no necesita escucharte para mostrarte noticias. Riesgo: Grabar conversaciones privadas. Bloqueado ✅

💳 Pagos / 🔔 Notificaciones

Ejemplo: La mayoría de webs usan su propio formulario de pago o plugins de terceros, no la API nativa del navegador. Riesgo: Que scripts no autorizados saquen dinero o envíen notificaciones falsas. Bloqueado ✅

🔄 Sensores / 🔗 USB

Ejemplo: Un sitio de noticias no necesita saber si estás caminando (acelerómetro) ni acceder a tus dispositivos USB. Riesgo: Saber si el usuario está quieto o en movimiento, o acceder a archivos USB sin permiso. Bloqueado ✅

✅ ¿Es seguro activarlo? Sí, totalmente. La mayoría de sitios WordPress no usan ninguna de estas funciones (cámara, micrófono, GPS...) para funcionar. Es como cerrar una puerta que ya estaba cerrada: no afecta a nada y protege si alguien intenta abrirla. Si tu web es un blog, tienda, landing page o sitio corporativo, actívalo sin miedo. Solo si tu web ofrece videollamadas o usa la ubicación del usuario deberías desactivarlo.

🔐 SRI (Subresource Integrity) — Protección de Recursos CDN

🎯 ¿Qué hace? (explicación sencilla)

Imagina que pides una pizza a domicilio. El repartidor te trae una caja sellada con un precinto de seguridad. Si el precinto está roto, sabes que alguien la abrió y no te la comes. SRI hace exactamente eso con los archivos que tu web carga desde otros servidores (Google Fonts, jQuery, Bootstrap...): pone un \"precinto digital\" en cada archivo. Si el archivo llega modificado (por un hacker, por ejemplo), el navegador detecta que el precinto está roto y lo rechaza. El usuario ni se entera, pero está protegido.

⚠️ ¿Por qué importa? (caso real)

Casi todas las webs usan recursos externos: Google Fonts para las letras bonitas, jQuery para los efectos visuales, Bootstrap para que se vea bien en móvil, Google Analytics para medir visitas... Todos estos archivos están en servidores que NO controlas. Han pasado casos reales donde hackers lograron colar código malicioso en CDNs muy conocidos. Sin SRI, si un CDN es hackeado, tu web cargaría ese virus sin que te dieras cuenta. Con SRI, el navegador dice: \"Este archivo no coincide con su huella digital, lo bloqueo\".

🔍 Caso real que pasó: En 2018, un atacante logró modificar un archivo JavaScript en un CDN usado por millones de webs (una librería llamada Event-Stream). El archivo modificado robaba criptomonedas de los visitantes. Si esas webs hubieran tenido SRI, el navegador habría detectado que el archivo ya no coincidía con su huella original y lo habría bloqueado automáticamente. Nadie habría perdido dinero.

⚙️ Cómo funciona en 3 pasos (fácil)

1️⃣ Escaneo automático

SeenSecure mira tu web y encuentra todos los archivos que cargas desde servidores externos (Google Fonts, jQuery, Bootstrap, iconos, etc.). Es como hacer un inventario de todo lo que entra en tu casa.

2️⃣ Se calcula la huella

Para cada archivo, SeenSecure genera una \"huella digital\" única (un código especial que identifica ese archivo exacto). Es como tomarle las huellas dactilares a cada recurso. Si el archivo cambia aunque sea una letra, la huella cambia por completo.

3️⃣ Protección activa

Cuando alguien visita tu web, el navegador compara la huella digital del archivo que llega con la que debería tener. Si coinciden → el archivo se ejecuta normal. Si no coinciden → el archivo es rechazado. Así de simple. El visitante ve la web correctamente y nunca sabe que hubo un intento de ataque.

📌 ¿Cada cuánto hay que reescanear? Solo cuando añadas algo nuevo: un plugin que cargue jQuery desde CDN, un tema que use Google Fonts, un icono nuevo. Es decir, casi nunca. Y cuando lo hagas, es solo un clic en el panel. El resto del tiempo, SRI trabaja solo.
✅ ¿Es seguro activarlo? Sí, totalmente. SRI no ralentiza tu web (la verificación la hace el navegador del visitante, no tu servidor). No rompe nada si los archivos son legítimos. El único caso en que bloquearía algo es si un archivo CDN ha sido modificado... que es exactamente lo que queremos. Actívalo y olvídate.

📋 Resumen y Recomendaciones

No todos los headers tienen el mismo nivel de riesgo o urgencia. Esta tabla te ayuda a priorizar:

Activar Inmediatamente

Estos headers no tienen efectos secundarios negativos y protegen contra ataques comunes:

  • ✅ X-Frame-Options: DENY — Clickjacking
  • ✅ X-Content-Type-Options: nosniff — MIME sniffing
  • ✅ Referrer-Policy: strict-origin-when-cross-origin
  • ✅ Permissions-Policy — APIs del navegador
  • ✅ SRI — Integridad de recursos CDN

Activar con Cuidado

Estos headers requieren verificación previa. Pueden bloquear el sitio si se configuran incorrectamente:

  • ⚠️ HSTS — Empieza con max-age bajo (3600). Solo sube a 2 años cuando estés 100% seguro de que HTTPS nunca se desactivará.
  • ⚠️ CSP — No lo actives con el valor de una sola línea que trae por defecto. Construye la política tú mismo primero en modo Monitoring, vigilando la consola del navegador. Si algo se bloquea, ajusta la política.
🎯 Orden recomendado de activación: 1️⃣ X-Frame-Options → 2️⃣ X-Content-Type-Options → 3️⃣ Referrer-Policy → 4️⃣ HSTS (con precaución) → 5️⃣ CSP (con precaución). Los primeros 3 son seguros y pueden activarse todos juntos.