Un webhook recibido todavía debe demostrar de dónde viene
Una aplicación recibe un aviso que parece correcto: tiene un tipo de evento, un identificador y los datos esperados. Eso no demuestra quién lo ha enviado. Si el aviso puede poner en marcha una acción, comprobar su origen forma parte del proceso.
Un ejemplo concreto: la firma de Stripe
La documentación de Stripe recomienda verificar los eventos recibidos en el webhook. Su ejemplo utiliza el cuerpo de la petición, la cabecera Stripe-Signature y el secreto del endpoint con la función constructEvent(). No basta con ver una cabecera con ese nombre: hay que validarla según el mecanismo del proveedor.
Cada servicio tiene su propio contrato. No copies el nombre de una cabecera o una regla de Stripe a otra integración suponiendo que funcionará igual. Revisa la documentación del servicio y la biblioteca que utiliza la aplicación antes de aceptar el evento como verificado.
El cuerpo original importa
Stripe explica que la verificación necesita el cuerpo original de la petición, sin cambios. Añadir espacios, reordenar propiedades o transformar el contenido antes de comprobar la firma puede hacer que la validación falle.
Este detalle afecta a la configuración del servidor: algunos frameworks procesan el JSON automáticamente antes de que el código del webhook lo reciba. Comprueba el orden de los componentes y conserva el cuerpo necesario para verificarlo. No desactives la comprobación para hacer desaparecer el error; separa el problema de configuración de la aceptación de datos no verificados.
Entornos distintos, secretos distintos
Otro error habitual que describe Stripe es utilizar el secreto de un endpoint diferente. Los eventos reenviados con su herramienta de desarrollo y un endpoint configurado en el panel no comparten necesariamente el mismo secreto. Identifica el entorno y el destino antes de configurar la verificación.
Para probar el circuito, utiliza las herramientas de prueba oficiales y comprueba que un mensaje alterado no desencadena la acción. Evita exponer secretos o datos de clientes en registros compartidos. Una firma válida tampoco decide qué acción corresponde: después hay que validar el tipo de evento y aplicar las reglas de negocio. Recibir, verificar y actuar son pasos distintos.