Revisión de seguridad de webhooks de Stripe: la verificación de checkout de $2,400
Revisión de seguridad de webhooks de Stripe de las verificaciones de firma y de quién puede leer una Checkout Session. $2,400 de pago único por app, $1,200 para empezar, sin suscripción.
En este artículo· 6 secciones
- 01¿Qué comprueba una revisión de seguridad del webhook de Stripe?
- 02¿Cuánto cuesta una revisión de seguridad del webhook de Stripe?
- 03¿Cómo debe cumplir un pedido el webhook?
- 04¿Quién puede leer una Checkout Session?
- 05¿Qué hay en la lista de verificación de la primera pasada?
- 06Cuando todavía no es el paso correcto
Una revisión de seguridad del webhook de Stripe responde una pregunta del dueño de negocio: ¿puede un desconocido marcar un pedido como pagado, o leer la Checkout Session de otra persona, en la app que ya tienes en marcha?
Eso lo vendo como una revisión de seguridad autorizada de una aplicación web. $2,400 de pago único por app. $1,200 para empezar. El informe queda escrito 48 horas después de que el acceso funcione. El PDF es tuyo. Sin suscripción.
Respuesta corta: Una revisión de seguridad del webhook de Stripe comprueba que tu endpoint verifica la firma de Stripe sobre el cuerpo sin procesar, y que una Checkout Session no la pueda leer la persona equivocada. Las dos las hago dentro de la revisión de seguridad de aplicaciones web: $2,400 de pago único, $1,200 para empezar, 48 horas después del acceso. No es un escáner mensual.
¿Qué comprueba una revisión de seguridad del webhook de Stripe?
Una revisión de seguridad del webhook de Stripe comprueba la verificación de la firma sobre el cuerpo sin procesar y quién puede leer una Checkout Session. Las dos van dentro de una sola revisión autorizada de la app: $2,400 de pago único, $1,200 para empezar, escrita 48 horas después de que el acceso funcione.
La documentación de webhooks de Stripe dice que el handler verifica el payload con el encabezado Stripe-Signature y el secreto whsec_ de ese endpoint, sobre el cuerpo sin procesar. Si un framework analiza el cuerpo primero, la verificación falla, o te la saltas y confías en el JSON que haya llegado. Devuelve un 2xx antes del trabajo lento, como actualizar una factura.
Las bibliotecas oficiales traen por defecto una tolerancia de 5 minutos. Una tolerancia de 0 apaga la comprobación de que el evento sea reciente. El modo live reintenta durante hasta tres días. Sandbox reintenta tres veces a lo largo de unas horas. Si cumples el pedido en cada entrega, un reintento lo envía dos veces.
Cada endpoint tiene su propio secreto. Test y live son distintos aunque la URL sea la misma. El secreto de stripe listen no es el secreto del Dashboard. Mezclarlos es la razón por la que una comprobación funciona en una laptop y falla en producción.
El resto de la pasada son las llamadas que la página ya hace. La versión más amplia es revisión de seguridad de API. Checkout es la parte del pago.
¿Cuánto cuesta una revisión de seguridad del webhook de Stripe?
La revisión cuesta $2,400 de pago único por una aplicación. Con $1,200 arranca y el saldo se paga cuando se entrega el informe. El PDF es tuyo. No hay cuota mensual. Una segunda app, una auditoría de código fuente o una carta de certificación es otra cotización.
A lo largo de 24 meses y de 36 meses la cifra sigue en $2,400. No hay una cuota por usuario que se acumule. La misma cifra está en precios de la revisión de seguridad.
| Qué estás comprando | Precio | Qué recibes de verdad |
|---|---|---|
| Esta revisión, una app web | $2,400 de pago único, $1,200 para empezar | Frontend, autenticación, API, firma del webhook, lecturas de Checkout Session. Escrito 48 horas después del acceso. |
| Una segunda app | Otros $2,400 | El mismo alcance, una autorización por escrito nueva |
| Auditoría de código fuente o una carta de certificación | No es esta cotización | Trabajo aparte. No invento certificaciones. |
| Automatización de flujos de trabajo | $3,500 de pago único | Un trabajo de operaciones con nombre, como copiar reembolsos a QuickBooks. No es una revisión de seguridad. |
| Puerta de entrada con IA | $3,500, $7,500 o $14,000 de pago único | Los clientes reservan o pagan desde una app de IA. No es una revisión de webhook. |
¿Cómo debe cumplir un pedido el webhook?
Stripe dice que el cumplimiento va en el webhook, no en la página de éxito, porque el cliente puede no llegar nunca ahí. Verifica la firma, guarda el id del evento una sola vez, marca el pedido como pagado en tu sistema de registro y devuelve un 2xx antes del trabajo lento.
La guía de cumplimiento de Stripe dice que no puedes confiar en la página de éxito. Un comprador puede pagar e irse antes de que cargue. Checkout alojado espera hasta 10 segundos a checkout.session.completed antes de redirigir. En la CLI, la redirección es inmediata. Producción es el camino de los 10 segundos.
| Paso | Acción | Sistema de registro | Escalamiento a una persona |
|---|---|---|---|
| Disparo | Stripe envía checkout.session.completed | Evento de Stripe | Ninguno |
| Verificar | Firma sobre el cuerpo sin procesar, el secreto de este endpoint, marca de tiempo dentro de cinco minutos | Tu handler del webhook | Rechaza y avisa a una persona si la verificación falla |
| Registrar | Guarda el id del evento una sola vez | Tu tabla de pedidos | Una entrega duplicada no debe cumplir el pedido otra vez |
| Cumplir | Márcalo pagado solo después del evento verificado | Pedidos, Jobber o la hoja en la que ya confías | El monto, la moneda o el cliente no coinciden con el pedido que creaste |
| Mostrar el recibo | La página de éxito puede cargar la sesión de ese comprador | Tu app, con la clave secreta en el servidor | La consulta del equipo es una ruta aparte, con sesión iniciada |
Copiar reembolsos a QuickBooks es otro producto: Automatización de flujos de trabajo, $3,500 de pago único por un trabajo con nombre, en marcha en 7 a 10 días. No reemplaza la comprobación de la firma.
¿Quién puede leer una Checkout Session?
Recuperar una Checkout Session es una llamada a la API hecha con tu clave secreta. La URL de éxito puede traer el id de la sesión. La revisión pregunta si una ruta que acepta ese id devuelve el correo, la dirección o el estado de pago de otra persona.
La llamada de Stripe para recuperar una Checkout Session usa la clave secreta. La documentación de la página de éxito te dice que pongas {CHECKOUT_SESSION_ID} en success_url. Ese id queda entonces en una barra de direcciones, un chat de soporte o un log de referrer.
La pregunta es tu ruta. ¿Quién puede pedirle a tu servidor que cargue esa sesión, y qué campos vuelven? El punto es que el comprador vea su propio recibo. Que un desconocido vea el correo, la dirección o el estado de pago es el hallazgo. Escribo la ruta, la severidad y la corrección. Sin receta en el PDF.
Que los clientes paguen desde ChatGPT, Claude o Grok es otro desarrollo: Puerta de entrada con IA, desde $3,500. La misma conexión funciona en la que ya usen de esas apps. No es esta revisión.
¿Qué hay en la lista de verificación de la primera pasada?
Recorro la ruta de pago que tu interfaz ya usa: el cuerpo sin procesar antes de cualquier analizador, el secreto del Dashboard de ese endpoint, los secretos de live y de test separados, una ventana de marca de tiempo de cinco minutos y una fila de cumplimiento por cada id de evento.
Entrégale esto a quien tenga el handler:
- El framework no analiza el cuerpo antes de la comprobación de la firma.
- El secreto es el
whsec_del Dashboard de este endpoint, no el secreto de la CLI, y live no está cambiado por test. - El cumplimiento se identifica con el id de evento de Stripe, porque los reintentos de live corren hasta tres días.
- Una ruta que acepta un id de sesión no devuelve el correo, la dirección o el estado de pago de otro cliente.
- Puedes rotar el secreto de firma. Stripe permite hasta 24 horas de coincidencia mientras actualizas el servidor.
Cuando todavía no es el paso correcto
Espera si Checkout no está en live, si necesitas una carta de PCI que no vendo, o si el trabajo de verdad es perseguir reembolsos en QuickBooks. Ese último trabajo es Automatización de flujos de trabajo, no una revisión de seguridad.
No contrates la revisión cuando:
- Todavía no tienes una Checkout Session ni un endpoint de webhook. No hay nada que autorizar.
- Necesitas un PCI QSA, una carta de CREST o un sello de compras. Eso no lo vendo.
- La app es un binario móvil, una red interna o una auditoría solo del código fuente. Esas son otras cotizaciones.
- No vas a firmar una autorización por escrito. No empiezo en un sistema que no sea de quien lo envía.
- El dolor son facturas sin cobrar o una exportación de reembolsos del viernes. Compra el trabajo de operaciones, no un PDF de seguridad.
Una muestra redactada, sin nombres de clientes y sin payloads de exploit, está en el formulario de solicitud de muestra. El alcance y la división del pago están en Revisión de seguridad de aplicaciones web.
Envía la URL de la app y dime si Checkout está en modo test o en live. Empieza la revisión con $1,200. Te respondo con el mapa de alcance dentro de 24 horas. Si prefieres hablar del flujo de trabajo y de si la revisión encaja, reserva una llamada de 20 minutos.
Preguntas frecuentes
How much does a Stripe webhook security review cost? +
I charge $2,400 once for one web app, with $1,200 to start and the rest on delivery. That covers frontend, auth, and API, including signature checks and Checkout Session reads. You own the report. There is no subscription. A second app is a second quote.
Is the success page enough to mark an order paid? +
No. Stripe's fulfillment docs say a customer can pay and never reach your success page. Fulfillment belongs on a verified webhook. The redirect can show a receipt. It is not the record that the order was paid. Hosted Checkout may wait about 10 seconds for that webhook before redirecting.
What is not included in the $2,400? +
Source-code audit, mobile binaries, phishing, and any certification letter. I do not invent certifications. The PDF has no exploit payloads and no client names. A redacted sample is available before you pay. One retest of the same URL is included.
Do you need my live secret key? +
I need written authorization and access that works, usually a test-mode app plus the webhook endpoint you want reviewed. I do not start on a system you do not own. The 48-hour clock starts when that access works, not when the first email arrives.
