ログイン不具合を直す途中で、「ログに残してはいけない情報」を先に消した話

今日は、開発中のLINE予約システムで認証まわりを見直した。

発端は「ログインできない」という単純な症状だった。Supabase Authを使ったGoogleログインとメール認証、ログイン後の保護ルートを順番に確認し、コールバック処理、環境変数、セッションの受け渡しを追っていった。

その途中で、認証確認処理のログに、障害解析には不要な値まで出る余地があることに気づいた。開発中は情報が多いほど安心に見えるが、本番では逆になる。ログインの成否を調べるために必要なのは処理の段階とエラー種別であり、利用者や認証に関係する値そのものではない。

そこで、不具合修正と並行して、まず機密になり得る情報をログへ残さない形に変更した。成功・失敗を追える最小限の記録だけに絞り、AIには修正候補とテスト観点を出させた。最終判断はコード差分と実行結果を見ながら行った。

変更後は、認証まわりのテスト63件、型チェック、ビルド、差分チェックを実行した。全体テストには2件の失敗が残ったが、修正前の状態でも再現する改行コード由来のものだったため、今回の変更による不具合とは分けて扱った。「全部成功」と雑にまとめず、今回直した範囲と既存課題を切り分けることも検証の一部だと思う。

今回の学びは、認証機能では「ログインできること」だけを完成条件にしないことだ。保護ルート、失敗時の戻り方、ログに残す情報、既存テストへの影響まで確認して、ようやく安全に公開へ進める。

Next.js・Supabaseを使った認証導入や、既存Webシステムの安全な改修でお困りの場合は、出品中のWeb・業務システム開発サービスからご相談ください。現状調査から実装、検証、公開前確認まで対応します。