Ir al contenido principal

Riesgos configuración cabeceras de seguridad

Actualizado hace más de 2 meses

🔍 Riesgos comunes y raros al modificar encabezados en .htaccess

🔴 Problemas comunes

  1. CSS y JS dejan de cargarse

    • Si configuras mal Content-Security-Policy, podrías bloquear tus propios archivos de estilos y scripts.

    • Solución: Asegúrate de incluir 'self' y otros dominios permitidos en script-src y style-src.

  2. Fuentes personalizadas no cargan

    • Bloquear font-src en CSP puede hacer que las fuentes de Google u otros servidores no se muestren.

    • Solución: Añadir 'self' y dominios de fuentes a font-src.

  3. Imágenes rotas

    • Un CORS mal configurado puede bloquear la carga de imágenes desde servidores externos.

  4. Errores en API y conexiones a servicios externos

    • Si Permissions-Policy o CSP bloquean conexiones a APIs externas, integraciones como Google Maps o Facebook Login pueden fallar.

🛑 Riesgos raros pero posibles

  1. Desindexación de la web en Google

    • Un X-Robots-Tag: noindex mal colocado en .htaccess puede hacer que Google deje de indexar tu sitio.

  2. Problemas con WebSockets y aplicaciones en tiempo real

    • Servicios como chats en vivo o notificaciones push pueden bloquearse si los encabezados restringen connect-src.

  3. Conflictos con plugins de caché

    • Algunas configuraciones de Cache-Control en .htaccess pueden entrar en conflicto con plugins como WP Rocket o W3 Total Cache, afectando la velocidad del sitio.

  4. Errores en navegadores antiguos

    • Algunos encabezados modernos, como Permissions-Policy, pueden no ser reconocidos por navegadores más antiguos y generar problemas inesperados.

🚨 ¿Por qué podrían dejar de funcionar las pasarelas de pago?

Muchas pasarelas de pago dependen de scripts externos y redirecciones seguras. Un mal ajuste en los encabezados puede bloquear estas funciones, provocando errores en el proceso de pago.

🔴 Encabezados problemáticos para pasarelas de pago:

  1. Content-Security-Policy (CSP) mal configurado

    Si bloquea scripts o iframes de proveedores externos como Stripe, PayPal o Redsys, la pasarela no podrá cargar.

    • Ejemplo: Un CSP demasiado restrictivo que solo permite 'self' bloquearía scripts de stripe.com.

    • Solución: Incluir los dominios necesarios en script-src y frame-src.

    Header always set Content-Security-Policy "default-src 'self'; script-src 'self' https://js.stripe.com; frame-src 'self' https://js.stripe.com"

  2. Referrer-Policy muy restrictivo

    Algunas pasarelas necesitan saber de qué página viene el usuario para validar la transacción.

    • Si usas no-referrer, podrías bloquear esta comunicación.

    • Solución: Usa strict-origin-when-cross-origin.

    Header always set Referrer-Policy "strict-origin-when-cross-origin"

  3. X-Frame-Options con 'DENY'

    • Si la pasarela de pago se carga en un iframe, este encabezado podría bloquearlo.

    • Solución: Usa SAMEORIGIN o permite el dominio de la pasarela.

    Header always set X-Frame-Options "SAMEORIGIN"

🔧 Cómo evitar problemas

✔ Haz una copia de seguridad antes de modificar .htaccess.
✔ Prueba en un entorno de prueba antes de aplicar cambios en producción.
✔ Usa herramientas como Security Headers y CSP Evaluator para verificar tu configuración.
✔ Revisa si tu pasarela de pago tiene requisitos específicos sobre encabezados HTTP.

Artículos relacionados
Configurar encabezados de seguridad en WordPress
Content-Security-Policy (CSP)
¿Ha quedado contestada tu pregunta?