references/auth-and-safety.md

認証と、ブラウザ操作の安全性

ログインを伴うページや、データを変更しうるページをチェックするときの規則。 ログインを伴うチェックでは、操作を始める前に必ずこのファイルを読む。

資格情報の取り扱い

利用者から渡された ID、パスワード、トークン、ワンタイムパスワードなどについて、以下を守る。

• レポートファイルに書かない。 「テストアカウントでログインして確認した」という 記述に留め、値そのものは書かない
• 会話に再出力しない。 確認のために復唱することもしない
• スクリーンショットに写さない。 ログインフォームに値を入力した状態は撮影しない。 ログイン画面自体をチェックする必要がある場合は、入力前の状態を撮影する
• browser_evaluate のコードに埋め込まない。 入力は browser_type などの 専用のツールで行う
• チェック終了後、ログアウトできる場合はログアウトする

環境の確認

チェックを始める前に、対象が本番環境かどうかを利用者に確認する。

• 本番環境の場合: 実データが表示され、他の利用者に影響する操作が発生しうる。 破壊的操作は原則として行わない。個人情報が画面に表示されている場合、 スクリーンショットを撮らないか、レポートに含めない
• テスト・ステージング環境の場合: 比較的自由に操作してよいが、それでも破壊的操作の 可否は確認する

本番アカウントではなく、チェック用に用意されたアカウントを使うことを推奨する。

破壊的操作

以下は、実行する前に必ず利用者に許可を求める。許可を求めずに実行してはならない。

• データの作成、変更、削除
• フォームの送信（問い合わせ、申し込み、注文、投稿）
• メール、通知、メッセージの送信
• 決済、課金、ポイントの消費
• 設定の変更（特に他の利用者に影響するもの）
• ファイルのアップロード、ダウンロード
• アカウントの状態を変える操作（退会、パスワード変更、権限変更）

許可を求めるときは、何をしようとしているか、なぜ必要かを具体的に伝える。

VIS-31（SC 3.3.4 エラー回避）の確認のため、この申し込みフォームを実際に送信して、
送信前に確認画面が出るか、送信後に取り消せるかを見たいです。
テストデータが1件作成されます。実行してよいですか。

許可が得られない場合は、その観点を「判定不能」として記録し、レポートの 「要追加確認」に理由とともに記載する。 推測で「問題なし」としてはならない。

送信せずに確認できること

破壊的操作の許可が得られない場合でも、以下は確認できる。

• 送信ボタンを押す前の段階でのバリデーション表示（不正な値を入れてフォーカスを外す）
• 確認画面へ進む導線があるか（ボタンのラベルが「確認する」か「送信する」か）
• 入力欄のラベル、説明、autocomplete、エラー表示の実装

これらで判定できた範囲を明示し、残りを「要追加確認」に回す。

操作の範囲

• 指定された対象の範囲を超えて操作しない。 外部サイトへのリンクを辿らない。 別ドメインへ遷移した場合は戻る
• 認証が必要なページでチェックしているとき、意図せずログアウトされる操作 （「ログアウト」リンクを押すなど）に注意する。フォーカス巡回の確認中に Enter を 押してしまわないよう、リンクやボタンでは Enter を押さずにフォーカス位置の記録に留める （操作の確認が必要な要素は、個別に選んで実行する）
• 意図しない遷移が起きた場合は、元の画面に戻ってから続行する。どこまで確認済みだったかを 見失わないよう、状態ごとの進捗を記録しておく

多要素認証

多要素認証がある場合、コードの入力は自動化できない。以下のいずれかを利用者に相談する。

• 利用者が手動でログインした状態のブラウザを使う（Playwright MCP の永続プロファイル）
• 多要素認証が無効なテストアカウントを使う
• 利用者にコードを都度伝えてもらう（この場合もコードをレポートに書かない）

なお、多要素認証の入力欄そのものもチェック対象になりうる（SPEC-03、SEM-05、VIS-29）。 コードの入力欄が1文字ずつ分割されていて貼り付けができない実装は、SPEC-03 の問題である。

個人情報

チェック中に実在の利用者の個人情報が表示された場合、以下を守る。

• スクリーンショットに含めない。含まざるを得ない場合は、その部分を避けて撮影する
• レポートに転記しない。要素を特定する必要がある場合は、セレクタや構造で示す
• 会話に出力しない