結論（フォーム・パスワード入力のセキュリティ）
フォーム・パスワード入力のセキュリティ診断では、パスワード欄が type="password" か、フォームの送信先がHTTPS・同一オリジンか、パスワードをPOSTで送っているか、機密情報をURLに載せていないか、POSTフォームにCSRF対策の兆候があるかを確かめます。最優先は、入力内容の漏えいに直結する最重要（critical）の5項目です。
フォーム・パスワード入力の診断項目一覧（9項目）
パスワード欄の扱い、送信先、CSRF対策、URLへの機密情報の混入を確認します。各項目名から、意味・診断基準・リスク・具体的な対策を解説したページへ移動できます。
| No. | 診断項目 | 重大度 | 概要 |
|---|---|---|---|
| 58 | パスワード欄のtype属性 | critical | パスワード欄のtype属性は input type="password" にするのが必須です。 |
| 59 | フォーム送信先がHTTPS | critical | フォーム送信先がHTTPSでないと、ページがHTTPSでも入力内容は平文で送られます。 |
| 60 | POSTフォームのCSRF対策兆候 | high | POSTフォームのCSRF対策兆候は、フォームのHTMLにCSRFトークンらしき項目があるかで確認します。 |
| 104 | パスワードマネージャーに適したautocomplete | low | パスワードマネージャーに適したautocompleteとは、パスワード欄にcurrent-passwordまたはnew-passwordを指定することです。 |
| 105 | パスワード欄への貼り付けを許可 | medium | パスワード欄への貼り付けを許可することは、OWASP ASVS・NIST・WCAG 2.2がそろって求める要件です。 |
| 106 | 64文字以上のパスワードをHTMLで妨げない | medium | 64文字以上のパスワードをHTMLで妨げないとは、パスワード欄に64未満のmaxlengthを付けないことです。 |
| 107 | パスワードをPOSTで送信 | critical | パスワードをPOSTで送信するには、フォームにmethod="post"を明示します。 |
| 108 | 認証情報の送信先をHTTPS・同一オリジンへ限定 | critical | 認証情報の送信先をHTTPS・同一オリジンへ限定するとは、ログインフォームのactionをhttp://や外部ホストにしないことです。 |
| 109 | 機密情報をURL・GETフォームへ含めない | critical | 機密情報をURL・GETフォームへ含めないとは、パスワード・トークン・APIキー・セッションIDをクエリ文字列に載せないことです。 |
フォーム・パスワード入力のセキュリティ診断とは
フォーム・パスワード入力のセキュリティ診断は、利用者が入力した氏名・住所・問い合わせ内容・パスワードなどが、途中で盗み見られたり、意図しない場所に記録されたりしない作りになっているかを確かめるものです。セキュリティ診断127項目のうち、フォームとパスワード欄に関する9項目がこの分類に入ります。
フォームの安全性は、HTMLのわずかな書き方で大きく変わります。たとえば form 要素の method を指定しないと既定でGETになり、パスワードが ?password=... の形でURLに付いて送られます。ページ自体がHTTPSでも、action が http:// なら入力内容は暗号化されずに流れます。パスワード欄を type="text" のままにすれば、のぞき見や画面共有で漏れるうえ、パスワードマネージャーも働きません。
一方で、「安全そうに見えて逆効果」な設定もこの分類の対象です。パスワード欄への貼り付け禁止や、短すぎる maxlength、autocomplete="off" は、利用者が長く一意なパスワードを使うことを妨げます。OWASP ASVS 5.0.0やNIST SP 800-63Bは、パスワードマネージャーや貼り付けの利用を認めるよう求めています。
この分類の診断は、取得したHTMLのフォームと入力欄を外形的に調べるものです。サーバー側でCSRFトークンを検証しているか、サーバーがパスワードを切り詰めていないかといった内部の実装までは外から分からないため、判定結果をきっかけに実装の確認を進めることが大切です。
9項目の全体像（4つのグループ）
この分類の9項目は、大きく4つのグループに分けて考えると整理しやすくなります。
| グループ | 診断項目 | 確認する内容 |
|---|---|---|
| 送信先の安全性 | 「フォーム送信先がHTTPS」、「認証情報の送信先をHTTPS・同一オリジンへ限定」 | action と formaction がHTTPSか、パスワードを含むフォームの送信先が表示中のページと同じオリジンか |
| 送信方法とURL | 「パスワードをPOSTで送信」、「機密情報をURL・GETフォームへ含めない」 | パスワードフォームが method="post" か、パスワード・トークン・APIキー・セッションIDなどがURLのクエリやGETフォームに載っていないか |
| パスワード欄の書き方 | 「パスワード欄のtype属性」、「パスワードマネージャーに適したautocomplete」、「パスワード欄への貼り付けを許可」、「64文字以上のパスワードをHTMLで妨げない」 | type="password" で伏せ字にしているか、current-password／new-password の指定、貼り付けの妨害がないか、64未満の maxlength がないか |
| リクエスト偽造への備え | 「POSTフォームのCSRF対策兆候」 | POSTフォームに csrf_token・_wpnonce・authenticity_token のようなトークンらしき項目があるか |
送信先と送信方法のグループは「入力内容がどこを通ってどこに残るか」、パスワード欄のグループは「利用者が強いパスワードを無理なく使えるか」、CSRFは「本人の意図しない送信を受け付けないか」という観点で見ると、それぞれの項目の役割が分かりやすくなります。
優先して確認すべき項目
重大度が「最重要（critical）」の5項目は、問題があると入力内容やパスワードがそのまま漏えいするおそれがあるため、最初に確認します。
- パスワード欄のtype属性：パスワード欄は必ず type="password" にします。type="text" のままだと、のぞき見、入力履歴への平文保存、パスワードマネージャーの不作動による弱いパスワードの誘発が起きます。目のアイコンで一時的に表示する切替機能は認められています。
- フォーム送信先がHTTPS：form の action と、送信ボタン側で送信先を上書きする formaction の両方を確認します。action がHTTPSでも formaction がHTTPなら、実際の送信は平文になります。
- パスワードをPOSTで送信：method 未指定のログインフォームは、パスワードをURLに付けてGETで送ります。URLはブラウザ履歴やアクセスログに残るため、HTTPSでも防げない漏えい経路になります。
- 認証情報の送信先をHTTPS・同一オリジンへ限定：パスワード欄を含むフォームの送信先にHTTPがあれば不合格です。別オリジンへのHTTPS送信は、正規の統合認証基盤や電子申請サービスの場合もあるため要確認として扱います。
- 機密情報をURL・GETフォームへ含めない：password、access_token、api_key、phpsessid、cvv などの名前がURLのクエリやGETフォームの項目にあれば不合格です。診断では値を収集・表示せず、名前との完全一致だけで検出します。
次に「重要（high）」の「POSTフォームのCSRF対策兆候」を確認します。CSRFは、ログイン中の利用者に悪意あるページから勝手にリクエストを送らせる攻撃です。外からはサーバー側の検証まで分からないため、トークンが見つからなくても△（要確認）とし、独自名のトークンやFetch Metadata・Origin検証などで守っている場合もあります。
「中（medium）」の貼り付け許可と64文字以上の入力許可、「低（low）」のautocompleteの指定は、パスワードの強さと使いやすさに関わる項目です。いずれもHTMLの修正で直せることが多く、基本の送信設定を整えた後にまとめて対応するのが効率的です。
直すときの進め方と注意点
フォームの修正は、HTMLだけを直すとサーバー側の処理と食い違い、ログインできなくなることがあります。次の点に注意して進めます。
- 送信方法はHTMLとサーバーを同時に変える：method="post" に変えるときは、サーバー側がGETの値だけを読んでいないかを確認し、認証処理はPOSTだけを受け付けるようにします。JavaScriptの fetch で送っている場合も、読み込み失敗時などにブラウザの既定動作で送信されるため、HTML側に method="post" を明示します。
- 過去にURLへ載っていた情報は漏えい済みとみなす：GETでパスワードを送っていた場合は、Webサーバー・WAF・CDN・ログ集約基盤などのログを削除またはマスキングし、利用者にパスワード変更を依頼します。URLに載せていたAPIキーやトークンは、再発行と旧キーの無効化を行います。
- 送信先はリダイレクトではなく、送信先そのものを直す：HTTPの送信先がHTTPSへリダイレクトしていても、入力値を含む最初の送信はすでに平文です。action と formaction をHTTPSか相対URLに書き換え、CSPの form-action で送信先を制限すると保険になります。form-action はまずReport-Onlyで確認します。
- パスワード欄は「妨げない」方向に直す：onpaste="return false" などの貼り付け拒否を削除し、maxlength は64文字以上を受け入れる値にします。上限を設けるなら64文字を大きく上回る値とし、超過時は切り詰めずにエラーにします。HTMLの制限を外しても、サーバー側で切り詰めていれば同じ問題が残るため、64文字以上で登録とログインを実際に試します。
- CSRFはトークンを中心に多層で守る：推測できないトークンをhidden項目で埋め込み、サーバー側で照合します。SameSite Cookie やFetch Metadataは多層防御として有効ですが、SameSite=Lax だけでは不十分な場合があります。
自治体・公共機関のサイトで特に注意すること
自治体や公共機関のサイトでは、トップページにログイン欄がなく、フォームもGETのサイト内検索が中心のため、この分類の多くの項目は「対象外」になるのが通常です。ただし、それで安心せず、入力を受け付けるページを個別に確認することが大切です。よくある注意点として、次のようなものがあります。
- 職員ログイン、電子申請の入口、図書館の利用者ログイン、問い合わせ・申請・予約フォームは、そのページのURLを直接診断しないと確認できない。
- 検索フォームの検索語にも、相談内容に関わる要配慮情報が含まれることがある。GETで送る場合は入力値がURLに付き、アクセスログやブラウザ履歴に残るため、送信先は必ずHTTPSにする。
- 外部の統合認証基盤や電子申請サービスへ直接送信するフォームは、資産台帳・契約・構成図と照合して正規の送信先かを確かめ、送信先がHTTPSとHSTSを備えているかも確認する。
- 図書館の利用者番号と4桁の暗証番号のように、短い暗証番号を単独の認証要素として使う設計は、パスワード強度の観点から見直す対象になる。
入力を受け付けるページの一覧と、それぞれの送信先・送信方法を台帳にまとめ、システム更新や委託先の変更のたびに確認すると、こうした不備を防ぎやすくなります。
よくある質問（FAQ）
フォーム・パスワード入力のセキュリティ診断項目は、どの順番で直せばよいですか？
まず最重要の5項目、つまりパスワード欄のtype属性、フォーム送信先のHTTPS化、パスワードのPOST送信、認証情報の送信先の限定、機密情報をURLに含めないことを確認します。次に重要（high）のCSRF対策、最後にパスワード欄への貼り付け許可、64文字以上の入力許可、autocompleteの指定といった使いやすさに関わる項目を整えます。
フォーム・パスワード入力のセキュリティで、ページがHTTPSなら送信も安全ですか？
安全とは限りません。鍵マークはページの取得経路を示すもので、送信の暗号化は送信先URLで決まります。action や formaction が http:// なら入力内容は平文で送られ、送信先のHTTPSへのリダイレクトでも最初の送信は保護できません。
パスワード欄への貼り付け禁止やautocomplete="off"は、フォーム・パスワード入力のセキュリティを高めますか？
高めません。貼り付け禁止はパスワードマネージャーが生成した長く一意なパスワードを使えなくし、弱いパスワードの使い回しを招きます。autocomplete="off" も多くの現代のブラウザがログイン欄では無視します。ログイン欄には current-password、登録・変更欄には new-password を指定します。
自治体のトップページを診断すると、フォーム・パスワード入力の項目が「対象外」になるのはなぜですか？
多くの自治体公式サイトのトップページにはログイン欄がなく、フォームもGETのサイト内検索が中心だからです。職員ログイン、電子申請、図書館の利用者ログイン、問い合わせ・申請フォームなどは、そのページのURLを個別に診断してください。なお機密情報をURLに含めない項目は対象外にならず、常に判定されます。
フォーム・パスワード入力のセキュリティ9項目はまとめて確認できますか？
セキュリティAIチェッカーにURLを入力すると、この9項目を含む127項目を公開情報から自動で診断し、項目ごとの判定と改善の優先順位を表示します。