Հանրային webhook-ներ և թերավճարման ռիսկ AI-ով կառուցված կայքերում

Ուղիղ պատասխան

Եթե վճարման կամ գործընթացի webhook-ը կարելի է կանչել առանց նույնականացման և դրանք ընդունում են հաճախորդի կողմից վերահսկվող գումարներ, հարձակվողը կարող է էժան հաշիվներ ստեղծել կամ բիզնես գործընթացներ գործարկել։ Գումարները և ապրանքի ինքնությունը պետք է լինեն հեղինակավոր սերվերի վրա։

Արագ AI նախատիպը հաճախ «հարմարության համար» թողնում է /api/pay և /api/webhook բաց։ Սա հարմարություն չէ - սա անցք է։

Ի՞նչ է սա նշանակում գործնականում

• Սկսեք իրական վճարման և fulfilment գործընթացից, ոչ թե Checkout-ի դեմո կոճակից։
• Նկարագրեք պարզ լեզվով. ով է սահմանում գումարը, ով է հաստատում վճարումը, ով է բացում մուտքը։
• Ստուգեք յուրաքանչյուր ուղի, որտեղ հաճախորդի բրաուզերը կարող է փոխել amount, plan id կամ coupon։
• Թողեք ձեռքով ուղի վիճելի վճարումների և վերադարձների համար։

Ինչպիսին է լավը

• Webhook մատակարարի ստորագրության ստուգմամբ (Stripe և նմաններ)։
• Գումարը և product id-ն սերվերի գնացուցակից / պատվերից, ոչ թե հաճախորդի body-ից։
• Իդեմպոտենտ մշակում. webhook-ի կրկնությունը կրկնակի մուտք չի տալիս։
• Մատյաններ. event id, order id, արդյունք, սխալներ։
• Գաղտնի բանալիներ միայն սերվերի վրա. կանգառի կոճակ մուտքի տրամադրման վրա։

Ինչպիսին է վատը

• «Պրևյուում վճարումը անցնում է» առանց ստորագրության ստուգման։
• Հանրային endpoint «նշիր որպես վճարված» առանց auth-ի։
• Գինը և plan id-ն վստահում են frontend query/body-ին։
• underpay / overpay համադրում չկա։
• Բարակ մեքենայական «վճարման» լենդինգ առանց սերվերային պատվերի մոդելի։

Տիպիկ հարձակումներ

1. Underpayment - հաճախորդը ուղարկում է amount=1, սերվերը բացում է premium։
2. Replay - հին հաջող event-ը կրկին է ուղարկվում։
3. Forged webhook - POST առանց ստորագրության, կարծես Stripe-ից։
4. Workflow trigger - բաց URL-ը գործարկում է զեղչ, նամակ, CRM գործարք։

Ինչպես է փակում Dali-ն

Ամրացնում ենք վճարման և գործընթացների ուղին. vibe-code rescue, վճարումներ և գաղտնի բանալիներ, admin/promo սահմանափակումներ։ Կապված. մարտական գործակալներ, վերահսկման կետեր։