საჯარო webhook-ები და ნაკლებად გადახდის რისკი AI-ით აგებულ საიტებზე

პირდაპირი პასუხი

თუ გადახდის ან პროცესის webhook-ის გამოძახება auth-ის გარეშე შეიძლება და ისინი იღებენ კლიენტის მიერ კონტროლირებად თანხებს, თავდამსხმელს შეუძლია იაფი ინვოისები შექმნას ან ბიზნეს პროცესები გაუშვას. თანხები და პროდუქტის იდენტობა სერვერზე უნდა იყოს ავტორიტეტული.

სწრაფი 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 ლიმიტები. დაკავშირებული: საბრძოლო აგენტები, კონტროლის წერტილები.