Esta guía resume qué puede fallar al añadir cabeceras de seguridad HTTP en .htaccess (estilos que no cargan, pasarelas de pago bloqueadas, desindexación...) y cómo prevenirlo. Léela antes de configurar las cabeceras.
Requisitos previos
Una copia del .htaccess y, si puedes, un entorno de pruebas.
Instrucciones paso a paso
Antes de aplicar cabeceras
Haz una copia del .htaccess.
Pruébalas en un entorno de pruebas (staging) antes de producción.
Revisa los requisitos de tu pasarela de pago (Stripe, PayPal, Redsys...).
Comprueba el resultado con Security Headers y CSP Evaluator.
Problemas habituales
Síntoma | Causa y solución |
No cargan CSS o JS | CSP demasiado restrictiva: incluye 'self' y los dominios necesarios en script-src y style-src. |
No cargan las fuentes | Falta el dominio en font-src (por ejemplo Google Fonts). |
Imágenes rotas | CORS mal configurado. |
Fallan Maps, login social o chats | CSP o Permissions-Policy bloquean connect-src o las APIs externas. |
Google deja de indexar | X-Robots-Tag: noindex puesto por error. |
Conflictos de caché | Cache-Control choca con plugins como WP Rocket o W3 Total Cache. |
Pasarelas de pago
Cabecera | Configuración segura |
Content-Security-Policy | Permite el dominio de la pasarela en script-src y frame-src (ej.: https://js.stripe.com). |
Referrer-Policy | strict-origin-when-cross-origin (no uses no-referrer). |
X-Frame-Options | SAMEORIGIN (no DENY si la pasarela usa iframe). |
De esta forma aplicas cabeceras de seguridad sin romper tu web ni tu pasarela de pago. Ejemplo compatible con Stripe:
Header always set Content-Security-Policy "default-src 'self'; script-src 'self' https://js.stripe.com; frame-src 'self' https://js.stripe.com"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set X-Frame-Options "SAMEORIGIN"
Si algo ha dejado de funcionar: Restaura la copia del .htaccess y añade las cabeceras de una en una.
Ahora ya conoces los riesgos de las cabeceras de seguridad y cómo evitarlos.