Proteger wp-config.php y wp-includes: guía Apache y Nginx

Proteger wp-config.php es una de esas tareas de seguridad que todo el mundo da por hecha y casi nadie hace. Y es raro, porque ese archivo guarda justo lo que no quieres que vea nadie: las credenciales de conexión a la base de datos, las claves de cifrado de las sales de WordPress (SALT) y otros parámetros sensibles que, si se filtran, comprometen el sitio entero. La carpeta wp-includes, por su parte, contiene el núcleo de WordPress y tampoco debería ser accesible ni ejecutable directamente desde el navegador. Aquí vas a ver cómo blindar ambos elementos en Apache y Nginx, con reglas concretas que funcionan. ¿Y si prefieres no tocar nada tú mismo? En RedServicio (redservicio.net) pueden revisar tu configuración y resolver cualquier problema técnico de tu servidor o de WordPress.

Por qué wp-config.php y wp-includes son objetivos prioritarios

Los atacantes automatizados rastrean millones de sitios WordPress buscando fallos conocidos. ¿Dónde miran primero? Pues precisamente aquí:

• wp-config.php: contiene el usuario y la contraseña de MySQL, el prefijo de tablas, las claves de autenticación y, en muchas configuraciones, datos de servicios externos (SMTP, CDN, APIs). Lo peligroso es esto: si el servidor sufre un mal funcionamiento y sirve el archivo como texto plano en lugar de ejecutarlo, el atacante se queda con acceso total a la base de datos. Sin magia, sin exploits sofisticados.
• wp-includes: contiene scripts PHP del núcleo que nunca deben ejecutarse de forma directa. Archivos como wp-includes/js/tinymce/… o algunos endpoints antiguos se han explotado históricamente mediante inclusiones remotas o inyecciones cuando el servidor permite ejecutarlos aislados.

Hay algo más. Un plugin vulnerable puede permitir ataques de path traversal o lectura arbitraria de archivos, y el primer objetivo de esos ataques suele ser, otra vez, wp-config.php. Bloquear a nivel de servidor añade una capa de defensa que aguanta incluso cuando WordPress o un plugin fallan. Esa redundancia es la que te salva.

Cómo proteger wp-config.php en Apache con .htaccess

En Apache, lo más directo es usar directivas files o filesmatch en el archivo .htaccess de la raíz de WordPress. Añade esto antes de las reglas de reescritura:

<files wp-config.php>
require all denied
</files>

¿Trabajas con Apache 2.2 o anterior? La sintaxis equivalente es Order allow,deny / Deny from all. Y un detalle que muchos pasan por alto: si tu panel de control lo permite, mejor mover la regla al virtualhost, porque .htaccess puede quedar deshabilitado con la directiva AllowOverride None. Te habría funcionado en local y no servir de nada en producción.

Otros pasos recomendados en Apache:

1. Cambiar los permisos del archivo a 400 o 440, de modo que solo el propietario pueda leerlo.
2. Bloquear el listado de directorios con Options -Indexes. Evita exposición en wp-includes.
3. Deshabilitar la ejecución de PHP en wp-includes/uploads mediante un .htaccess con php_flag engine off o un handler que devuelva 403.

Comprueba después de cada cambio que la web sigue funcionando. Una regla mal escrita en .htaccess y tienes un error 500 en toda la web. Lo he visto más de una vez.

Cómo proteger wp-config.php y wp-includes en Nginx

Nginx no usa .htaccess, así que las reglas van en el bloque server de tu archivo de configuración (normalmente en /etc/nginx/sites-available/ o /etc/nginx/conf.d/). Para bloquear el acceso al archivo de configuración:

location = /wp-config.php {
deny all;
access_log off;
log_not_found off;
}

Y para impedir la ejecución directa de PHP dentro de wp-includes:

location ~* /wp-includes/.*\.php$ {
deny all;
}

Tras editar, valida la sintaxis con nginx -t y recarga con systemctl reload nginx. No te saltes el test previo. Vale también la pena limitar el acceso a wp-includes/js/tinymce solo a usuarios autenticados si tu sitio tiene varios editores. Si no has manejado Nginx antes, en RedServicio (redservicio.net) pueden aplicar estas configuraciones de forma segura y sin interrumpir tu servicio.

Restringir el acceso al directorio wp-includes

El directorio wp-includes contiene el núcleo de WordPress: librerías, scripts de administración y archivos que no deberían ejecutarse nunca directamente desde el navegador. Y aquí viene el matiz. No se trata de bloquear todo el directorio (romperías el frontend), sino de permitir el paso a los archivos estáticos necesarios (imágenes, CSS, JavaScript) y denegar la ejecución de PHP dentro de la carpeta.

Regla para Apache

Crea o edita el archivo wp-includes/.htaccess con este contenido:

• Options -Indexes: desactiva el listado de directorios, así un atacante no puede explorar el contenido.
• Con <Files ~ «\.(php|php5|phtml)$»> y la directiva Require all denied (Apache 2.4) bloqueas cualquier intento de ejecutar PHP dentro de la carpeta.

¿Y si algún plugin o tema necesita un script concreto de wp-includes? Poco habitual, pero pasa. En ese caso permite su acceso de forma individual con Require ip tu.direccion.ip. No abras el directorio entero por un solo archivo.

Regla para Nginx

Añade dentro del bloque server de tu configuración:

• location ~* /wp-includes/.*\.php$ { deny all; }: corta toda ejecución de PHP en wp-includes.
• location ~* /wp-includes/js/tinymce/ { allow 1.2.3.4; deny all; }: si gestionas un sitio con varios editores, limita el editor TinyMCE a las IP de oficina o VPN.
• Recuerda recargar el servicio con nginx -t && systemctl reload nginx. Validar la sintaxis antes de aplicar los cambios te ahorra más de un disgusto.

Con esto neutralizas un vector de ataque clásico: la explotación de vulnerabilidades en scripts del núcleo accesibles directamente por URL. Mantener WordPress actualizado está bien, claro. Pero esta capa evita que un exploit conocido llegue siquiera a ejecutarse.

Comprobaciones y pruebas de seguridad tras aplicar las reglas

Aplicar reglas sin verificarlas es una fuente habitual de sitios rotos. Lo he visto más veces de las que me gustaría. Antes de dar por bueno el cambio, pasa esta lista:

1. Acceso directo a wp-config.php: abre https://tudominio.com/wp-config.php. Debe devolver un 403 o 404. Nunca contenido. Nunca una página en blanco.
2. Backup del sitio: descarga el archivo y comprueba que sigue intacto; el bloqueo debe afectar solo al acceso web, no al funcionamiento interno de WordPress.
3. Funcionamiento general: navega por la portada, una entrada con imágenes, un formulario de contacto y el personalizador de tema. Los archivos estáticos de wp-includes (como load-styles.php y los scripts de jQuery) deben seguir cargando.
4. Editor de entradas: abre el editor de bloques y mira que los scripts de TinyMCE y demás utilidades cargan sin errores en la consola del navegador.
5. Registro de errores: revisa /var/log/nginx/error.log o el error_log de Apache buscando 403 inesperados tras publicar contenido.

Si algo se rompe, el método más rápido es comentar la última regla añadida, recargar el servidor y volver a probar. Cambia siempre una sola directiva cada vez. Solo así podrás aislar la causa del problema.

Conclusión: blindar tu WordPress desde el servidor

Proteger wp-config.php y restringir la ejecución de código en wp-includes son dos de las medidas con mejor relación entre esfuerzo y resultado que puedes aplicar en un WordPress. No sustituyen a mantener el núcleo, los plugins y los temas actualizados (eso no negocia), pero añaden una barrera a nivel de servidor que bloquea los vectores de ataque más comunes incluso cuando alguna extensión presenta una vulnerabilidad.

La cosa, resumida, queda en tres frentes:

• Denegar el acceso web a wp-config.php en Apache y Nginx, impidiendo que las credenciales de la base de datos lleguen a salir del servidor.
• Bloquear la ejecución de PHP en wp-includes sin por ello romper el frontend ni el panel de administración.
• Verificar tras cada cambio que el sitio funciona y que las reglas responden con los códigos HTTP esperados.

No lo olvides: complementa estas reglas con permisos de archivo correctos (644 para wp-config.php, 750 para los directorios sensibles), copias de seguridad automáticas y autenticación en wp-login. La seguridad de WordPress es una suma de capas, y el servidor web es la primera de todas. Si prefieres delegar esta tarea en profesionales o has aplicado las reglas y algo no funciona como esperabas, en RedServicio (redservicio.net) podemos auditar tu servidor, aplicar estas configuraciones de forma segura y dejar tu WordPress blindado sin interrumpir el servicio.