¿Te preocupa que un tema vulnerable deje la web expuesta o que una actualización rompa el child theme y abra una puerta? El hardening de temas y child themes reduce el riesgo de takeover de plantilla, inyecciones PHP y filtrado de información crítica sin sacrificar la capacidad de mantener y actualizar el sitio.
Esta guía detalla pasos prácticos, comandos y snippets para reforzar temas y child themes en WordPress: desde permisos y bloqueo de editor, hasta protección de functions.php, reglas en servidor, CSP/SRI para assets y flujos de auditoría/rollback para entornos empresariales.
Puntos clave: Lo que debes saber en 1 minuto
- El hardening de temas protege la capa de presentación y evita que vulnerabilidades en templates o funciones permitan ejecución remota o filtrado de datos.
- Un child theme no es invulnerable: necesita su propio hardening (permisos, validación de entradas y protección de archivos críticos).
- Bloquear edición y poner permisos correctos (chmod/chown) evita cambios directos desde el panel y reduce riesgos por credenciales comprometidas.
- Auditoría automatizada + staging/CI previenen despliegues inseguros: usar WPScan, Theme Check y pruebas unitarias antes de actualizar producción.
- Proteger functions.php y enqueuing de assets mitiga inyecciones PHP y carga de recursos externos no verificados (usar CSP y SRI).
Por qué el hardening de temas y child themes importa
Los temas controlan la presentación y, frecuentemente, contienen lógica en PHP, hooks y callbacks que ejecutan en contexto de usuario. Una vulnerabilidad en un archivo de tema (por ejemplo, una función que evalúa entrada sin saneamiento) puede permitir:
- ejecución remota de código (RCE),
- subida/ejecución de archivos maliciosos,
- escalado de privilegios y takeover del sitio,
- filtrado de datos sensibles en frontend.
El child theme añade personalización: si se copia código inseguro desde el tema padre o se introducen funciones nuevas sin validación, la superficie de ataque aumenta. Además, un proceso de actualización mal diseñado puede sobrescribir o romper mecanismos de seguridad si no se gestiona correctamente.
Fuentes relevantes: WPScan (escáner reconocido) y OWASP (principios de validación/saneamiento) ofrecen buenas prácticas a seguir. Más info: WPScan, OWASP.
Checklist práctico para hardening de tu child theme
- Revisión inicial
- Verificar código del child theme: no usar eval(), preg_replace/e, create_function, o include/require dinámicos sin whitelist.
- Eliminar templates innecesarios y archivos con código sin uso.
- Control de versiones y staging
- Mantener child theme en repositorio (git) y desplegar a través de CI a staging antes de producción.
- Permisos y propiedad
- Fijar permisos: archivos 644, carpetas 755, functions.php 640 en entornos gestionados cuando sea posible.
- Bloqueo de edición
- Definir DISALLOW_FILE_EDIT y, si procede, DISALLOW_FILE_MODS en wp-config.php.
- Protección de entry points
- Añadir checks de capability en hooks administrativos y nonces en formularios personalizados.
- Enqueue seguro de assets
- Evitar cargas directas desde CDNs no confiables; usar SRI/CSP.
- Auditoría y escaneo
- Ejecutar WPScan y Theme Check en CI; configurar alertas automatizadas.
- Plan de rollback
- Mantener snapshots y scripts de rollback (wp-cli) para restablecer versión previa si una actualización falla.
Snippets esenciales (ejemplos)
- Evitar edición desde panel (wp-config.php):
// Añadir en wp-config.php
define('DISALLOW_FILE_EDIT', true);
// Opcionalmente para entornos totalmente gestionados
define('DISALLOW_FILE_MODS', true);
- Sanear entrada antes de usarla en child theme (functions.php):
if ( isset($_POST['custom']) ) {
$valor = sanitize_text_field(wp_unslash($_POST['custom']));
// Validad antes de usar
}
- Enqueue correcto en child theme (functions.php):
function child_enqueue_assets() {
wp_enqueue_style('parent-style', get_template_directory_uri() . '/style.css', array(), '1.0');
wp_enqueue_style('child-style', get_stylesheet_directory_uri() . '/style.css', array('parent-style'), '1.0');
}
add_action('wp_enqueue_scripts', 'child_enqueue_assets');
Seguridad WordPress: configuración para proteger temas y child
Desactivar la edición de archivos y limitar plugins
- Definir DISALLOW_FILE_EDIT bloquea el editor integrado (apariencia > editor). Es una medida básica y eficaz.
- DISALLOW_FILE_MODS impide instalación/actualización desde el panel; solo recomendable si se gestiona actualizaciones por CI/devops.
Cabeceras y políticas de seguridad
- HSTS, X-Content-Type-Options, X-Frame-Options y CSP deben configurarse en servidor. Ejemplo de CSP para assets de tema:
Content-Security-Policy: default-src 'self'; script-src 'self' https://cdnjs.cloudflare.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; img-src 'self' data:; font-src https://fonts.gstatic.com; object-src 'none';
- Para assets cargados desde terceros, usar Subresource Integrity (SRI):
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/normalize/8.0.1/normalize.min.css" integrity="sha384-..." crossorigin="anonymous">
Configuración de servidor para proteger /wp-content/themes
- Nginx: bloquear ejecución de PHP en /wp-content/themes y subcarpetas donde no sea necesario:
location ~* /wp-content/themes/.+/.(?:php|phtml)$ {
deny all;
}
- Apache (.htaccess) regla para impedir navegabilidad y ejecución:
<IfModule mod_rewrite.c>
RewriteRule ^wp-content/themes/(.*) - [F]
</IfModule>
<FilesMatch "/.(php|phtml)$">
Require all denied
</FilesMatch>
(Adaptar reglas si el tema necesita plantillas PHP accesibles; negar solo a carpetas específicas de subida).
Permisos de archivos y bloqueo de edición en themes
Recomendación práctica de permisos
- Propiedad de archivos: usuario del servicio web (ej: www-data en Debian/Ubuntu). Evitar dar propiedad a cuentas FTP/SSH de usuarios humanos.
- Permisos sugeridos para entornos Linux:
- Carpetas: 755
- Archivos: 644
- functions.php (archivo crítico): 640 o 644 dependiendo de la política de propiedad
Comandos ejemplo:
chown -R www-data:www-data /var/www/site/wp-content/themes/mi-child-theme
find /var/www/site/wp-content/themes/mi-child-theme -type d -exec chmod 755 {} /;
find /var/www/site/wp-content/themes/mi-child-theme -type f -exec chmod 644 {} /;
chmod 640 /var/www/site/wp-content/themes/mi-child-theme/functions.php
Si el hosting es compartido o gestionado, confirmar con el proveedor antes de cambiar permisos.
Bloqueo de edición en admin
- Como se indicó, DISALLOW_FILE_EDIT en wp-config.php. Complementar con control de roles: retirar capability 'edit_theme_options' a roles no administrativos yusar plugins de gestión de roles si procede.
Proteger functions.php y evitar inyecciones PHP
functions.php es uno de los objetivos preferidos por atacantes porque se ejecuta en todas las cargas. Medidas concretas:
- No incluir código de terceros sin revisión. Evitar copiar snippets desde foros sin entenderlos.
- Saneamiento y validación: todas las entradas (GET, POST, OPTIONS) deben sanitizarse con funciones WP (sanitize_text_field, wp_kses_post, esc_url_raw, intval, etc.).
- Evitar eval() y create_function(): estas funciones facilitan ejecución arbitraria.
- Protección por capacidad: cualquier acción que modifique archivos o opciones sensibles debe requerir current_user_can('manage_options') o capability equivalente.
Ejemplo de wrapper para prevenir cargas directas de archivos maliciosos:
// Evitar ejecución directa
if ( ! defined('ABSPATH') ) {
exit; // Exit if accessed directly
}
Además, implementar logging de cambios en archivos críticos (monitorizar checksum de functions.php) ayuda a detectar modificación no autorizada.
Auditoría, escaneo y pruebas de vulnerabilidades en themes
Herramientas recomendadas y comandos
- WPScan: escaneo de vulnerabilidades conocidas en themes y plugins.
- Comando básico:
wpscan --url https://example.com --enumerate t
- Theme Check: plugin oficial para validar estándares y seguridad de themes.
- Ejecutar en entorno de staging y revisar advertencias.
- Static analysis: PHPCS con reglas de WordPress y escáneres de PHP como RIPS o SonarQube para detectar patrones peligrosos.
- Dependencias JS/CSS: usar supply chain scanners (Snyk, npm audit) si el theme incluye packages.
Flujo recomendado (CI/CD)
- Push a rama feature del repo del theme.
- CI ejecuta linters (PHPCS), tests automatizados y WPScan.
- Despliegue a staging tras pasar checks.
- Pruebas manuales de compatibilidad visual y de hooks.
- Aprobar y desplegar a producción con snapshot y plan de rollback.
Pruebas manuales clave
- Revisar templates por funciones inseguras (eval, file_get_contents con URLs externas, include dinámico).
- Probar formularios personalizados para CSRF (nonces), XSS (filtrado de salida) e inyección SQL.
- Escanear assets cargados externamente y verificar SRI/CSP.
Análisis comparativo: protecciones básicas vs hardening profundo
| Medida |
Protección básica |
Hardening profundo |
| DISALLOW_FILE_EDIT |
Sí |
Sí + controles de rol + auditoría de cambios |
| Permisos de archivos |
644/755 |
644/755 con owner www-data y policies de CI |
| Protección de functions.php |
Saneamiento básico |
Saneamiento, nonces, logging, checksum y alertas |
| Actualizaciones |
Manuales o automáticas |
Testing en CI, staging y rollback automatizado |
Checklist visual: hardening de child theme
✅ Paso 1 → Revisar funciones peligrosas y eliminar eval()
✅ Paso 2 → Aplicar permisos 644/755 y chown www-data
✅ Paso 3 → Configurar DISALLOW_FILE_EDIT y nonces
✅ Paso 4 → Añadir CSP/SRI para recursos externos
✅ Paso 5 → Integrar WPScan/Theme Check en CI
Ventajas, riesgos y errores comunes
Beneficios / cuándo aplicar ✅
- Empresas y tiendas online con plantillas personalizadas o múltiples child themes.
- Proyectos con despliegues automatizados y necesidad de control de cambios.
- Sitios que cargan activos externos o tienen formularios personalizados.
Errores que debes evitar / riesgos ⚠️
- Cambiar permisos sin entender la propiedad del proceso web (puede romper uploads).
- Usar DISALLOW_FILE_MODS en entornos donde se esperan actualizaciones rápidas sin CI.
- Copiar snippets de internet sin validar: introduce vulnerabilidades.
- No tener rollback ni snapshots: una actualización puede dejar el sitio caído.
Preguntas frecuentes
¿Qué es el hardening de temas y child themes?
El hardening de temas y child themes es el conjunto de medidas técnicas (permisos, configuración, saneamiento, cabeceras y auditoría) destinadas a reducir la superficie de ataque y proteger archivos y funciones del tema.
¿Un child theme hereda vulnerabilidades del tema padre?
Sí. Si el tema padre contiene código inseguro, esas vulnerabilidades pueden afectar al child theme. También el child theme puede introducir nuevos riesgos si no se revisa el código.
¿Qué permisos son los más seguros para /wp-content/themes?
Recomendación general: carpetas 755 y archivos 644, con propiedad del usuario del servidor web (ej. www-data). Ajustar functions.php a 640 si la política de usuario lo permite.
¿Cómo evitar que un atacante modifique functions.php?
Bloquear edición en el panel (DISALLOW_FILE_EDIT), restringir permisos y monitorizar cambios con checksums o un IDS de archivos.
¿Qué herramientas automatizan la auditoría de themes?
WPScan para vulnerabilidades conocidas y Theme Check para estándares de themes. Complementar con PHPCS, SonarQube o Snyk para análisis estático y de dependencias.
¿Se deben aplicar CSP y SRI a los assets del tema?
Sí. CSP reduce riesgos de inyección de scripts y SRI asegura integridad de recursos externos. Ambas son medidas complementarias.
¿Cómo gestionar actualizaciones del tema padre sin romper el child theme?
Probar actualizaciones en staging con CI que ejecute tests y visual regression; aplicar merge controlado y mantener compatibilidad a través de hooks bien definidos.
Tus próximos pasos
- Auditar el child theme hoy mismo: ejecutar WPScan y Theme Check en staging y listar warnings.
- Aplicar DISALLOW_FILE_EDIT y fijar permisos (644/755) tras confirmar propiedad del servidor.
- Integrar un pipeline CI que ejecute linters, WPScan y despliegue a staging con rollback automatizado.
