Guía sobre la securización de las llamadas API en un entorno de WordPress

Introducción: dos direcciones, dos problemas distintos

Se habla de «seguridad de la API» como si fuera un solo tema. Son dos, y confundirlos es la causa de la mayoría de los errores:

ENTRANTE : lo que el mundo puede pedir a su WordPress   → API REST, webhooks
SALIENTE : lo que su WordPress pide al mundo            → claves, proveedores, IA

El entrante es un problema de permisos: quién puede pedir qué. El saliente es un problema de secretos: dónde vive la clave y quién puede leerla. Este artículo trata los dos, empezando por el que más se descuida.

1. Saliente — dónde vive la clave

Es el punto que anula todo lo demás si se falla.

Nunca en un fichero versionado. Una clave en un repositorio permanece en el historial aunque se borre después. La revocación es la única solución real: cambiar el fichero no basta.

Nunca en el código de un tema. Un tema se copia, se comparte, se despliega en preproducción, se envía a un prestador.

Nunca en JavaScript del lado del cliente. Una clave que llega al navegador es una clave pública. Este error es más frecuente de lo que parece porque «funciona» perfectamente.

En una variable de entorno del servidor, o en el almacén de secretos de su alojamiento. Y con una regla organizativa que vale tanto como la técnica: una clave por cliente y por uso. Una clave compartida hace imposible toda imputación, y un desbordamiento se vuelve anónimo.

Ese último punto es también lo que hace legible el presupuesto — el razonamiento completo está en optimizar el presupuesto de su agencia con BYOK.

2. Saliente — lo que hay que verificar en cada llamada

• Un tiempo de espera explícito. Sin él, un proveedor lento bloquea su página. Es la causa más común de «el sitio se ha caído» cuando en realidad esperaba una respuesta.
• Un plafón de gasto en el proveedor, por clave. Es una garantía estructural: aguanta incluso si un tratamiento automático entra en bucle. Ningún compromiso contractual da eso, porque actúa a posteriori.
• Un límite de frecuencia en su lado, para que un bucle mal cerrado cueste un incidente y no un mes de presupuesto.
• Ningún dato inútil enviado. El mejor protegido es el que no ha salido: si el tratamiento solo necesita el texto de un producto, no necesita el nombre del cliente. Es el principio desarrollado en por qué la privacidad de los datos es su mejor aliada.
• Ningún secreto en los registros. Un mensaje de error que vuelca la petición completa escribe su clave en un fichero que se conserva y a veces se envía a un tercero.

3. Entrante — la API REST, y lo que expone por defecto

WordPress expone una API REST activa por defecto. No es un defecto, pero conviene saber tres cosas:

1. Ciertas rutas son públicas por diseño, y algunas revelan la lista de autores del sitio, es decir nombres de cuenta utilizables para un ataque de contraseña. Restringir esa ruta cuesta unas líneas.
2. Cada extensión puede añadir sus propias rutas. Su superficie entrante crece con cada instalación, sin que nadie lo mire. Es otro argumento para auditar sus extensiones.
3. Una ruta personalizada sin verificación de capacidades está abierta a todo el mundo. Es el error clásico de la extensión escrita a medida: se comprueba el nonce, se olvida la capacidad. El nonce demuestra el origen de la petición, no el derecho a ejecutarla. Hacen falta los dos.

4. Entrante — los webhooks

Un webhook es una URL pública que ejecuta código. Tres reglas, y ninguna es opcional:

• verificar la firma que envía el emisor, sistemáticamente. Sin verificación, cualquiera que conozca la URL puede desencadenar el tratamiento;
• hacer el tratamiento idempotente: el mismo evento recibido dos veces no debe producir dos efectos. Los proveedores reenvían, es normal;
• responder rápido y trabajar después. Un webhook que ejecuta un tratamiento largo antes de responder provoca reenvíos, y los reenvíos provocan duplicados.

5. Los cinco errores que se encuentran en todas partes

1. La clave en el cliente — funciona, y es público.
2. El nonce sin la capacidad — se comprueba el origen, no el derecho.
3. La clave compartida entre clientes — imposible imputar, imposible revocar sin afectar a todos.
4. Sin tiempo de espera — la caída del proveedor se convierte en su caída.
5. El secreto en los registros — se escribe una vez y se conserva durante meses.

6. El protocolo, en una página

• Ninguna clave en un repositorio versionado, en un tema o en JavaScript de cliente
• Una clave por cliente y por uso, en variable de entorno o almacén de secretos
• Plafón de gasto fijado en el proveedor, por clave, con alerta intermedia
• Tiempo de espera explícito en cada llamada saliente
• Límite de frecuencia en los tratamientos automáticos
• Rutas REST personalizadas: nonce y verificación de capacidades, sin excepción
• Webhooks: firma verificada, tratamiento idempotente, respuesta rápida
• Registros revisados: ningún secreto, ninguna petición completa volcada
• Procedimiento de revocación escrito — y probado una vez, no supuesto

El último punto es el que nadie hace y el único que cuenta el día que hace falta.

Conclusión

La seguridad de las llamadas API no descansa en una herramienta sino en dos preguntas que hay que poder responder en cualquier momento: ¿dónde viven mis claves, y quién puede leerlas? y ¿qué puede pedirme el mundo sin identificarse?

La mayoría de los incidentes no vienen de un ataque sofisticado, sino de una clave que estaba donde no debía y de una ruta que no verificaba lo que creía verificar.

La prueba: si tuviera que revocar todas sus claves esta noche, ¿sabría dónde están y cuánto tardaría? Si no puede responder, ese es el trabajo que hay que hacer primero.

Para seguir: el fortalecimiento avanzado de WordPress, la protección proactiva contra las amenazas de día cero y el enfoque RGPD+ y la arquitectura BYOK. Nuestras extensiones premium están disponibles con reembolso íntegro en 14 días : ver el catálogo.