WordPress headless, donde el CMS actúa como backend de contenido y un frontend independiente consume sus APIs, es una arquitectura cada vez más popular. Pero con esta flexibilidad vienen responsabilidades de seguridad que los sitios WordPress tradicionales no tienen: las APIs REST y GraphQL expuestas públicamente son una superficie de ataque que necesita protección específica.

El modelo de seguridad en WordPress headless

En un WordPress headless, la API REST (/wp-json/) y opcionalmente WPGraphQL (/graphql) son los puntos de entrada principales. A diferencia de un WordPress tradicional donde la seguridad se concentra en el formulario de login y el acceso al wp-admin, en la arquitectura headless cualquier endpoint de la API es potencialmente accesible desde internet.

El riesgo no es solo el acceso no autorizado a datos. Las APIs mal configuradas pueden revelar información sensible (direcciones de email de usuarios, metadatos internos), ser vulnerables a ataques de enumeración de usuarios o sufrir ataques de denegación de servicio específicos para las rutas de la API.

Hardening de la REST API de WordPress

• Deshabilitar endpoints que no uses: la ruta /wp-json/wp/v2/users expone información de usuarios por defecto. Si no la necesitás, deshabilitala.
• Requerir autenticación para endpoints sensibles usando Application Passwords o OAuth.
• Rate limiting específico para rutas de la API: una IP no debería poder hacer 1000 consultas a la API por minuto.
• Deshabilitar la REST API completamente para usuarios no autenticados si el frontend no necesita datos públicos.
• Revisar todos los plugins instalados: muchos agregan sus propios endpoints a la REST API sin documentarlo claramente.

Seguridad específica para WPGraphQL

GraphQL introduce vulnerabilidades específicas que no existen en REST: las queries de profundidad excesiva (deeply nested queries) pueden generar consultas a base de datos extremadamente costosas que degradan el rendimiento del servidor. El plugin WPGraphQL incluye configuración para limitar la profundidad máxima de las queries y el número de nodos que se pueden solicitar.

La introspección de GraphQL (que permite a cualquier cliente descubrir el schema completo) debe deshabilitarse en producción para no facilitar a atacantes el mapa completo de los datos disponibles. En desarrollo puede mantenerse activa, pero el entorno de producción debe tenerla desactivada o restringida a clientes autenticados.

CORS: configuración correcta para frontends externos

En una arquitectura headless, el frontend JavaScript se sirve desde un dominio diferente al WordPress (por ejemplo, frontend.empresa.com consume la API de cms.empresa.com). Esto requiere configurar correctamente los headers CORS para que el navegador permita las peticiones cross-origin solo desde los dominios autorizados.

Una configuración CORS permisiva (Access-Control-Allow-Origin: *) facilita ataques CSRF donde un sitio malicioso puede hacer peticiones a la API de WordPress en nombre de un usuario autenticado. La configuración correcta especifica exactamente qué dominios están autorizados.

En Octopus Agencia Digital tenemos experiencia construyendo arquitecturas WordPress headless seguras. Si estás planeando o ya tenés una instalación headless y querés revisar su seguridad, contactanos.