Un sitio puede utilizar HTTPS y seguir estando insuficientemente protegido en el navegador. Entre el servidor y la pantalla del usuario, las cabeceras HTTP transmiten instrucciones que limitan ciertos comportamientos de riesgo: carga de scripts externos, integración del sitio en un iframe, interpretación incorrecta de un archivo o acceso a funciones sensibles del navegador. Estas protecciones son discretas, pero deben formar parte de la auditoría técnica de un sitio WordPress, una aplicación PHP o un CRM empresarial a medida.

¿Para qué sirven las cabeceras de seguridad HTTP?

Una cabecera de respuesta es una información que el servidor envía junto con la página. Algunas cabeceras indican al navegador qué debe permitir o rechazar. Pueden reducir el impacto de ataques como la inyección de scripts, el secuestro de clics o la explotación de un contenido cuyo tipo se ha declarado de forma incorrecta. OWASP las presenta como un refuerzo útil de la seguridad, no como un sustituto de un código correctamente desarrollado, actualizado y revisado.

Las protecciones más útiles que conviene revisar

  • Content-Security-Policy (CSP) define las fuentes autorizadas para scripts, estilos, imágenes, tipografías y otros recursos. Una política bien diseñada limita especialmente la explotación de determinadas vulnerabilidades XSS. Sin embargo, debe adaptarse al sitio.
  • Strict-Transport-Security (HSTS) pide al navegador que vuelva automáticamente mediante HTTPS en las visitas posteriores. Solo debe enviarse a través de HTTPS. La opción includeSubDomains debe activarse únicamente cuando todos los subdominios afectados puedan funcionar de forma permanente con HTTPS.
  • X-Content-Type-Options: nosniff impide que el navegador deduzca un tipo de contenido distinto del declarado por el servidor. Esto reduce ciertos escenarios en los que un archivo puede interpretarse como código ejecutable.
  • frame-ancestors, dentro de la CSP, controla qué sitios pueden integrar una página. X-Frame-Options sigue siendo útil para mantener la compatibilidad con algunos navegadores antiguos, mientras que frame-ancestors ofrece un control más moderno.
  • Referrer-Policy limita la información de origen transmitida cuando un visitante sigue un enlace. Permissions-Policy puede desactivar o restringir funciones como la cámara, el micrófono o la geolocalización cuando no son necesarias.

Por qué copiar una configuración preparada puede romper el sitio

Una CSP demasiado estricta puede bloquear una herramienta de analítica, un mapa, un vídeo, un pago online, un captcha o un script añadido por WordPress. En cambio, una política llena de excepciones como unsafe-inline pierde parte de su utilidad. El método correcto consiste en inventariar los recursos que realmente utiliza el sitio y probar primero la política con Content-Security-Policy-Report-Only. Este modo informa de las infracciones sin bloquear inmediatamente los elementos afectados.

HSTS también exige precaución. Una duración larga, includeSubDomains o la inscripción en una lista de precarga pueden dejar inaccesible un subdominio si su certificado o su configuración HTTPS no están preparados. Conviene empezar con una duración limitada, revisar todo el dominio y reforzar después la regla de forma progresiva.

Cómo realizar una comprobación práctica

La primera comprobación puede hacerse desde la pestaña Red de las herramientas de desarrollo del navegador o mediante un comando que muestre las cabeceras HTTP. Hay que probar la página de inicio, la administración, los formularios, el área de clientes y, cuando exista, el proceso de pago.

  • Anotar las cabeceras presentes y detectar duplicados o contradicciones.
  • Inventariar los dominios externos que carga el sitio.
  • Preparar las reglas en un entorno de preproducción o en modo informe.
  • Probar formularios, estadísticas, mapas, vídeos, accesos y pagos.
  • Desplegar de forma progresiva y vigilar los errores después de la publicación.

En WordPress, una extensión puede añadir determinadas cabeceras, pero una configuración en el servidor, el proxy inverso o el CDN suele ser más coherente. Lo importante es evitar que varias capas envíen reglas diferentes. En una aplicación PHP a medida, las cabeceras deben integrarse en una configuración común para cubrir todas las respuestas, incluidas las páginas de error.

Un pequeño ajuste que requiere un método real

Las cabeceras de seguridad no hacen que un sitio sea invulnerable. Añaden una defensa útil alrededor del código, las actualizaciones, las copias de seguridad, el control de accesos y la supervisión. Para una pyme o un profesional de Niza, Cannes o Mónaco, el objetivo no es acumular reglas técnicas, sino proteger los recorridos importantes: solicitudes de contacto, reservas, pagos, acceso de clientes y herramientas internas.

Puntos que deben verificarse antes de publicar

Revisar las recomendaciones de OWASP y MDN en el momento de la publicación, comprobar la compatibilidad actual de Permissions-Policy y CSP, confirmar que todos los subdominios admiten HTTPS antes de activar HSTS con includeSubDomains o preload, y adaptar cada regla a los servicios externos que utiliza realmente el sitio.