あなたのSaaSからお金が漏れ出している
ほとんどの開発者は、SaaSをリリースしたら次のプロジェクトへ移ってしまいます。セキュリティは後回しのタスクとして扱い、実際のユーザーや収益が発生するのを待つのです。
実際の金銭的損失は、多くの場合、単純なミスから発生します。それらは複雑なハッキングではなく、コード内のロジックエラーなのです。
お金を失う、よくある4つのパターンを紹介します：
- クレジットシステムにおけるレースコンディション（競合状態） ユーザーの残高を読み取り、チェックし、新しい残高を書き込む。もしユーザーが同時に2つのリクエストを送信した場合、最初のリクエストがデータベースを更新する前に、両方のリクエストがチェックを通過してしまう可能性があります。その結果、1回分の料金で2回分のサービスを提供することになってしまいます。
解決策：アトミックなデータベース操作を使用する。読み取ってから書き込むのではなく、ユーザーに十分なクレジットがある場合にのみ残高を更新する単一のコマンドを使用してください。
- アイデンティティ（本人確認）におけるクライアント入力の信頼 チェックアウト時にリクエストボディからメールアドレスを取得しているケースです。認証済みのユーザーは、そのメールアドレスを他人のものに書き換えることができます。これにより、誤ったアカウントに対して請求セッションを作成したり、システムを調査したりすることが可能になってしまいます。
解決策：リクエストボディからのアイデンティティを決して信頼しない。サーバー上の検証済みセッショントークンからメールアドレスを抽出してください。
- 年間プランの請求ロジックの不備 多くの開発者は、Stripeの支払いイベントをリッスンすることでユーザーのクレジットをリセットしています。これは月額プランでは機能しますが、年間プランでは失敗します。Stripeは年に1回しかイベントを送信しません。ユーザーは初日にクレジットを受け取りますが、その後11ヶ月間は何も受け取れないことになります。
解決策：クレジットのリセットを請求イベントから切り離す。リセット日に基づいて、どのユーザーにリセットが必要かをチェックするデイリーのcronジョブを使用してください。
- 安全でないトークン保存
パスワードリセットトークンを
localStorageに保存しているケースです。ページ上のあらゆるスクリプトがlocalStorageにアクセスできます。これには、ブラウザ拡張機能やサードパーティの分析ツールも含まれます。
解決策：認証SDKを使用してリカバートークンを処理する。トークンをlocalStorageに保存せず、ライブラリに自動的に処理させてください。
問題は常に同じです。クライアントを信頼しすぎていることです。リクエストが一つずつ届くと信じ、請求イベントがすべてのケースをカバーしていると信じてしまっています。
これらの問題を修正するのにかかる時間は、一日もかかりません。お金を失う前に、コードを監査しましょう。
出典: https://dev.to/manolito99/your-saas-is-probably-leaking-money-right-now-and-you-dont-know-it-1g38