Cabeceras de seguridad que todo sitio web debe enviar

Security2026-09-19TryQuickToolBox

Has asegurado tu servidor, parcheado tu framework y capacitado a tu equipo en codificación segura. Sin embargo, tu sitio sigue siendo vulnerable si no envía las cabeceras HTTP de seguridad correctas. Estas cabeceras de respuesta indican a los navegadores cómo comportarse al manejar tu contenido, y las cabeceras ausentes o mal configuradas dejan la puerta abierta a cross-site scripting (XSS), clickjacking, ataques de degradación de protocolo y fugas de datos.

En esta guía, cubriremos las cabeceras de seguridad esenciales que todo sitio web debe enviar, explicaremos qué hace cada una y te mostraremos cómo configurarlas correctamente.

Por qué importan las cabeceras de seguridad

Las cabeceras de seguridad son una primera línea de defensa porque aplican políticas a nivel de navegador que tú controlas. No reemplazan la validación de entrada ni la autenticación segura, pero reducen significativamente la superficie de ataque. Por ejemplo, una Content-Security-Policy estricta puede impedir que un script inyectado se ejecute, incluso si un atacante encuentra una vulnerabilidad XSS.

Los principales navegadores admiten estas cabeceras de forma consistente, y añadirlas suele ser cuestión de unas pocas líneas de configuración. Hay pocas razones para no usarlas.

Las cabeceras de seguridad esenciales

A continuación están las cabeceras que todo sitio web en producción debería enviar. Cubriremos qué hacen, los valores recomendados y los errores comunes.

1. Content-Security-Policy (CSP)

CSP es la cabecera más potente para mitigar XSS e inyección de datos. Restringe las fuentes desde las que el navegador puede cargar scripts, estilos, imágenes y otros recursos. Una política inicial adecuada podría verse así:

Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https://images.example.com; object-src 'none'; base-uri 'self'; form-action 'self';

Comienza con default-src 'self' y añade excepciones gradualmente según sea necesario. Evita 'unsafe-inline' para scripts si es posible; usa nonces o hashes en su lugar. Prueba a fondo porque una CSP mal configurada puede romper tu sitio.

2. HTTP Strict Transport Security (HSTS)

HSTS obliga a los navegadores a usar HTTPS para todas las solicitudes futuras a tu dominio. Previene ataques de degradación de protocolo y secuestro de cookies. Una cabecera típica:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

El max-age está en segundos (un año). includeSubDomains aplica la política a todos los subdominios. preload permite que tu dominio se añada a las listas de precarga del navegador, pero solo úsalo si estás absolutamente seguro de que todos los subdominios admiten HTTPS.

3. X-Frame-Options

Esta cabecera impide que tu sitio se incruste en un iframe, lo que detiene los ataques de clickjacking. Usa:

X-Frame-Options: DENY

O SAMEORIGIN si necesitas enmarcar tu propio contenido. Los navegadores modernos también admiten la directiva frame-ancestors en CSP, que es más flexible. Si usas CSP, puedes omitir X-Frame-Options, pero incluir ambas proporciona mejor compatibilidad.

4. X-Content-Type-Options

Esta cabecera evita que los navegadores hagan MIME-sniffing de una respuesta alejándose del Content-Type declarado. Es simple y efectiva:

X-Content-Type-Options: nosniff

Sin ella, un archivo malicioso podría interpretarse como script ejecutable. Configúrala siempre.

5. Referrer-Policy

Referrer-Policy controla cuánta información de referrer se envía con las solicitudes. Un valor predeterminado equilibrado:

Referrer-Policy: strict-origin-when-cross-origin

Esto envía la URL completa para solicitudes del mismo origen y solo el origen para solicitudes de origen cruzado. Reduce la fuga de información de rutas sensibles mientras preserva la analítica.

6. Permissions-Policy

Anteriormente Feature-Policy, esta cabecera te permite habilitar o deshabilitar funciones del navegador como geolocalización, cámara y micrófono. Ejemplo:

Permissions-Policy: geolocation=(), camera=(), microphone=()

Deshabilitar funciones no utilizadas reduce el impacto de scripts de terceros comprometidos.

Comparación de cabeceras de seguridad

CabeceraPropósitoValor recomendado
Content-Security-PolicyMitigar XSS e inyección de datosdefault-src 'self'; script-src 'self' ...
Strict-Transport-SecurityAplicar HTTPSmax-age=31536000; includeSubDomains
X-Frame-OptionsPrevenir clickjackingDENY o SAMEORIGIN
X-Content-Type-OptionsDetener MIME sniffingnosniff
Referrer-PolicyControlar fuga de referrerstrict-origin-when-cross-origin
Permissions-PolicyRestringir funciones del navegadorgeolocation=(), camera=()

Cómo añadir cabeceras de seguridad

El método depende de tu servidor web o framework. Aquí tienes enfoques comunes.

Nginx

Añade cabeceras en tu bloque de servidor:

add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://trusted.cdn.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https://images.example.com; object-src 'none'; base-uri 'self'; form-action 'self';" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Frame-Options "DENY" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "geolocation=(), camera=(), microphone=()" always;

El parámetro always garantiza que las cabeceras se envíen incluso en respuestas de error.

Apache

Habilita mod_headers y añade:

Header always set Content-Security-Policy "default-src 'self'; script-src 'self' https://trusted.cdn.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https://images.example.com; object-src 'none'; base-uri 'self'; form-action 'self';"
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
Header always set X-Frame-Options "DENY"
Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "geolocation=(), camera=(), microphone=()"

Node.js (Express)

Usa el middleware helmet, que establece muchas cabeceras por defecto:

const helmet = require('helmet');
app.use(helmet());
// Personaliza CSP si es necesario
app.use(helmet.contentSecurityPolicy({
  directives: {
    defaultSrc: ["'self'"],
    scriptSrc: ["'self'", "https://trusted.cdn.com"],
    styleSrc: ["'self'", "'unsafe-inline'"],
    imgSrc: ["'self'", "data:", "https://images.example.com"],
    objectSrc: ["'none'"],
    baseUri: ["'self'"],
    formAction: ["'self'"],
  }
}));

Helmet también establece otras cabeceras como X-Content-Type-Options y Referrer-Policy por defecto.

Probar tus cabeceras

Después del despliegue, verifica tus cabeceras usando las herramientas de desarrollador del navegador (pestaña Network) o escáneres en línea como SecurityHeaders.com. Comprueba que:

Revisa y actualiza tus políticas regularmente a medida que tu sitio evoluciona.

Preguntas frecuentes

¿Cuál es la cabecera de seguridad más importante?

Content-Security-Policy suele considerarse la más importante porque mitiga directamente los ataques XSS e inyección de datos, que están entre las vulnerabilidades web más comunes.

¿Pueden las cabeceras de seguridad reemplazar otras medidas de seguridad?

No. Las cabeceras de seguridad son una capa de defensa en profundidad. Aún necesitas codificación segura, validación de entrada, autenticación y otras buenas prácticas.

¿Añadir cabeceras de seguridad romperá mi sitio web?

Si están mal configuradas, especialmente CSP, pueden bloquear recursos legítimos. Prueba siempre en un entorno de staging y monitorea la consola del navegador en busca de violaciones antes de desplegar a producción.

¿Listo para asegurar tu sitio? Empieza añadiendo las cabeceras anteriores y luego prueba con las herramientas de desarrollador de tu navegador. Para una forma rápida de inspeccionar y formatear respuestas JSON de tu escáner de seguridad, prueba nuestro JSON Formatter.