認証情報の送信先をHTTPS・同一オリジンへ限定とは？form actionの危険な例・CSP form-actionでの対策

認証情報の送信先をHTTPS・同一オリジンへ限定とは

認証情報の送信先をHTTPS・同一オリジンへ限定とは、パスワード欄を含むログインフォームの action 属性（入力したIDとパスワードの送り先）を、HTTPSで、かつ表示中のページと同じオリジンにすることです。

ページ自体がHTTPSで表示されていても、action="http://..." であれば送信内容は暗号化されずにネットワークを流れます。また、送信先が自サイトとは別のオリジン（スキーム・ホスト・ポートの組）である場合、パスワードは別のサーバーに渡ります。正規の認証基盤であれば問題ありませんが、意図しない外部送信や改ざんの兆候である可能性もあります。

セキュリティAIチェッカーのこの項目は、パスワード欄を含むフォームの送信先が「HTTPS」であるか、さらに「同一オリジン」であるかを確認します。HTTP送信は即座に盗聴につながるため不合格、別オリジンへのHTTPS送信は正当なシングルサインオン（SSO）もあり得るため要確認として扱います。

form の action の解決ルール

• action が空、または省略された場合、送信先は現在のページのURLになります。ページがHTTPならHTTPで送信されます。
• 相対URL（/login）はページのURLを基準に解決されます。
• 送信ボタンの formaction 属性は、フォームの action を上書きします（MDN）。
• オリジンは「スキーム＋ホスト＋ポート」で決まります。https://www.city.example.lg.jp と https://shinsei.city.example.lg.jp は同じ組織のサイトでも別オリジンです。

なぜ認証情報の送信先を限定する必要があるのか

ブラウザの保護と限界

Chromeは2020年に、HTTPSページ上でHTTPへ送信するフォーム（mixed forms）について、入力時の警告表示、送信前の全画面警告、自動入力の無効化を導入すると発表しました（Chromium Blog。当初予定のChrome 86から87へ延期）。なお、ログインとパスワードの欄があるmixed formsでは、Chromeのパスワードマネージャーは引き続き動作するとされています。ただし利用者が警告を無視すれば送信されますし、HTTPページ上のフォームそのものは対象外です。送信先の安全はサイト側で担保する必要があります。

OWASP ASVS 5.0.0 V12.2.1（L1）は、外部向けHTTPサービスへの接続はすべてTLSを使い、非暗号化通信へフォールバックしないことを求めています。IPA「安全なウェブサイトの作り方」2.3も、パスワードでログインするページのHTTPS化を勧め、送信先URLだけでなく入力画面もhttps://にする必要があると説明しています。

別オリジン送信が正当な場合

• 自治体の統合認証基盤、電子申請サービス、図書館システムなど、別ホストで運用される認証サービスへ直接POSTする構成。
• 外部IdP（OpenID Connect等）を使う場合は、通常は認証画面そのものがIdP側にあり、自サイトのフォームからパスワードを外部へ直接送る構成は一般的ではありません。

別オリジンへの送信が設計どおりかは、外部からは判定できません。資産台帳や構成図と照合して確認します。

認証情報の送信先についてよくある誤解

• 「ページがHTTPSなら送信も暗号化される」：送信先URLのスキームで決まります。action に http:// が書かれていれば平文です。
• 「HSTSがあるから大丈夫」：HSTSは同じホスト（includeSubDomains ならサブドメインも）へのHTTP接続をHTTPSへ切り替えますが、HSTSを設定していない別ホストへのHTTP送信は守れません。

フォームの送信方法（GETかPOSTか）は「パスワードをPOSTで送信」、サイト全体のHTTPS化は「HTTPSで配信されている」、全ページへのHSTS付与は「HSTSを全HTTPS応答へ適用」で確認します。このページは「送信先のスキームとオリジン」に絞って解説します。

認証情報の送信先をHTTPS・同一オリジンへ限定の診断基準（セキュリティAIチェッカー）

取得対象

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

検出の手順

1. HTMLから <form ...> と、その後に最初に現れる </form> までを1組として抽出し、内部に type="password" の <input> を含むものをパスワードフォームとします（閉じタグのないフォーム、属性値に <・> を含むタグは対象外）。
2. 各フォームの action 属性（未指定は空文字）を、そのページの最終URLを基準に絶対URLへ解決します。
3. 解決結果を次のように分類します。

判定条件

根拠には該当件数のみを表示し、送信先URLそのものは表示しません。送信ボタンの formaction による上書きと、JavaScriptで送信先を変える処理は評価対象外です。

自治体サイトでの判定例

認証情報の送信先が不適切だとどんなリスクがあるか

• 盗聴によるパスワード窃取：公衆無線LANや経路上の機器で、平文のIDとパスワードがそのまま読まれます。WSTG-CRYP-03は、action にHTTPが指定された認証フォームを典型的な問題例として挙げています。
• 改ざん・中間者攻撃：HTTP通信は応答の書き換えも可能で、送信後の画面に偽のログイン画面やマルウェア配布ページを差し込まれるおそれがあります。
• 意図しない外部送信：CMSのテンプレート改ざんやXSSでフォームの action を書き換えられると、パスワードが攻撃者のサーバーへ送られます。送信先が同一オリジンに限定されていれば、こうした異常に気付きやすくなります。CSPの form-action ディレクティブを使うと、ブラウザ側で送信先を制限できます。
• 委託先の管理範囲外：別オリジンの送信先が契約終了したサービスや、ドメイン期限切れで第三者に取得されたホストを指している場合、認証情報が第三者に渡ります。

認証情報の送信先を限定する設定方法（HTML・Apache・nginx・IIS・Next.js）

1. action をHTTPSの同一オリジンへ固定する

<!-- 修正前 -->
<form action="http://www.example.lg.jp/login.php" method="post">

<!-- 修正後：相対パスで同一オリジンへ（ページはHTTPSで配信） -->
<form action="/login.php" method="post">

相対パスにしておけば、ページがHTTPSである限り送信先もHTTPSになります。そのうえで、サイト全体をHTTPSへリダイレクトし、HSTSを設定します（transport.https、crawl.hsts-coverage）。

2. CSPの form-action で送信先を制限する

# Apache (.htaccess)
<IfModule mod_headers.c>
  Header always set Content-Security-Policy "form-action 'self'; frame-ancestors 'self'; object-src 'none'; base-uri 'self'"
</IfModule>

# nginx
add_header Content-Security-Policy "form-action 'self'; frame-ancestors 'self'; object-src 'none'; base-uri 'self'" always;

<!-- IIS web.config -->
<system.webServer>
  <httpProtocol>
    <customHeaders>
      <add name="Content-Security-Policy" value="form-action 'self'; frame-ancestors 'self'" />
    </customHeaders>
  </httpProtocol>
</system.webServer>

// Next.js next.config.js
module.exports = {
  async headers() {
    return [{
      source: '/:path*',
      headers: [{ key: 'Content-Security-Policy', value: "form-action 'self'; frame-ancestors 'self'" }],
    }];
  },
};

正規の外部認証基盤へ送る場合は、form-action 'self' https://auth.example.lg.jp のように許可先を明示します。

3. 別オリジンの送信先を棚卸しする

1. 診断で△になったフォームの送信先ホストを洗い出します。
2. 資産台帳、契約、構成図と照合し、運用中の正規サービスかを確認します。
3. 不要になったフォームは削除し、正規の場合は送信先がHTTPSとHSTSを備えているか確認します。
4. 可能であれば、認証画面ごと認証基盤側へリンクで遷移させ、公式サイト上にパスワード欄を置かない構成にします。

修正後の確認方法

# フォームの送信先を確認
curl -s https://www.example.lg.jp/login/ | tr '\n' ' ' | grep -oiE '<form[^>]*>'

# CSPのform-actionを確認
curl -sI https://www.example.lg.jp/login/ | grep -i content-security-policy

ブラウザの開発者ツールでログインを実行し、送信リクエストのURLが https:// で始まり、想定したホストであることを確認します。修正後はセキュリティAIチェッカーで再診断し、この項目が○になることを確認します。

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

• CSPを新たに入れる場合、form-action 以外のディレクティブ（script-src など）を同時に厳しくすると、インラインスクリプトに依存したページが動かなくなります。最初は form-action と frame-ancestors など影響の小さいディレクティブから導入し、必要に応じて Content-Security-Policy-Report-Only で事前に確認してください。
• 設定例の object-src 'none' は <object>・<embed> によるPDF等の埋め込みを止めます。埋め込みを使うサイトでは外してください。
• アプリケーションやCMSが既にCSPを出力している場合、サーバー設定で別のCSPを足すと、既存の値が置き換わるか、ヘッダーが2本になって両方が同時に適用されます。既存のポリシーに form-action を追記する形にしてください。
• form-action はリダイレクト先にも適用されるブラウザがあります。ログイン後に外部の認証基盤へリダイレクトする構成では、その遷移先も許可リストに含めてください。
• .htaccess で Header を使うには mod_headers と AllowOverride FileInfo 相当の許可が必要です。IfModule で囲むことで、モジュールがない環境で500エラーになるのを防げます。
• POSTフォームのCSRF対策は「POSTフォームのCSRF対策兆候」で別途確認します。

よくある質問（FAQ）

参考資料

• OWASP ASVS 5.0.0 V12 Secure Communication（12.2.1）
• OWASP ASVS 5.0.0 V14 Data Protection（14.2.1）
• OWASP WSTG-CRYP-03
• MDN form element（action / formaction）
• MDN CSP: form-action
• Chromium Blog「Protecting Google Chrome users from insecure forms」
• CWE-319 Cleartext Transmission of Sensitive Information
• IPA「安全なウェブサイトの作り方」（PDF）

「認証情報の送信先をHTTPS・同一オリジンへ限定」と関連する診断項目

• パスワードをPOSTで送信critical
• HTTPSで配信されているcritical
• HSTSを全HTTPS応答へ適用high
• POSTフォームのCSRF対策兆候high
• フォーム送信先がHTTPScritical
• パスワード欄のtype属性critical
• パスワードマネージャーに適したautocompletelow
• パスワード欄への貼り付けを許可medium