HN 日本語サマリー

← 一覧へ戻る
Web開発

小規模ビジネスウェブサイトのセキュリティヘッダー:7つの基準のうち49.7%がNoneを満たさず

Security headers on 4,688 small-business websites: 49.7% met none of 7 criteria (rackcrunch.com)

7 pointsby terrybyte1 コメント

要約

2026年に実施された米国のディレクトリ掲載小規模ビジネスウェブサイト7,040件を対象とした調査によると、セキュリティヘッダーの導入状況は低いことが明らかになりました。調査対象の4,688サイトのうち、49.7%が7つの主要なセキュリティヘッダー基準のいずれも満たしていませんでした。特に、Content-Security-Policy (CSP) の導入率は21.2%でしたが、その多くはスクリプト保護に有効でない設定でした。この結果は、多くの小規模ビジネスが基本的なウェブセキュリティ対策を怠っている現状を示唆しています。

全文翻訳

ディレクトリ掲載米国内小規模ビジネスウェブサイトのセキュリティヘッダー2026年の7,040件のディレクトリ掲載米国内小規模ビジネスウェブサイトの調査:どのセキュリティヘッダーを送信し、どのヘッダーを間違っているか。RACKCRUNCHチーム著 · スキャン 2026-09-24 · PDF(security-headers-study-2026.pdf、400 KB、SHA-256 c8fa6a281799ff1f86c79b62f5ba5b52535a4ca9d9b6bdce69d61f5bfaeb6d91)としても利用可能。なぜ調査したかRACKCRUNCHは無料のセキュリティヘッダーチェックを提供しています。URLを入力すると、1回の要求を行い、どのレスポンスヘッダーが設定されているか、どのヘッダーが悪く設定されているか、どのヘッダーが欠落しているかを教えてくれます。一度に1つのサイトをチェックするだけでは、より大きな全体像について知りたくなりました。私たちは銀行や大手テクノロジー企業を対象としたわけではありません。配管工、法律事務所、自動車販売店、ピザ屋など、専任のウェブセキュリティ担当者がいない可能性のあるビジネスを対象としました。私たちはそのようなビジネスのリストを必要としましたが、きれいなものはありませんでした。そこで、私たちが最も近いものとして見つけたものを使用しました:人間が編集したDMOZの後継である公開Curlieウェブディレクトリです。2026-02-02のスナップショットに基づき、その米国のローカル「ビジネスと経済」カテゴリから7,040件のディレクトリ行をランダムに抽出しました。これらは7,022のユニークな初期登録可能ドメインを表します。これをSMB指向のディレクトリサンプルと考えてください。私たちはこれらのビジネスの規模をチェックしませんでした。いくつかは「小規模」よりも大きいでしょうし、ディレクトリはリストに載るほど確立されたビジネスに偏っています。このレポートが「サイト」と言う場合、それは米国のすべての小規模ビジネスではなく、これらのディレクトリ掲載サイトを意味します。2026-09-24に、サンプリングされた各URLに対して2回のHTTPS要求チェーンスキャンを実行し、最大3回のリダイレクトを追跡しました。報告されたすべての推定値は2回目のスキャンからのものです。私たちはレスポンスヘッダーを読み、ページ自体は読みませんでした。私たちは低い採用率を予想していました。それがほぼ得られたものです。驚きは、その低さから、そして私たちが分解しなければならなかった1つの数字から来ました。サイトが送信するヘッダー7,040件のサンプリング行のうち5,642件が、使用可能なHTTPSレスポンスを提供しました。そのうち4,701件はHTTP-200レスポンスであり、それらは4,688のユニークな最終登録可能ドメインから来ました。それらの4,688ドメインが私たちの主要なベース(データファイルでは「dedup-200」と呼ばれます)です:2回目のスキャンからの、最終登録可能ドメインごとの1つのHTTP-200レスポンス。このレポートのすべての数値は、特に断りがない限り、そのベースに基づいています。1私たちは最も単純な質問から始めました:7つの調査定義の明示的なヘッダー基準のうち、各サイトが満たしているのはどれか?これらは私たちのルーブリックの下での基準であり、セキュリティグレードではありません。サイトは合理的にそれらのいくつかを省略することができます。3つについては最初に説明が必要です。Referrer-Policyの欠落はブラウザのセキュアデフォルト値を取得するため、失敗とはみなしません。ポイントは、サイトが自身でセキュアな値を設定した場合にのみ与えられます。Permissions-Policyはまだ実験的であり、ブラウザ間でのサポートが均一ではありません。私たちの基準は明示的な宣言を数え、得られた保護を数えるわけではありません。Cross-Origin-Opener-Policyはコンテキストに依存します。ポップアップを開くサイトやクロスオリジンウィンドウを処理するサイトにとって最も重要であり、サインインや支払いフローを壊す可能性があります。私たちのルーブリックにおける明示的な基準は、どれも普遍的ではありませんでした。HSTSは最も一般的に観察されたヘッダーで、サイトの43.8%に存在していました。私たちの7項目のルーブリックで最も一般的に満たされた基準はX-Content-Type-Options: nosniffで、39.7%でした。私たちのより強力なHSTS基準(少なくとも1年間+ includeSubDomains)を満たしたのはわずか12.3%でした。私たちはそれを調査定義の強力なHSTSと呼び、最終レスポンスホストのみで測定されます。サイトがwwwにリダイレクトする場合、そこでのincludeSubDomainsはwww下のホストをカバーし、ベアドメインやshopのような兄弟ホストはカバーしません。578件の強力なHSTS合格のうち、260件(45.0%)はwww最終ホストから、316件はベアドメインから、2件は別のサブドメインから来ました。したがって、強力なHSTS合格のほぼ半分では、観測されたポリシーはwwwホスト上にあり、ベアドメインのカバレッジを確立していません。31.2%は、私たちのパーサーの下で認識された制限的な値を持つクリックジャッキングヘッダーを送信します。8.0%は、明示的な非ワイルドカードPermissions-Policy宣言を送信し、1.1%は、認識された非デフォルトのCross-Origin-Opener-Policy値を送信します。86.6%のサイトはReferrer-Policyをまったく送信しません。上記のように、それはサウンドよりも悪いことではありません。ヘッダーが欠落している場合、最新のブラウザはstrict-origin-when-cross-originにフォールバックします。これは賢明なデフォルトです。より懸念されるケースは、明示的な弱いレガシー値です。そして、5サイトに1つが何かを漏らしています。20.5% [19.3-21.7]のサイトが、私たちのバージョン-トークンルールに一致しました:Server、X-Powered-By、X-AspNet-Version、またはX-AspNetMvc-Versionのいずれかに数字が含まれている場合。例えば、Apache 2.4.x、Microsoft-IIS/10.0、またはnginx 1.xです。27サイトでは、唯一の漏洩はASP.NETバージョンヘッダーでした。これはバージョンをターゲットにした偵察に役立つ可能性がありますが、低深刻度の発見です:バージョン番号を隠しても何も修正されません。ここに主要なベースの完全な表があります。区間は、フレームバイアス、パーサーの誤分類、CDNの変動、または選択的なプラットフォームの帰属ではなく、指定されたサンプルモデルの下でのサンプリング不確実性を定量化します。コントロール(ユニークHTTP-200ドメイン、n=4,688)サイトシェア95% CI HSTS存在 2,053 43.8% 42.4-45.2 強力なHSTS:少なくとも1年+ includeSubDomains(最終ホスト) 578 12.3% 11.4-13.3 1年未満のHSTS 665 14.2% 13.2-15.2 CSP強制(任意のポリシー) 992 21.2% 20.0-22.4 CSPレポートのみ 37 0.8% 0.6-1.1 CSPがスクリプトを制限 186 4.0% 3.4-4.6 ヘッダーのみのスクリプト-CSPルールをパス 8 0.17% 0.1-0.3 クリックジャッキング保護(認識された制限値) 1,463 31.2% 29.9-32.5 無効な値を持つクリックジャッキングヘッダー 15 0.3% 0.2-0.5 X-Content-Type-Options: nosniff 1,861 39.7% 38.3-41.1 Referrer-Policy セキュア値設定 373 8.0% 7.2-8.8 Referrer-Policy 弱い(レガシー値) 252 5.4% 4.8-6.1 Referrer-Policy 無効(認識されない値) 1 0.02% 0.0-0.1 Referrer-Policy 欠落(ブラウザデフォルト適用) 4,062 86.6% - 明示的な非ワイルドカード Permissions-Policy宣言 374 8.0% 7.2-8.8 Permissions-Policy ワイルドカードのみ 10 0.2% 0.1-0.4 COOP same-origin 35 0.7% 0.5-1.0 COOP same-origin-allow-popups 15 0.3% 0.2-0.5 COOP noopener-allow-popups または restrict-properties 0 0.0% 0.0-0.1 認識された非デフォルトCOOP値(上記いずれか) 50 1.1% 0.8-1.4 COOP no-op (unsafe-none) 19 0.4% 0.3-0.6 COOP 不正形式 4 0.09% 0.0-0.2 バージョン-トークン開示 960 20.5% 19.3-21.7 1つの無効なReferrer-Policyは、「Referrer-Policy: yes」を送信するサイトです。7つの基準を組み合わせると、見出しの数字が得られます。HTTP-200を返したユニークな最終登録可能ドメインのうち、49.7%が7つの調査定義の明示的なヘッダー基準のいずれも満たしていませんでした [95% CI 48.3-51.2]、つまり4,688件中2,331件でした。2これは採用率の測定値であり、安全でないウェブサイトの割合の推定値ではありません。エラーページやボットチャレンジページを含む、すべての使用可能なレスポンスに対する同じ測定値は、最後に示す感度分析にあります。そのようなレスポンスは、サイトの通常のホームページのヘッダーではなく、CDN、WAF、ホスティングプラットフォーム、またはアプリケーションエラーページの構成を反映している可能性があるため、それらは主要なベースではありません。崩壊したCSPの数字最初のドラフトでは、CSPの結果はほぼまともに見えました。約6サイトに1つが「合格」しました。それは高すぎると感じられました。そのため、改訂された分析でCSPのカウントをやめ、それを読み取ることにしました。ルーブリックに記載されているCSPレベル3の文書化されたサブセットを実装するパーサーを使用しました。約5サイトに1つ、21.2% [20.0-22.4]が強制CSPを送信しています。これは問題ないように聞こえますが、ポリシーの内容を見るとそうではありません。ほとんどはフレームルール(frame-ancestors、これはクリックジャッキング対策であり、スクリプト対策ではありません)またはupgrade-insecure-requestsです。最も一般的な3つの正確なポリシーは、frame-ancestors 'self'(170サイト)、Shopifyプラットフォームのデフォルトであるblock-all-mixed-content; frame-ancestors 'none'; upgrade-insecure-requests;(167)、およびベアのupgrade-insecure-requests(130)でした。これらを合わせると、強制Content-Security-Policyを送信した992サイトの47.1%を占めます。3つのうち、スクリプトディレクティブを持つものはありません。3CSPは、インジェクションされたスクリプトに対する重要な防御策です。ここでは、ポリシーが何によって分類されるかを示します。