フォーム送信先がHTTPSとは？混在フォームのリスク・診断基準・修正方法

フォーム送信先がHTTPSとは

フォーム送信先がHTTPSとは、<form> の action 属性と、送信ボタン側で送信先を上書きする formaction 属性が、http:// ではなく HTTPS（または相対URL）になっている状態のことです。

<form action="https://www.city.example.lg.jp/search/" method="get">

ページ自体が HTTPS で配信されていても、<form action="http://..."> のように送信先が HTTP になっていると、入力された氏名・住所・電話番号・問い合わせ内容・検索語などは暗号化されずにネットワークを流れます。この状態を Chrome などのブラウザは「混在フォーム（mixed form）」と呼び、警告の対象にしています。

この診断項目は、トップページの HTML に含まれるフォームの送信先（action 属性と formaction 属性）に http:// が使われていないかを確認します。

action と formaction の関係

MDN によると、<form> の action は「フォーム送信を処理するURL」で、この値は <button>、<input type="submit">、<input type="image"> の formaction 属性で上書きできます。したがって、form タグの action が HTTPS でも、送信ボタンの formaction が HTTP なら実際の送信は平文になります。

action を省略した場合や相対URL（/search など）の場合は、ページ自身のURLを基準に解決されるため、HTTPS ページ上では HTTPS で送信されます。

method と送信内容

method の既定値は GET で、入力値はURLのクエリ文字列として付加されます。POST では本文として送られます。どちらも HTTP であれば平文で、経路上の第三者が読み取り・改ざんできます。GET の場合はさらにアクセスログやブラウザ履歴、Referer にも残ります。

フォーム送信先がHTTPでなぜ危険なのか（混在フォームとブラウザの警告）

Chrome の混在フォーム警告

Chromium ブログ（2020年8月「Protecting Google Chrome users from insecure forms」）は、HTTPS ページ上の HTTP 送信フォームを混在フォームとして扱い、次の対応を行う方針を公表しました。

当初は M86 で導入予定とされ、同記事の2020年10月7日付の追記で M87 への延期が告知されています。なお、ログインフォームではパスワードマネージャーは引き続き動作するとされています。住民から見ると、自治体サイトで送信のたびに警告が出ることになり、信頼性を大きく損ないます。

標準・要件での位置付け

OWASP ASVS 5.0.0 12.2.1（L1）は、外部向けHTTPサービスとの通信はすべてTLSを使い、非暗号化通信へフォールバックしないことを求めています。OWASP WSTG v4.2 では WSTG-CRYP-03（非暗号化チャネルで送信される機微情報のテスト）と WSTG-ATHN-01（暗号化チャネルでの認証情報送信のテスト）が、この問題を確認するテストです。弱点としては CWE-319（機密情報の平文送信）に当たります。

フォーム送信先についてよくある誤解

• 「ページに鍵マークが付いているから送信も安全」：鍵マークはページの取得経路を示すもので、送信先は別です。
• 「送信先サーバーが HTTP→HTTPS リダイレクトしているから大丈夫」：最初の送信リクエスト（入力値を含む）はすでに平文で送られています。リダイレクトでは保護できません。また POST は 301/302 で GET に変わり、入力が失われることもあります。
• 「検索フォームだけだから問題ない」：検索語には相談内容（DV、生活保護、病名など）が含まれることがあり、自治体サイトでは要配慮情報になり得ます。

ページ自体の HTTPS 化は「HTTPSで配信されている」、ログインフォームの送信先を同一オリジンに限定できているかは「認証情報の送信先をHTTPS・同一オリジンへ限定」の項目で別に確認します。このページは、すべてのフォームの送信先が HTTP でないかに絞って解説します。

フォーム送信先がHTTPSの診断基準（セキュリティAIチェッカー）

取得対象と方法

• 最終到達ページ（トップページ）の HTML 本文（最大2MB）を解析します。
• <form ...> 開始タグをすべて抽出し、action 属性の値が http:// で始まるもの（引用符あり・なし、値先頭の空白を許容）を数えます。
• あわせて HTML 全体から、<button> または <input> の formaction 属性が http:// で始まるものを数えます。
• 相対URL・action 省略・https:// は安全側として扱います（ページ自体の HTTPS 化は別項目 transport.https で評価）。

判定条件

• 根拠欄には「HTTP送信先: 件数/フォーム総数」と、該当があれば「HTTPのformaction: 件数」が表示されます。
• 重み5のため、1件の fail で総合スコアは大きく下がります。この項目に「△ 要確認（warn）」はありません。

自治体サイトでの判定例

自治体トップページでは「サイト内検索」の form がよく該当します。外部のサイト内検索サービスや、旧来の Google カスタム検索の設置コードが http:// のまま残っている例が典型です。

診断の限界

• JavaScript（fetch や XMLHttpRequest、form.action = ... の動的変更）による送信先は評価しません。
• トップページ以外のフォーム（問い合わせ、申請、アンケート）は対象外です。主要フォームのページは個別に診断してください。
• //example.jp/ のようなプロトコル相対URLはページのスキームを継承するため、HTTPS ページ上では安全として扱います。

フォーム送信先がHTTPだとどんなリスクがあるか

• 盗聴：公衆無線LANや侵害されたルーター上で、問い合わせ内容・氏名・連絡先・検索語が第三者に読まれます。
• 改ざん：応答側も HTTP のため、送信後に表示される結果ページを書き換えられ、偽の案内や偽の振込先、マルウェア配布サイトへの誘導を差し込まれる可能性があります。
• ブラウザ警告による業務影響：混在フォームとして警告が表示されると、住民が送信をためらい、問い合わせが電話に回るなど窓口負担が増えます。自動入力も無効化されます。
• 個人情報保護上の問題：個人情報の保護に関する法律に基づく安全管理措置の観点から、平文送信は説明が困難です。

フォーム送信先をHTTPSにする方法（HTML・CSP：Apache・nginx・IIS・Next.js）

1. 送信先を HTTPS に変える

<!-- 修正前 -->
<form action="http://search.example-cms.jp/city/" method="get">
<!-- 修正後（同一サイトなら相対URLでもよい） -->
<form action="https://search.example-cms.jp/city/" method="get">

送信先のサーバーが HTTPS に対応していない場合は、委託先に HTTPS 化を依頼するか、HTTPS 対応のサービスへ切り替えます。

2. 一括で洗い出す

# 公開ディレクトリ内の HTTP 送信先を検索
grep -rniE '(action|formaction)\s*=\s*["'\'']?\s*http://' /var/www/html --include=*.htm* --include=*.php

CMS の場合はテンプレート（ヘッダー・フッター部品）と、記事本文に貼り付けられた埋め込みコードの両方を確認します。

3. ブラウザ側の保険：CSP の form-action と upgrade-insecure-requests

Content-Security-Policy の form-action で送信先を HTTPS に限定できます。また upgrade-insecure-requests は、HTTP のサブリソース参照とフォーム送信（別オリジン宛てを含む）を自動的に HTTPS へ置き換えます。

form-action はまず Report-Only で影響を確認します。upgrade-insecure-requests は Report-Only ヘッダーでは無視される（W3C 仕様）ため、強制ヘッダーにだけ書きます。

Apache（.htaccess）

<IfModule mod_headers.c>
  Header always set Content-Security-Policy-Report-Only "form-action 'self' https:"
</IfModule>

nginx

add_header Content-Security-Policy-Report-Only "form-action 'self' https:" always;

IIS（web.config）

<system.webServer>
  <httpProtocol>
    <customHeaders>
      <add name="Content-Security-Policy-Report-Only" value="form-action 'self' https:" />
    </customHeaders>
  </httpProtocol>
</system.webServer>

Next.js（next.config.ts、確認後の強制ヘッダーの例）

const nextConfig = {
  async headers() {
    return [{ source: "/:path*", headers: [
      { key: "Content-Security-Policy", value: "form-action 'self' https:; upgrade-insecure-requests" },
    ] }];
  },
};
export default nextConfig;

Report-Only の違反は、report-to / report-uri を指定しない場合ブラウザの開発者ツールのコンソールでしか確認できません。問題がないことを確認してから Content-Security-Policy へ切り替え、upgrade-insecure-requests を加えます。既存の CSP がある場合は、ヘッダーを二重に送らず既存ポリシーにディレクティブを追記してください。CSP 全体の評価は「Content Security Policy」の項目で行います。

4. 設定後の確認方法

curl -s https://www.city.example.lg.jp/ | grep -ioE '<(form|button|input)[^>]*(action|formaction)[^>]*>'

Chrome でフォームに入力し、「このフォームは安全ではありません」の表示が出ないこと、開発者ツールの Network で送信リクエストが https:// であることを確認します。修正後はセキュリティAIチェッカーで再診断し、根拠欄の「HTTP送信先」が0件になっていることを確かめてください。

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

• form-action は送信後のリダイレクト先にも適用されるブラウザがあります。外部決済・外部認証へ遷移するフォームがある場合は、その遷移先も許可に含めてください。
• upgrade-insecure-requests は HTTPS 非対応の外部資産や送信先を利用できなくします。Report-Only では試せないため、事前に Content-Security-Policy-Report-Only: default-src https: で HTTP 参照を洗い出すか、テスト環境で確認します。
• 送信先を変える場合、受け側の CGI・PHP が HTTPS でも同じパスで動くこと、POST がリダイレクトで失われないことを確認します。

よくある質問（FAQ）

参考資料

• MDN <form> 要素（action / formaction / method）
• MDN <input type="password">（HTTPS で配信すべき旨の注意）
• Chromium Blog「Protecting Google Chrome users from insecure forms」
• Help Net Security「Chrome 86 will prominently warn about insecure forms on secure pages」
• OWASP ASVS 5.0.0 V12 Secure Communication
• W3C Upgrade Insecure Requests
• CWE-319

「フォーム送信先がHTTPS」と関連する診断項目

• HTTPSで配信されているcritical
• 認証情報の送信先をHTTPS・同一オリジンへ限定critical
• Content Security Policyhigh
• canonicalが安全なURLを指しているmedium
• パスワード欄のtype属性critical
• POSTフォームのCSRF対策兆候high
• パスワードマネージャーに適したautocompletelow
• パスワード欄への貼り付けを許可medium