AIで速く作ったWebサービスに共通する、認可と認証の3つの弱点を直した

課題

AIで開発すると、動くものは早く出ます。ただ「動いている」と「守られている」は別で、認可と認証は正常系だけを見ていると弱点が残ります。稼働中のサービスを複数社で点検すると、開発者も技術構成も違うのに、同じ型の弱点が繰り返し見つかりました。

• データベースの公開範囲が広く、Web層の認証だけでは守られていなかった
• 画面(URL)単位の認可はあるが、画面から呼ばれるサーバー処理の側に本人確認が無かった
• 認証が「有効」の設定なのに、資格情報が未設定で、実際には機能していなかった

取り組み

• 設定ファイルを読んで判断するのではなく、実際のリクエストで「守られているか」を確かめる点検を先に行った
• データベースの公開読み取りを全テーブルで止め、アプリからのアクセスを内部権限に一本化。適用の瞬間に機能が止まらないよう、アプリ側の修正を先に出す順序で進めた
• 画面の認可とサーバー処理の認可を分けて点検し、処理の内側で本人確認を行う形に。認可の失敗は黙って空を返さず、拒否として扱う
• 認証は「未設定なら拒否」に変更し、設定と実装のずれを実際の動作で確認
• 実装した本人とは別の文脈で独立したレビューを行い、指摘は一次情報で確かめてから対応
• 顧客への共有は、指摘を人ではなく構造に帰す書き方にし、未修正の項目の詳細は共有資料に書かない

結果

項目	結果
データベースの公開読み取り	数十テーブル→0(全テーブルで拒否を実測)
サーバー処理の認可	一般ユーザーが到達できる経路を優先して修正。残りは顧客の課題管理へ引き継ぎ
認証の設定漏れ	未設定なら拒否する形に修正

この案件から言えること

「動いている」と「守られている」は別です。 守られているかは、設定を読むのではなく実際の動作で確かめます。認可は入口(URL)ではなく、処理の内側に置く。この2点は、AIで速く作るほど先に決めておく必要があります。