パスワード欄への貼り付けを許可とは？貼り付け禁止の弊害・標準の要求・修正方法

パスワード欄への貼り付けを許可とは

パスワード欄への貼り付けを許可とは、ログイン画面や会員登録画面のパスワード欄で「貼り付け（Ctrl+V）」を妨げないことです。実際のサイトでは、onpaste="return false" という属性や、JavaScriptで paste イベントを拒否する処理によって、貼り付けを禁止している実装が見られます。

貼り付け禁止は一見すると安全側の対策に見えます。しかし実際には、利用者がパスワードマネージャーで生成した長く一意なパスワードを使えなくなり、短く覚えやすいパスワードの使い回しや、紙へのメモを誘発します。

国際的な標準はそろって「貼り付けを妨げない」ことを求めています。セキュリティAIチェッカーのこの項目は、診断AIが取得したHTML内に、パスワード欄への貼り付けを拒否する記述があるかを確認します。

貼り付け禁止の典型的な実装パターン

<!-- 典型例1：インライン属性で拒否 -->
<input type="password" name="pw" onpaste="return false;">

<!-- 典型例2：スクリプトで拒否 -->
<script>
document.getElementById('password').addEventListener('paste', function (e) {
  e.preventDefault();
  alert('パスワードは貼り付けできません');
});
</script>

確認用の「パスワード（再入力）」欄だけを貼り付け禁止にする例も多く見られます。しかし、パスワードマネージャーの生成値を確認欄に入力できなくなるため、同じく問題です。

なぜパスワードの貼り付けを許可すべきなのか（標準の要求）

主要な標準・指針の立場

ASVSのL1は最低限の水準であり、公開サービス全般が対象です。WCAG 2.2の観点では、記憶や転記が難しい利用者にとって、貼り付けは認証の前提となる支援機能です。

パスワードの貼り付け禁止についてよくある誤解

• 「貼り付け禁止はキーロガーやクリップボード窃取の対策になる」：端末がマルウェアに感染していれば、キー入力も画面も盗まれます。貼り付け禁止で防げるリスクは小さく、弱いパスワードを招く不利益のほうが大きいというのが標準の立場です。
• 「確認欄なら禁止してよい」：確認欄は入力ミス防止のためにありますが、マネージャー利用者にとっては二重入力の障害になります。表示切替（目のアイコン）で確認させる方法が推奨されます。
• 「autocomplete=offにすればより安全」：主要ブラウザはログイン欄の autocomplete=off を無視して保存を提案することが多く、効果は限定的です。用途に応じて current-password／new-password を指定するほうが適切です。これは「パスワードマネージャーに適したautocomplete」で確認します。

なお、パスワード欄の文字数上限は「64文字以上のパスワードをHTMLで妨げない」、入力欄が伏せ字になっているかは「パスワード欄のtype属性」の各項目で確認します。このページは「貼り付けを妨げないか」に絞って解説します。

パスワード欄への貼り付けを許可の診断基準（セキュリティAIチェッカー）

取得対象

外部診断強化モジュールが、トップページと、Ver2巡回で見つかった同一オリジンの追加ページ（ログイン・管理・アカウント系URLを優先）から最大2ページ、合計最大3ページのHTMLを使います。追加リクエストはGETのみで、JavaScriptは実行しません。

検出の手順

1. 各ページのHTMLから <input ...> タグを抽出し、type 属性が password のものをパスワード欄とします。
2. パスワード欄の onpaste 属性値に return false または preventDefault が含まれるものを「インラインでの貼り付け拒否」とします。
3. ページ全体のHTML（インラインスクリプトを含む）で preventDefault( を探します。その位置を起点に、直前およそ400字以内に paste／clipboard の語があり、かつ、その語の前およそ900字以内または preventDefault( の後ろおよそ900字以内に password／passwd／pwd の語がある記述を「スクリプトによる貼り付け拒否の兆候」とします（いずれも大文字小文字を区別しません）。

判定条件

スコアは「Σ(重み×係数)÷Σ(適用項目の重み)×100」で、係数はpass=1.00、warn=0.45、fail=0です。

×ではなく△にとどめる理由は、外部ファイルのJavaScriptやフレームワークのイベント処理は取得HTMLだけでは完全に追えず、近接語の一致が別の処理（例：検索欄の貼り付け整形）を誤って拾う可能性があるためです。逆に、外部JSで貼り付けを禁止している場合は検出できず、○になることがあります。

自治体サイトでの判定例

パスワードの貼り付けを禁止するとどんなリスクがあるか

• 弱いパスワードと使い回し：長いランダムなパスワードを手入力するのは現実的でないため、利用者は短く覚えやすいパスワードを選び、他サービスと使い回しがちになります。他サービスから漏えいしたID・パスワードの組み合わせを試すパスワードリスト攻撃（クレデンシャルスタッフィング）の成功率が上がります。
• アクセシビリティの阻害：認知・記憶・運動機能に制約のある利用者が、マネージャーや貼り付けなしでは認証できなくなり、住民向けサービスの利用機会を奪います。WCAG 2.2の3.3.8に抵触し得ます。
• フィッシング耐性の低下：パスワードマネージャーは登録したドメインでしか自動入力しないため、偽サイトに気付くきっかけになります。マネージャーを使えない設計は、この防御を手放すことになります。

貼り付け禁止そのものが直接の侵入経路になるわけではないため重大度はmediumですが、他の認証対策の効果を下げる設計上の問題です。

パスワード欄の貼り付けを許可する修正方法（HTML・CMS・Next.js）

1. HTMLとJavaScriptから拒否処理を削除する

<!-- 修正後：貼り付け拒否なし、用途を明示 -->
<label for="login-password">パスワード</label>
<input type="password" id="login-password" name="password"
       autocomplete="current-password" required>

<!-- 新規登録・変更画面 -->
<input type="password" id="new-password" name="new_password"
       autocomplete="new-password" minlength="15" required>

拒否処理を探すには、テンプレートとJSを次のように検索します。

grep -rniE "onpaste|oncopy|oncut" ./htdocs ./templates
grep -rniE "addEventListener\(\s*['\"](paste|copy|cut)['\"]" ./htdocs ./src
grep -rniE "on\(\s*['\"]paste" ./htdocs ./src   # jQueryの場合

2. 確認欄の代わりに「表示切替」を用意する

確認欄を廃止し、パスワードを一時的に表示するボタンで入力ミスを防ぐ方法があります。ASVS V6.2.6も、マスク入力を基本としつつ一時表示の機能を認めています。

<input type="password" id="pw" autocomplete="new-password">
<button type="button" aria-controls="pw" aria-pressed="false"
  onclick="const f=document.getElementById('pw');
           const show=f.type==='password';
           f.type=show?'text':'password';
           this.setAttribute('aria-pressed',String(show));">
  パスワードを表示
</button>

CSPでインラインイベントを禁止している場合は、同じ処理を外部JSの addEventListener で実装してください。

3. CMS・パッケージ製品の場合

• 電子申請システムや図書館システムなどのパッケージ製品で拒否処理が組み込まれている場合は、ベンダーに設定変更または改修を依頼します。調達仕様書に「ASVS V6.2.7準拠（貼り付け・パスワードマネージャーを妨げない）」を明記すると、次回更新時の要件として扱えます。
• WordPress等でプラグインが貼り付けを禁止している場合は、プラグインの設定を確認し、不要なら無効化します。

4. Next.js（React）の場合

// 悪い例：onPasteで拒否
<input type="password" onPaste={(e) => e.preventDefault()} />

// 良い例
<input type="password" name="password" autoComplete="current-password" />

修正後の確認方法

1. ブラウザでログイン画面を開き、テキストをコピーしてパスワード欄に貼り付けられるか確認します。
2. 主要なパスワードマネージャー（ブラウザ内蔵、外部製品）で保存・自動入力ができるか確認します。
3. HTMLを取得して拒否記述が残っていないか確認します。

curl -s https://www.example.lg.jp/login/ | grep -niE "onpaste|preventDefault"

修正後は、セキュリティAIチェッカーで再診断し、この項目が○になることを確認します。

サイトを壊さないための注意点

• 貼り付け拒否と同じ関数内で入力チェックや送信処理をしている場合があります。イベントハンドラーを丸ごと削除する前に、拒否部分だけを取り除けるか確認してください。
• 貼り付けを許可すると、前後に空白を含む値が入ることがあります。NIST SP 800-63B-4は前後の空白除去などの限定的な許容を認めていますが、検証の挙動を変える場合は既存パスワードでのログイン可否を事前に試験してください。
• 外部JSで拒否している場合は本診断で検出されないことがあるため、実機での貼り付け確認を必ず行ってください。

よくある質問（FAQ）

参考資料

• OWASP ASVS 5.0.0 V6 Authentication（V6.2.6〜V6.2.9）
• NIST SP 800-63B-4 Authentication and Authenticator Management（3.1.1.2 Password Verifiers）
• W3C Understanding SC 3.3.8 Accessible Authentication (Minimum)
• OWASP WSTG-ATHN-07 Weak Authentication Methods
• IPA「安全なウェブサイトの作り方」

「パスワード欄への貼り付けを許可」と関連する診断項目

• パスワードマネージャーに適したautocompletelow
• 64文字以上のパスワードをHTMLで妨げないmedium
• パスワード欄のtype属性critical
• フォーム送信先がHTTPScritical
• POSTフォームのCSRF対策兆候high
• パスワードをPOSTで送信critical
• 認証情報の送信先をHTTPS・同一オリジンへ限定critical
• 機密情報をURL・GETフォームへ含めないcritical