Cómo proteger los webhooks de CRM y e-commerce frente a eventos falsos o duplicados

Un webhook no es solo una URL que recibe datos de una plataforma externa. Es una puerta de entrada que puede crear un pedido, actualizar una ficha de cliente, emitir un aviso, modificar existencias o iniciar una automatización. Si se acepta un evento de origen no verificado, repetido o con datos inesperados, una integración útil puede provocar acciones de negocio indebidas.

El problema requiere combinar controles técnicos y operativos: saber qué proveedor puede llamar, qué eventos están permitidos, qué datos son aceptables y qué consecuencia concreta puede tener cada mensaje. El objetivo no es bloquear las integraciones, sino diseñarlas para que un fallo, un reintento o una notificación anómala no se conviertan automáticamente en un pedido, un cargo, un cambio de estado o una alerta falsa.

El riesgo: una notificación puede convertirse en una acción empresarial

En una integración habitual, una pasarela de pago, un e-commerce, un CRM o una herramienta de mensajería envía una notificación servidor a servidor a un endpoint propio. El receptor no debería tratar esos datos como fiables por el mero hecho de llegar desde una integración conocida. OWASP identifica el consumo inseguro de APIs como un riesgo cuando una aplicación confía excesivamente en servicios integrados y reduce controles de autenticación, cifrado o validación de los datos recibidos. [1]

Por ejemplo hipotético, una tienda puede recibir el evento “pago confirmado” y liberar un pedido sin comprobar su autenticidad, su referencia interna o su estado real. Otro sistema podría recibir dos veces una notificación de alta de cliente y crear registros duplicados. El impacto depende de la acción conectada al webhook, por lo que conviene evaluar cada endpoint como parte de un proceso de negocio y no como un detalle menor de configuración.

Empiece con un inventario y un alcance definido

Antes de cambiar código o reglas de automatización, elabore un inventario de webhooks. Para cada uno, identifique el proveedor emisor, la URL receptora, los eventos permitidos, el sistema de destino, la persona responsable, el mecanismo de autenticación y la fecha de la última revisión. Mantener visibilidad sobre las APIs y sus interfaces ayuda a reducir problemas derivados de un inventario deficiente o de interfaces olvidadas. [5]

También defina qué puede hacer cada evento válido. Que una notificación esté autenticada no significa que deba poder modificar cualquier dato. Un evento de entrega debería actualizar solo el estado de envío previsto; no debería crear reembolsos, cambiar precios ni alterar permisos. Esta separación permite aplicar el principio de mínimo efecto: cada mensaje desencadena únicamente la acción que su tipo y contexto justifican.

• Documente proveedor, endpoint, responsable, eventos aceptados y sistema afectado.
• Indique si el evento contiene datos personales, referencias de pedido o información sensible.
• Establezca una vía de desactivación controlada para detener temporalmente una integración ante una incidencia.

Verifique el origen antes de ejecutar la acción

La ruta receptora debe usar HTTPS y estar dedicada al webhook, sin convertirla en un punto de entrada genérico para múltiples funciones. La autenticación debe seguir el mecanismo documentado por cada proveedor: puede consistir en una firma calculada sobre la solicitud, un secreto asociado a la suscripción o un token. NIST recomienda incorporar autenticación de quien llama y validación de solicitudes y respuestas como controles de protección de APIs. [2]

La comprobación debe realizarse antes de lanzar efectos de negocio. Según el modelo del proveedor, puede implicar verificar una firma, una marca temporal, un identificador de suscripción o los elementos de un JWT, como su caducidad, emisor, firma y audiencia. Microsoft Graph describe estos patrones para sus notificaciones y señala que la validación correspondiente debe completarse antes de considerar una notificación como auténtica. Los secretos deben mantenerse fuera del código de la aplicación y protegerse adecuadamente. [3] [4]

• Rechace solicitudes que no usen el método HTTP previsto.
• Compare firmas o secretos mediante mecanismos seguros proporcionados por el lenguaje o plataforma.
• Defina límites de tamaño para las solicitudes y plazos razonables de aceptación cuando el proveedor los soporte.

Valide el contenido y haga que el procesamiento sea idempotente

Una firma válida acredita el mecanismo de envío, pero no sustituye la validación del contenido. Compruebe el tipo de evento, la estructura esperada, los campos obligatorios, formatos, rangos, valores permitidos y referencias internas antes de enviar datos a un ERP, CRM, WordPress o sistema de pedidos. OWASP recomienda validar y sanear los datos que proceden de APIs externas, ya que deben tratarse como información no confiable. [1]

Para evitar duplicados, registre un identificador único del evento, el proveedor y el resultado de su procesamiento. Antes de crear un pedido, emitir un ticket o actualizar stock, consulte si esa combinación ya fue aceptada. Si vuelve a llegar, registre el intento para investigación, pero no repita la acción. La idempotencia debe diseñarse en el sistema receptor, porque los emisores pueden reenviar notificaciones tras errores o tiempos de espera. [4]

• Conserve una ventana de deduplicación adecuada al ciclo de cada proceso.
• Relacione el ID del evento con la referencia interna de pedido, cliente o transacción.
• Trate por separado los eventos repetidos, inválidos y pendientes de revisión para facilitar su seguimiento.

Separe la recepción de la ejecución y deje evidencia útil

Cuando el proveedor lo permita, valide rápidamente la notificación, guárdela de forma controlada y envíela a una cola para su procesamiento posterior. Así se reduce el riesgo de que una operación lenta provoque un tiempo de espera y un reintento del emisor. Microsoft Graph, por ejemplo, recomienda confirmar o encolar pronto las notificaciones y contempla reintentos cuando no recibe una respuesta satisfactoria. [4]

El procesamiento diferido no elimina los controles: el trabajador que consume la cola debe volver a aplicar reglas de idempotencia, validar el contexto de negocio y registrar el resultado final. Guarde fecha, proveedor, ID de evento, resultado de autenticación, resultado de validación, acción solicitada y referencia interna. Evite conservar cuerpos completos si incluyen tokens, secretos o datos personales innecesarios. Pruebe los flujos solo en entornos autorizados, con eventos de prueba documentados o preproducción, incluyendo firmas inválidas, formatos inesperados y reenvíos controlados.

• Defina quién revisa los eventos fallidos o pendientes.
• Alerte sobre aumentos anómalos de rechazos, duplicados o errores de procesamiento.
• Revise el inventario y las reglas cuando cambie el proveedor, el endpoint o el proceso de negocio.

Preguntas frecuentes

¿Basta con ocultar la URL del webhook?

No. Una URL poco visible no sustituye la autenticación ni la validación. El endpoint debe verificar el mecanismo admitido por el proveedor, aceptar únicamente eventos esperados y limitar las acciones que puede iniciar.

¿Por qué recibo el mismo webhook más de una vez?

Muchos emisores reintentan una notificación si no reciben una respuesta adecuada o si se produce un tiempo de espera. El receptor debe preverlo con un identificador de evento, un registro de procesados y lógica idempotente para no repetir la acción empresarial.

¿Qué conviene revisar tras una incidencia con un webhook?

Revise la evidencia disponible: proveedor, ID de evento, hora, resultado de autenticación, validación de contenido, acción solicitada y referencia interna. Después, corrija la regla concreta, pruebe el cambio en un entorno autorizado y actualice el inventario del webhook.