# 認証と、ブラウザ操作の安全性 ログインを伴うページや、データを変更しうるページをチェックするときの規則。 **ログインを伴うチェックでは、操作を始める前に必ずこのファイルを読む。** ## 資格情報の取り扱い 利用者から渡された 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 の問題である。 ## 個人情報 チェック中に実在の利用者の個人情報が表示された場合、以下を守る。 - スクリーンショットに含めない。含まざるを得ない場合は、その部分を避けて撮影する - レポートに転記しない。要素を特定する必要がある場合は、セレクタや構造で示す - 会話に出力しない