セキュリティ
はじめに
多くの人々の生活のますます多くの部分がオンラインに移行するにつれて、個人データも同様にオンライン化されており、ウェブセキュリティはかつてないほど重要になっています。日常的に使用する多くのシステムは、データを盗もうとしたり混乱を引き起こそうとする攻撃者にとって依然として魅力的なターゲットとなっています。今年もまた、現代の脅威の規模と複雑さが示されました。DDoS攻撃の規模と頻度は増加し続けており、記録された最大の攻撃は11月に31.4 Tbpsに達しました。サプライチェーンの脆弱性は前例のない規模に拡大し、Shai-Hulud 2.0攻撃は1,000以上のnpmパッケージを侵害し、27,000以上のGitHubリポジトリに感染したと報告されています。また、React2Shellとして知られるReactの重大な脆弱性により、開発者はアプリケーションの迅速な更新に追われました。
本チャプターでは、ウェブを保護することを目的とした仕組みと、様々な理由によりそれらが機能しない場合について分析します。Transport Layer Security（TLS）やサードパーティコンテンツインクルージョンに対する保護などのウェブセキュリティの核心要素を探ります。これらのセキュリティ対策の採用がどのように進化しているか、攻撃防止にどのように役立っているか、そして誤設定がどのように適切な機能を妨げるかについて解説します。さらに、セキュリティに関連するいくつかのwell-known URIも分析します。
採用状況の測定だけでなく、場所、技術スタック、ウェブサイトの業種など、セキュリティ機構の採用を促進する要因も探ります。Web Almanacの過去のエディションのデータと比較することで、ウェブセキュリティの状態における長期的なトレンドと変化を把握することができます。
トランスポートセキュリティ
HTTPSはTransport Layer Security（TLS）を使用してクライアントとサーバー間の接続を保護します。年々、HTTPSを使用するウェブサイトが増加し、ユーザーのセキュリティが向上しています。今年、HTTPS経由で送信されるすべてのリクエストの割合は前年比で再び上昇し、モバイル接続で98.8%を超えました。
平文のHTTPではなくHTTPSを使用して送信されるリクエストの割合は100%に近づき続けており、2024年版Web Almanacと比較してモバイルでさらに0.74%上昇しました。
HTTPS経由で提供されるホームページの数にも前向きな進化が見られます。この数字はモバイルで95.6%から97.3%に上昇しました。多くのウェブサイトが多数の（多くの場合セキュアな）サイトへのサードパーティリクエストを送信するため、この数値はHTTPS経由で送信されるリクエストの割合よりも低くなる傾向がありますが、幸いにも毎年上昇し続けています。
これらの指標で前向きなトレンドが続き、HTTPSを使用するサイトの割合が100%に近づいていることは喜ばしいことです。これらの高い数値の一部は、ブラウザベンダー（Chrome、Firefox、Safari）が平文のHTTPにフォールバックする前にまずHTTPSで通信しようとし、ユーザーにセキュリティ警告を表示することが多いことで、サイトオーナーにTLSの採用を促していることで説明できます。
プロトコルバージョン
ここ数年、TLS1.3は最高のセキュリティを実現するための推奨プロトコルバージョンとなっています。最新バージョンはTLS1.2で欠陥が発見されたアルゴリズムを廃止し、前方秘匿性などのより強固なセキュリティ保証を提供します。QUICも内部的にTLSを使用しており、TLS1.3と同様のセキュリティ保証を提供しています。
2024年版Web Almanacと同様に、QUICとTLS1.3の両方で使用が増加していることが分かります。TLS1.2を使用していた一部のサイトがTLS1.3に移行し、TLS1.2またはTLS1.3を使用していた一部のサイトがQUICに移行したと考えられます。TLS1.2は今年さらに4.5%減少しました。今年はQUICの採用がやや鈍化し、QUICを使用するサイトの割合は0.8%しか上昇しませんでした。将来的にはTLS1.2が（長い時間をかけて）徐々に廃止され、QUICが引き続き普及していくと予想されます。
暗号スイート
暗号化されたチャネルでの通信を開始するには、双方が同じ暗号アルゴリズム（または暗号スイート）を使用してお互いを理解する必要があります。そのため、通信前に使用する暗号スイートに合意します。ほとんどのリクエストはGalois Counter Mode（GCM）暗号を使用した接続で行われていることが分かります。これはパディング攻撃への耐性と、TLS1.3で必須とされている関連データ付き認証暗号化（AEAD）の提供により好まれています。また、より安全な256ビット版ではなく、128ビット鍵の使用が前年比4%増加していることも分かります。NISTは128ビット暗号スイートをセキュアとみなしていますが、256ビット版はさらに強力なセキュリティ保証を提供します。今年のAlmanacのデータセットには前年よりも多くのリクエストが含まれているため、この変化はデータセットの拡大に起因する可能性があります。使用中の暗号スイートはあまり多様ではなく、実際にデータセットで使用が確認された暗号スイートはわずか5種類です。これはTLS1.3がGCMまたは最新のブロック暗号のみを許可しているためと考えられます。
AES_256_GCMが2番目に一般的なスイートで、トラフィックの約16.1%を占めており、CHACHA20_POLY1305などの最新の代替手段やAES_256_CBCなどのレガシーモードはウェブ接続のごく一部（1%未満）を占めるに過ぎません。TLS1.3は前方秘匿性をサポートするアルゴリズムのみを許可しています。TLS1.3の高い採用率から、多くのリクエストが前方秘匿性の要件を満たすことが期待されます。
予想に反して、前方秘匿性のある接続で送信されるリクエストの数が比較的少ないことが分かります。2024年版Web Almanac以降、前方秘匿性リクエストは20%減少しています。現在、このメトリクスにはTLS1.2とTLS1.3の前方秘匿性暗号のみが含まれており、QUICのTLSは含まれていないようで、これが確認された低下の説明となる可能性があります。
認証局
TLSを使用するためには、サイトは認証局（CA）から証明書を取得する必要があります。ブラウザが多数のCAを信頼しているため、サイトの証明書はブラウザによって有効な証明書として識別されます。その後、証明書はブラウザとサイトのサーバー間の安全な通信に使用されます。
| 発行者 | デスクトップ | モバイル |
|---|---|---|
| R11 | 20.80% | 21.86% |
| R10 | 20.75% | 21.73% |
| WE1 | 16.35% | 17.24% |
| E6 | 4.50% | 4.65% |
| E5 | 4.31% | 4.42% |
| Sectigo RSA Domain Validation Secure Server CA | 3.60% | 3.52% |
| Go Daddy Secure Certificate Authority - G2 | 1.77% | 1.60% |
| WR1 | 1.16% | 1.40% |
| Amazon RSA 2048 M02 | 1.37% | 1.33% |
| Amazon RSA 2048 M03 | 1.30% | 1.25% |
前年と比較すると、当時人気だったLet’s EncryptのR3中間証明書が発行者として消えていることが分かります。これは（2025年9月に）期限切れになったため予想されていたことで、前年からすでに他の中間証明書への移行が始まっていました。R10とR11の中間証明書がR3を引き継ぐ新しい証明書です。現在、中間鍵のピン留めを防ぐことを明示的な目標として、2つの中間RSA証明書（R10とR11）と2つの中間ECDSA証明書（E5とE6）があります。上位5発行者の中でLet’s Encrypt以外の唯一の証明書はWE1で、Google Trust Services（GTS）のものです。リストにはGTSのWR1も含まれています。これらの証明書はGTSの新世代中間証明書の一部であり、前年に見られたGTS CA 1P5発行者などが期限切れになっています。
Let’s Encryptの証明書を使用するサイトの総シェアは、前回の56%からわずかに低下して52.6%になりました。データから分かるように、GTSのWE1証明書が発行する証明書のシェアが増加していることが一因として挙げられます。ただし、GTSが発行した証明書（WE1他）の総シェアは計算されていません。
HTTP Strict Transport Security
HTTP Strict Transport Securityは、サーバーがブラウザに対して、まずHTTPを試みてHTTPSへのリダイレクトに従うのではなく、このドメインのページにはHTTPSのみでアクセスするよう指示できるレスポンスヘッダーです。
HSTSヘッダーを使用するページ数は引き続き増加しており、前回のエディションと比較して6ポイント上昇し、モバイルで訪問された全ページの36%に達しています。
サーバーはヘッダーにいくつかのディレクティブを含めて、ブラウザに追加の設定を伝えることができます。例えば、max-age ディレクティブはブラウザにHTTPSのみを使用し続ける期間を伝えます。他のディレクティブ includeSubDomains と preload はオプションです。
max-ageディレクティブを使用しており、4%のみがポリシーを無効にするためにmax-ageをゼロに設定しています。高度なセキュリティ機能の採用率は大幅に低く、サブドメインを保護しているサイトは約40%、最初の訪問からセキュア接続を確保するためにpreloadディレクティブを使用しているサイトは約22%に留まっています。有効な max-age を持つレスポンスのシェアは96%にわずかに増加しました。includeSubdomains と preload ディレクティブはそれぞれ約4%増加しており、一部のサイトが両方のディレクティブを同時に設定し始めたことを示している可能性があります。非公式の preload ディレクティブには includeSubdirectories の設定と max-age が少なくとも1年の値を持つことが必要です。preload ディレクティブを使用することで、サイトはブラウザが初回接続時でもドメインとそのサブドメインに常にHTTPSでアクセスすることを保証できます（preloadなしのHSTSを使用する場合は必ずしもそうとは限りません）。
max-age値の分布。
有効な max-age 値の分布は、低いパーセンタイルを除いてほぼ同じままです。10パーセンタイルでは30日から91日へと大きな増加が見られ、非常に低い max-age 値を設定するサイトが減少していることを示しています。中央値は1年つまり365日のままです。
クッキー
クッキーはウェブの重要な部分です。クッキーはウェブサイトが複数のステートレスなリクエストにわたって情報を保存できるようにします。サイトのクッキーを保護するために、Cookiesチャプターで詳しく報告されている多くのブラウザ組み込み機能があります。このチャプターでは特にクッキー属性、クッキープレフィックス、永続性（有効期限）のセクションを参照します。
コンテンツインクルージョン
コンテンツインクルージョンはウェブのコアコンポーネントです。コンテンツデリバリーネットワーク（CDN）からのページ、CSS、JavaScriptや共有ソースからの画像をインクルードできることは、ウェブが構築された基盤の一つです。しかし、これにはサードパーティのコンテンツをインクルードするサイトがそれらのサードパーティリソースに多大な信頼を置くなど、特定のリスクが伴います。もちろん、そのリソースが悪意を持っていないか、悪意のある攻撃者によって侵害されていないという保証はなく、これはサプライチェーン攻撃など多くの深刻な攻撃につながる可能性があります。このリスクを軽減するために、コンテンツインクルージョンを制御するセキュリティポリシーを使用することが重要です。
コンテンツセキュリティポリシー
コンテンツセキュリティポリシー（CSP）は、ウェブサイトがそのページにロードされるコンテンツをきめ細かく制御できるようにします。Content-Security-Policy レスポンスヘッダーを設定するか、<meta> HTMLタグで定義することで、ウェブサイトは使用中のポリシーをブラウザに伝え、ブラウザはそれを強制します。ポリシーには多くの利用可能なディレクティブがあり、ウェブサイトがどのソースからコンテンツをロードできるかを定義できます。
CSPは特定のリソースのロードをブロックするために使用でき、潜在的なクロスサイトスクリプティング（XSS）攻撃の影響を軽減するのに役立ちます。さらに CSP は、update-insecure-requests ディレクティブによる暗号化通信チャネルの使用の強制や、frame-ancestors ディレクティブを使用した現在のページがサブリソースとしてロードできるページの制御など、他の目的にも使用できます。これにより、ウェブサイトはクリックジャッキング攻撃から防御できます。
Content-Security-Policyヘッダーの採用率の相対的な増加。
CSPの採用は昨年の18.5%から今年の21.9%へと引き続き増加しており、20%近い増加です。Web Almanacの前回版で予測されたように、採用率は20%を超え、引き続き着実に上昇していることを示しています。
ディレクティブ
upgrade-insecure-requestsとframe-ancestorsで、セキュア接続の管理とクリックジャッキングの防止のために、CSPヘッダーの約50〜55%に存在します。デスクトップサイトは一般的に従来のディレクティブ使用でリードしていますが、モバイルサイトはtrusted-typesやreport-uriなどの最新セキュリティ機能で大幅に高い採用率を示しています。今年も多くのウェブサイトがCSPを upgrade-insecure-requests と frame-ancestors ディレクティブのために使用しています。これらのディレクティブを使用するモバイルサイトの相対的なシェアはわずかに減少しましたが、これはスキャンされたCSPヘッダーの数が多いことに起因していると考えられます。絶対数はデスクトップとモバイルでそれぞれ40万と80万のCSPヘッダーが増加しています。
upgrade-insecure-requests に置き換えられた block-all-mixed-content ディレクティブは、ここ数年と同様に引き続きわずかに減少しています。このディレクティブは非推奨なので、これは良いニュースです。
| ポリシー | デスクトップ | モバイル |
|---|---|---|
upgrade-insecure-requests |
21.45% | 22.79% |
block-all-mixed-content; frame-ancestors 'none'; upgrade-insecure-requests; |
19.92% | 18.06% |
require-trusted-types-for 'script';report-uri /checkin/_/AndroidCheckinHttp/cspreport |
2.67% | 12.10% |
frame-ancestors 'self' |
7.55% | 6.38% |
upgrade-insecure-requests; |
4.92% | 4.30% |
frame-ancestors 'self'; |
2.53% | 2.29% |
昨年上位3位にあったのと同じヘッダー値が今年の上位4位にも登場しています。ただし、今年の3番目に一般的なCSPヘッダーは新しいものです。この変化は、今年は昨年のようにデスクトップ使用率ではなくモバイル使用率で最も一般的なヘッダーをソートしているためです。Android関連の特定の report-uri エンドポイントを持つtrusted typesポリシーが3位に現れています。
Trusted typesは、インジェクションシンク（element.innerHTMLなど）に渡されるパラメータを制限し、プレーン文字列の代わりに適切に型付けされた値のみが渡されるようにするために使用できます。インジェクションシンクに渡される値を制限することで、多くの潜在的なDOM XSS脆弱性を防ぐことができます。観察されたtrusted typesヘッダーはモバイルページの12%以上に表示されています。この特定のCSPポリシー値の高い使用率については直接的な説明はありません。
5位と6位では、upgrade-insecure-requests と frame-ancestors 'self' ディレクティブが再び登場しますが、今回は末尾にセミコロンがついています。セミコロンはディレクティブを区切るために使用されますが、定義されているディレクティブが1つだけの場合は廃棄することができ、どちらのヘッダー値も同じ効果を持つ有効なCSPポリシーです。
script-src のキーワード
CSPに含まれる最も重要なディレクティブの一つは script-src です。このディレクティブを使用することで、ウェブサイトはどのスクリプトがページで実行できるかを制御できます。これは攻撃者が任意のスクリプトを実行するのを妨げることができるため、攻撃者を抑制することができます。script-src には複数の潜在的なキーワードがあります。
script-src属性の使用状況を示す棒グラフ。デスクトップとモバイルの両方でウェブサイトの圧倒的な92%がunsafe-inline属性を使用しており、unsafe-evalはポリシーの77%に存在し、nonceは約20%のサイトで使用され、strict-dynamicは約10%のみです。script-srcキーワードの普及率。
unsafe-inline と unsafe-eval キーワードが非常に頻繁に使用されていることが分かります。これらのキーワードはそれぞれインラインスクリプトの実行を許可するか、JavaScriptの eval 関数の使用を許可するため、CSPの script-src のセキュリティへの影響を大幅に低下させます。
昨年と比較して、script-src キーワードの使用にほとんど変化がないことが分かります。重要な注意点として、unsafe-inline の存在は必ずしもインラインスクリプトが実行できることを意味するわけではありません。場合によっては、CSP仕様に従って unsafe-inline は無視されます。例えば、nonceと strict-dynamic キーワードがCSPポリシーに追加されている場合がこれに該当します。
script-src属性の使用状況を示す棒グラフ。デスクトップとモバイルの両方でヘッダーの圧倒的な92%がunsafe-inline属性を使用しており、unsafe-evalはポリシーの77%に存在し、nonceは約20%のサイトで使用され、strict-dynamicは約10%のみです。script-srcキーワードの普及率。
ページごとではなくヘッダーごとのキーワード使用状況も確認します。CSPでは、1つのレスポンスに複数のCSPヘッダーが存在し、異なるディレクティブを定義する場合があります。ディレクティブが複数回定義されている場合、ポリシーはブラウザが使用する最も制限的なポリシーを作成するために結合されます。
リクエストごとの値と非常に似た分布が見られ、ほとんどのページがCSPヘッダーを1つだけ使用しているか、設定しているCSPヘッダーの1つだけに script-src を使用していることを示しており、ほとんどのページで script-src ディレクティブが競合していないことを意味します。
許可されたホスト
CSPは完全に理解して正しく使用するには複雑なセキュリティポリシーです。使用中のCSPヘッダーの長さを確認すると、ポリシーのサイズに大きなバリエーションがあることが分かります。
観察されたすべてのヘッダーのうち、75%が86バイト以下の長さです。これは昨年の75バイト以下よりわずかに長くなっています。90パーセンタイルでより長いポリシーが増加していることが分かります。デスクトップのポリシーは長くなり、モバイルのポリシーはわずかに短くなり、ポリシーの長さの差が広がっています。
| ホスト | デスクトップ | モバイル |
|---|---|---|
https://www.googletagmanager.com |
0.74% | 0.62% |
https://fonts.gstatic.com |
0.61% | 0.49% |
https://fonts.googleapis.com |
0.60% | 0.48% |
https://www.google.com |
0.54% | 0.46% |
https://www.google-analytics.com |
0.47% | 0.38% |
https://www.youtube.com |
0.41% | 0.34% |
https://*.google-analytics.com |
0.35% | 0.31% |
https://*.google.com |
0.31% | 0.30% |
https://connect.facebook.net |
0.33% | 0.29% |
https://www.gstatic.com |
0.35% | 0.27% |
CSPヘッダーに含まれる最も一般的にロードされるHTTPSオリジンは、広告、フォント、その他のCDNリソースに使用されるものです。
| ホスト | デスクトップ | モバイル |
|---|---|---|
wss://*.hotjar.com |
0.18% | 0.15% |
wss://*.intercom.io |
0.07% | 0.07% |
wss://booth.karakuri.ai |
0.08% | 0.06% |
wss://www.livejournal.com |
0.04% | 0.05% |
wss://*.quora.com |
0.03% | 0.05% |
wss://tsock.us1.twilio.com/v3/wsconnect |
0.02% | 0.04% |
wss://api.smooch.io |
0.05% | 0.03% |
wss://*.zopim.com |
0.05% | 0.03% |
wss://*.pusher.com |
0.04% | 0.03% |
wss://cable.gumroad.com |
0.04% | 0.03% |
セキュアウェブソケット（wss://）オリジンでは、Hotjarが1位を占め、出現数が2倍になっています。他のオリジンは出現数が少ないままです。
Hotjarはウェブサイト分析に使用されており、ウェブサイトの分析情報への継続的な関心を示しており、Intercomはカスタマーサービスに使用されています。また、AIファースト企業として、上位3位に入るkarakuriという日本のAI企業も統計に登場しています。
サブリソース整合性
改ざんされたリソースのロードから保護するために、開発者はサブリソース整合性（SRI）を利用できます。CSPが開発者にリソースがロードされるソースを制限させる一方で、SRIはそれらのリソースが開発者が期待するコンテンツを含むことを確認します。例えば、CDNが侵害され、攻撃者が有効なスクリプトを悪意のあるものに変更することに成功した場合はその逆になります。
<script> タグと <link> タグで integrity 属性を使用することで、開発者はブラウザにリソースの期待するハッシュを伝えることができます。指定されたリソースをロードする際、ブラウザはリソースの内容のハッシュが提供されたハッシュに対応するかどうかを確認し、対応しない場合はリソースのロード/実行を拒否し、ウェブサイトを潜在的に侵害されたコンテンツから保護します。
SRIはデスクトップとモバイルのページでそれぞれ25.9%と23.6%で使用されています。これは昨年から両数字とも約2.5%上昇しており、増加する数の開発者がSRIを使用してページを保護していることを示しています。
昨年と比較して、ページごとのサブリソースカバレッジの中央値が0.41%低下しています。この低下は、今年のWeb Almanacクローラーがクロールするページ数が多いことによる可能性が高いです。
| ホスト | デスクトップ | モバイル |
|---|---|---|
www.gstatic.com |
34.70% | 34.55% |
static.cloudflareinsights.com |
8.89% | 8.37% |
cdnjs.cloudflare.com |
7.43% | 7.20% |
cdn.userway.org |
6.10% | 6.60% |
code.jquery.com |
4.96% | 4.77% |
cdn.shoplineapp.com |
4.62% | 5.22% |
cdn.jsdelivr.net |
4.50% | 4.06% |
d3e54v103j8qbb.cloudfront.net |
2.03% | 2.30% |
SRI保護スクリプトがロードされる最も一般的なホストのリストは、一部のエントリーが相対的な位置を変えながらも、全体的に安定しています。例えば cloudflareinsights レコードは相対的な出現率が増加しましたが、2.40%のみです。
昨年と同様に、これらのエントリーのほとんどはCDNであり、SRIでロードおよび保護されるリソースのほとんどがCDNからロードされていることを示しています。これらのスクリプトは開発者の直接制御下にないことが多いため、これは理にかなっています。CDNは多くの場合、多くの開発者が含めることができる大量のスクリプトをホストします。これは自分のサーバーへの負荷が下がるため開発者にとって有益ですが、クライアントにとってもそれを含むすべてのウェブサイトで同じスクリプトを一度ずつロードするのではなく、CDNからスクリプトをキャッシュできるという点で有益です。
自分で制御していないサーバーにホストされているスクリプトを含めるリスクは、開発者として完全に制御している場合よりも高くなります。この外部スクリプトの開発者が悪意のあるコンテンツを含めることを決めるか、サーバーが侵害されてスクリプトが悪意のあるものに置き換えられた場合、SRIなしでは開発者のユーザーがこの悪意のあるコンテンツをロードして実行することになります。ユーザーをこれらの予期しない変更から保護し、どのスクリプトが実行を許可されているかを確実に知るための良い方法がSRIの使用です。
パーミッションポリシー
パーミッションポリシー（以前はFeature Policy）は、カメラ、マイク、センサー（加速度計など）、位置情報データなど、ブラウザでの特定機能の使用を許可または拒否できるようにするポリシーです。Permissions-Policy レスポンスヘッダーを通じて、開発者はメインページとその埋め込みコンテンツによる特定の機能使用を許可または拒否できます。1つの埋め込みリソースに対する特定のポリシーは、<iframe> 要素の allow 属性を通じて設定できます。
Permissions-Policyヘッダーの採用率の相対的な増加（モバイル）。
昨年と比較して、Permissions-Policy の使用は相対的に60%近く増加しました。これは大きな相対的な増加ですが、Permissions-Policy を使用するウェブサイトの絶対的な割合は、モバイルで3.7%と依然として比較的少ない状況です。採用率の上昇はポリシーにとって良い兆しです。
| ヘッダー | デスクトップ | モバイル |
|---|---|---|
interest-cohort=() |
11.02% | 11.56% |
accelerometer=(), autoplay=(), camera=(), encrypted-media=(), fullscreen=(), geolocation=(), gyroscope=(), magnetometer=(), microphone=(), midi=(), payment=(), picture-in-picture=(), publickey-credentials-get=(), screen-wake-lock=(), sync-xhr=(), usb=() |
5.01% | 10.00% |
geolocation=(),midi=(),sync-xhr=(),microphone=(),camera=(),magnetometer=(),gyroscope=(),fullscreen=(self),payment=() |
4.63% | 4.44% |
accelerometer=(), autoplay=(), camera=(), cross-origin-isolated=(), display-capture=(self), encrypted-media=(), fullscreen=*, geolocation=(self), gyroscope=(), keyboard-map=(), magnetometer=(), microphone=(), midi=(), payment=*, picture-in-picture=*, publickey-credentials-get=(), screen-wake-lock=(), sync-xhr=*, usb=(), xr-spatial-tracking=(), gamepad=(), serial=() |
3.65% | 3.45% |
geolocation=(self) |
2.06% | 2.64% |
accelerometer=(), camera=(), geolocation=(), gyroscope=(), magnetometer=(), microphone=(), payment=(), usb=() |
2.77% | 2.38% |
accelerometer=(self), autoplay=(self), camera=(self), encrypted-media=(self), fullscreen=(self), geolocation=(self), gyroscope=(self), magnetometer=(self), microphone=(self), midi=(self), payment=(self), usb=(self) |
2.39% | 2.25% |
browsing-topics=() |
1.82% | 2.14% |
geolocation=(), microphone=(), camera=() |
2.11% | 2.09% |
geolocation=self |
1.87% | 1.81% |
Permission-Policyヘッダー
上位10位の Permissions-Policy 値を確認すると、GoogleのFederated Learning of Cohorts（FLoC）をオプトアウトするためにヘッダーを使用する開発者が少なくなっており、Permissions-Policy ヘッダーの11.5%のみが interest-cohort=() 値を含んでいます。また、モバイルでの Permissions-Policy ヘッダーの10%がこの値を含む、一度に多くの機能をオプトアウトする値が人気の値になっていることも分かります。これは異なるPermission PolicyでのTopics APIに置き換えられたためと考えられます。また、GoogleがこれらのPrivacy Sandbox APIを廃止しているため、将来的にさらに減少する可能性が高いです。
上位10位で観察された他のすべての値は、ウェブページと埋め込みコンテンツの権限を制限することを目的としています。パーミッションポリシーはデフォルトでオープンであり、機能の使用を制限するためにはヘッダーで明示的に言及する必要があります。昨年と同様に、デスクトップの Permissions-Policy ヘッダーの0.27%が * ワイルドカード値を設定しており、allow 属性により厳格なポリシーを定義していないページと埋め込みコンテンツにすべての権限を明示的に付与しています。モバイルでは、ワイルドカード値はまったく見つかりませんでした。
前述のように、Permissions PolicはHTML <iframe> の allow 属性でも定義できます。例えば、埋め込みコンテンツにカメラとマイクへのアクセスを許可するiframeは次のようになります：
<iframe src="https://example.com/" allow="camera 'self'; microphone 'self'">モバイルの合計3,330万のiframeのうち、29.2%が allow 属性を含んでいることが観察されました。allow 属性の使用の相対的な減少は、今年のクロールで前年よりも多くのページが含まれていたため、1,000万以上多くのiframe要素が見つかったことに起因していると考えられます。
| ディレクティブ | デスクトップ | モバイル |
|---|---|---|
encrypted-media |
60.90% | 70.66% |
autoplay |
34.99% | 41.83% |
picture-in-picture |
26.10% | 36.63% |
gyroscope |
23.76% | 34.20% |
accelerometer |
23.76% | 34.20% |
clipboard-write |
20.39% | 26.24% |
join-ad-interest-group |
24.23% | 17.35% |
web-share |
12.07% | 15.67% |
attribution-reporting |
3.93% | 2.35% |
run-ad-auction |
3.84% | 2.26% |
allow属性ディレクティブ
興味深いことに、昨年の上位3つの allow 属性値（join-ad-interest-group、attribution-reporting、run-ad-auction）は昨年と比べて極めて低い採用率になっています。これらの値をiframe要素に追加したと仮定されていた大手プレイヤーが、その変更を元に戻した可能性があります。昨年の上位10位に入るその他の値は、allow 属性値への組み込みが全体的に大幅に増加しており、絶対的な変化は最大+50%に達しています。
iframeサンドボックス
<iframe> 要素にsandbox属性を使用することで、開発者は <iframe> に埋め込まれたリソースが侵害されたり悪意を持ったりした場合のいくつかの攻撃からユーザーを保護できます。sandbox 属性の値では、開発者が <iframe> にロードして表示されるコンテンツに対してどのような制限を設けるべきかを指定できます。例えば、以下の <iframe> は埋め込みウェブページがスクリプトを実行できるようにします：
<iframe src="https://example.com/" sandbox="allow-scripts"></iframe>sandbox属性の使用は2024年版から20.0%から22.7%に上昇しており、埋め込みコンテンツによる潜在的な悪用からユーザーを保護したいと考える開発者が増加していることを示しています。
allow-scriptsとallow-same-originディレクティブはほぼ普遍的で、JavaScriptの実行や独自のストレージへのアクセスなどのコア機能を埋め込みコンテンツが維持できるようにするためにサンドボックスページの約97〜98%に存在します。allow-popupsとallow-popups-to-escape-sandboxなどの適度に一般的な機能はサイトの約70〜75%で利用されており、allow-top-navigation-by-user-activationなどの特殊なナビゲーションコントロールは30%未満で最も採用率が低くなっています。昨年と同様に、sandbox 属性を持つすべてのiframeのうち、98.5%（モバイル）が allow-scripts ディレクティブを含めることで埋め込みウェブページがスクリプトを実行できるようにするために使用していることが分かります。2位は、モバイルiframeの97.8%で使用されており、開発者がロードされたリソースを埋め込み元のオリジンの一部にするための allow-same-origin です。
新興のセキュリティヘッダー
TLS、HSTS、CSPポリシー、SRI、iframeの sandbox 属性などの既存のセキュリティ機能のほとんどで上昇が見られます。これらの既存機能に加えて、時代が進むにつれて新しい攻撃が作成され、より多くの防御が実装されています。このセクションでは、実際の環境で見られる頻度が増えている比較的新しいドキュメントポリシーについて説明します。
ドキュメントポリシー
ドキュメントポリシーは、2022年に最終更新されたコミュニティグループレポートの草案です。もともとは、パーミッションポリシーモデルに合わなかったり、複雑さを過度に増加させたりするパーミッションポリシーへの提案された追加に対する応答として作成されました。
ドキュメントポリシーはパーミッションポリシー、CSP、サンドボックスなどの関連メカニズムと比べていくつかの利点があります。パーミッションポリシーよりもきめ細かく、異なる継承モデルを持っており：子リソースは互換性がある場合は親が選んだ特定のポリシーを上書きできます。CSPよりも一般的で、リソースがロードされた後の権限に関するディレクティブを持っており、リソースをロードできるオリジンを決定するだけではありません。サンドボックスより拡張が容易なのは、サンドボックスで言及されていない機能はデフォルトでブロックされており、新しいものを追加することが非常に困難だからです。
| ヘッダー | デスクトップ | モバイル |
|---|---|---|
include-js-call-stacks-in-crash-reports |
68.48% | 71.99% |
js-profiling |
12.66% | 15.24% |
js-profiling; include-js-call-stacks-in-crash-reports |
17.41% | 11.94% |
force-load-at-top |
1.25% | 0.65% |
no-font-display-late-swap |
0.06% | 0.05% |
使用中のドキュメントポリシーヘッダーのうち、3分の2以上がクラッシュレポートにコールスタックを含めるために使用されていることが分かります。js-profiling ディレクティブと組み合わせると、これら2つの機能が現在のユースケースの大多数を占めています。現在、合計で19の異なるディレクティブを含むポリシー値が見つかります。一般的には定義されているディレクティブがより多い場合もありますが、現時点ではその合計数は把握できていません。
現在、デスクトップとモバイルでそれぞれ約24,000と29,500ページしか見つかっておらず、訪問した総ページ数の0.10%です。ドキュメントポリシーヘッダーの採用率は今後も上昇すると予想されますが、将来的な採用は急速には進まないかもしれません。
攻撃防御
ブラウザが実装しているウェブサイトへの多くの防御がある一方で、すべての可能性とベストプラクティスの概要を把握することは困難です。さらに、保護がオプトインであり、デフォルトで有効になっていない場合は、さらなる課題となります。開発者は最新の攻撃と、それらの攻撃からユーザーを保護するために存在する防御について常に最新情報を把握しておく必要があります。このセクションでは、ウェブ全体でどの攻撃防御手段が使用されているかを評価します。
セキュリティヘッダーの採用
多くの保護メカニズムがHTTPレスポンスヘッダーを通じて設定できます。これらのヘッダーの値に基づいてブラウザはこれらの保護を強制します。すべてのセキュリティメカニズムがすべてのウェブサイトに関連するわけではありませんが、セキュリティヘッダーがまったくない場合はセキュリティに対する緊急性の欠如を示す可能性があります。
X-Content-Type-Optionsが2025年までに採用率約50%でグループをリードしています。X-Frame-OptionsやStrict-Transport-Securityなどの他の主要なヘッダーがそれに続き、サイトの約35%への着実な増加を示しています。一方、Cross-Origin-Opener-PolicyやPermissions-Policyなどのより現代的またはニッチなヘッダーは採用の初期段階にあり、10%の閾値を大きく下回っています。昨年と同様に、採用が減少しているヘッダーはわずかです。Feature-Policy ヘッダーは Permissions-Policy に取って代わられたため廃止されており、採用が減少していることは驚くことではありません。他の2つ（Clear-Site-Data と Document-Policy-Report-Only）の採用率は非常に低く（それぞれ0.01%と0.00001%）、採用率の相対的な変化は大きく見えることがありますが、絶対的な差は実際には小さいです。これは全体的なセキュリティヘッダーの採用が時間とともに増加し続けていることを意味し、ウェブセキュリティ全体にとって前向きな兆候です。
2024年版からの最も強い上昇は Strict-Transport-Security（+4.02%）、Content-Security-Policy（+3.39%）、X-Content-Type-Options（+2.30%）です。
Origin-Agent-Cluster
Origin-Agent-Clusterは、正しく設定されている場合、ドキュメントに使用されるリソース（オペレーティングシステムプロセスなど）を同じオリジンのドキュメントと共有するリクエストをブラウザに伝えます。ブラウザはリクエストに応じることも応じないこともあり、クライアントはJavaScriptを使用してリクエストが実際に応じられたかどうかを確認できます。
使用率は依然として低く、モバイルサイトの0.47%、デスクトップサイトの0.38%がこれを使用していますが、彼らが何のために使用しているかを詳しく見てみましょう：
| ヘッダー | デスクトップ | モバイル |
|---|---|---|
?1 |
74.11% | 90.32% |
?0 |
25.79% | 9.60% |
1 |
0.08% | 0.07% |
0 |
0.01% | 0.01% |
Origin-Agent-Clusterヘッダー値
ブール値はHTML Living Standardで疑問符で始まる文字列として定義されています。これは 1 や 0 のような値がこのヘッダーに対して無効であることを意味します。幸いにも、これらの値の使用は限定的です。?1 値は Origin-Agent-Cluster の唯一の有効値であり、開発者がこの機能にオプトインしたいことを伝えるために使用され、他のすべての値は無視されます。モバイルでは、ヘッダーの90%以上が有効な ?1 値を持っています。残念ながら、ヘッダー値の0.07%は 1 であり、開発者が専用リソースの使用をリクエストしたいにもかかわらず無視される値です。
document.domainの使用
document.domainを使用することで、開発者は現在のドキュメントのドメイン部分を読み取ることができ、新しいドメインを設定することもできます（現在のドメインのスーパードメインのみ許可）。その後、ブラウザは同一オリジンポリシーのチェックに新しいドメインをオリジンとして使用します。ただし、このプロパティの使用は現在非推奨となっており、ブラウザはまもなくこのプロパティのサポートを停止する可能性があります。
| Blink機能 | デスクトップ | モバイル |
|---|---|---|
DocumentSetDomain |
0.49% | 0.36% |
DocumentDomainSetWithNonDefaultPort |
0.16% | 0.14% |
DocumentDomainEnabledCrossOriginAccess |
0.0008% | 0.0004% |
DocumentDomainBlockedCrossOriginAccess |
0.0002% | 0.0001% |
DocumentOpenAliasedOriginDocumentDomain |
0.00008% | 0.00001% |
document.domainの使用
デスクトップとモバイルのウェブサイトのうち0.5%未満が document.domain セッターを使用してページのオリジンを変更しており、非デフォルトポートで行うサイトはさらに少ないことが分かります。これは前向きなトレンドですが、依然としてコードを更新すべき数万のウェブサイトが存在します。
CSPとX-Frame-Optionsによるクリックジャッキング防御
前述のように、コンテンツセキュリティポリシー（CSP）は frame-ancestors ディレクティブを使用してクリックジャッキング攻撃に対して有効です。一部の上位CSPヘッダー値には 'none' または 'self' 値を持つ frame-ancestors ディレクティブが含まれており、ページの埋め込みを全体的にブロックするか、同一オリジンのページへの埋め込みを制限します。
クリックジャッキング攻撃に対する別の防御方法は、X-Frame-Options（XFO）ヘッダーを通じてです。XFOヘッダーを設定することで、開発者はドキュメントが他のドキュメントに埋め込めないこと（’DENY’）、または同一オリジンのドキュメントのみに埋め込めること（SAMEORIGIN）を伝えることができます。
| ヘッダー | デスクトップ | モバイル |
|---|---|---|
SAMEORIGIN |
72.48% | 72.13% |
DENY |
24.40% | 24.64% |
ALLOWALL |
0.68% | 0.72% |
SAMEORIGIN, SAMEORIGIN |
0.27% | 0.28% |
allow-from https://s.salla.sa |
0.16% | 0.28% |
X-Frame-Optionsヘッダー値
今年のデータと2024年のデータではほとんど変化がないことが分かります。X-Frame-Options ヘッダーは主に同一オリジンのウェブサイトがページを埋め込めるようにするために使用されています（72.1%）。次に、任意のページが自身のコンテンツを埋め込むことを拒否するために使用されています（24.6%）。
観察される他の値の例はテーブルの3行目から5行目に示されています。ALLOW-FROM 値はかつて有効でしたが、現在は非推奨でブラウザに無視されます。XFOで ALLOW-FROM を使用する代わりに、開発者はCSPの frame-ancestors ディレクティブの使用に切り替えるべきです。これらの仕様外の値はあまり見られませんが、ヘッダーを設定することで保護が有効になると期待する開発者によって設定されている場合があります。
クロスオリジンポリシーを使用した攻撃防御
SpectreとMeltdownのようなマイクロアーキテクチャサイドチャネル攻撃とCross-Site Leaks（XS-Leaks）の登場により、クロスオリジンリソースの使用と埋め込みに関するセキュリティの視点が変わりました。これらの脅威に対応して、他のウェブサイトでのリソースのレンダリングを制御し、これらの新しい脅威から保護するための新しいメカニズムが作成されました。
クロスオリジンポリシーとして知られる複数の新しいセキュリティヘッダーがこれらの課題への対応として作成されました：Cross-Origin-Resource-Policy（CORP）、Cross-Origin-Embedder-Policy（COEP）、Cross-Origin-Opener-Policy（COOP）。これらのヘッダーは、開発者がリソースが異なるオリジン間でどのように埋め込まれるかを制御できるようにすることで、サイドチャネル攻撃から保護するメカニズムを提供します。これらのヘッダーのすべての採用が年々増加し続けており、CORPとCOOPの両方が今年2%以上の採用率に達していることが観察されます。
Cross-Origin-Resource-Policyは3つの中で最も広く採用されており、2023年の約1.75%から2025年には2.25%以上に成長しています。Cross-Origin-Opener-Policyは最も大きな相対的な成長を経験し、3年間で採用率が1.00%未満から約2.00%へと倍増以上しました。Cross-Origin-Embedder-Policyは最も一般的でないものの、2025年までに約0.75%の採用率に達する着実な上昇傾向を示しています。クロスオリジンエンベッダーポリシー
Cross-Origin-Embedder-Policy（COEP）は、開発者がどのクロスオリジンリソースが現在のドキュメントに埋め込めるかを設定できるようにします。デフォルト（ヘッダーが存在しない場合）では、すべてのクロスオリジンリソースがページに埋め込めます。これはヘッダーが unsafe-none 値で設定されている場合と同じ動作です。
| COEP値 | デスクトップ | モバイル |
|---|---|---|
unsafe-none |
83.26% | 86.52% |
require-corp |
6.68% | 4.92% |
credentialless |
2.59% | 1.89% |
昨年と比較して、ほとんどの開発者は依然として unsafe-none 値を使用してすべてのコンテンツが現在のドキュメントに埋め込まれることを明示的に許可するためにCOEPヘッダーを設定しています。この値の使用率はモバイルで依然として86%以上ありますが、昨年から約2%低下しており、開発者がヘッダーの使用を変更し始めていることを示している可能性があります。
他の値 require-corp と credentialless は昨年からそれぞれ0.2%と0.3%のわずかな採用増加を見せました。require-corp を使用する場合、ブラウザは同一オリジンコンテンツまたはCORPによって埋め込みが許可されたクロスオリジンコンテンツのみがページに埋め込まれることを強制します。
credentialless の場合、ブラウザはコンテンツのCORSポリシーに関係なく no-cors モードでクロスオリジンリクエストを許可しますが、クッキーはリクエストに添付されません。
クロスオリジンリソースポリシー
COEPと関連して、Cross-Origin-Resource-Policy（CORP）は、現在のドキュメントにどのコンテンツが埋め込まれるかを強制するのではなく、現在のコンテンツがどのドキュメントからアクセスできるかを管理します。
可能な値は cross-origin、same-origin、same-site の3つだけです。cross-origin 値はすべてのドキュメントがリソースにアクセスできるようにし、same-origin と same-site 値はそれぞれ同一オリジンまたはサイトのドキュメントのみにリソースへのアクセスを制限します。開発者はオリジン（スキーム、ホスト、ポート）とサイト（登録可能なドメイン）の違いを認識すべきです。ヘッダーが存在する場合、no-cors モードのリクエストはブラウザによってブロックされます。
| CORP値 | デスクトップ | モバイル |
|---|---|---|
cross-origin |
81.36% | 80.52% |
same-origin |
14.40% | 15.63% |
same-site |
3.80% | 3.48% |
ほとんどの場合、ヘッダーはあらゆるクロスオリジンリソースへのアクセスを許可するために使用されています。今年この数字に大きな変化が見られ、昨年から10%以上低下してモバイルで80.5%になっています。一方、same-origin 値の使用は約10%上昇しており、開発者がクロスオリジンアクセスからリソースを保護する方向に移行していることを示しています。same-site の使用シェアはほぼ同じで、半パーセント未満のわずかな減少を示しています。
クロスオリジンオープナーポリシー
最後のクロスオリジンポリシーヘッダー、Cross-Origin-Opener-Policy（COOP）は、開発者が window.open などのブラウザAPIを通じてページを開いたときに他のページがそのページを参照できる方法を制御できるようにします。
デフォルト値の unsafe-none はCOOP保護を無効にできるようにし、これはヘッダーが存在しない場合にも起こります。開発者が window.open を使用して unsafe-none を使用するページを開いた場合、返された値を使用して開かれたページの特定のプロパティにアクセスでき、これがCross-Site Leaksにつながる可能性があります。
same-origin がオープナーと開かれたリソースの両方に存在する場合、windows.open によって返された参照はオープナーが使用できます。same-origin-allow-popups は、ドキュメントが依然として動作する参照へのアクセスを維持しながら、unsafe-none を持つ別のドキュメントを開けるようにします。
最後に、noopener-allow-popups は、開かれたドキュメントも同じCOOP値が設定されている場合を除いて、参照に決してアクセスできないようにします。
| COOP値 | デスクトップ | モバイル |
|---|---|---|
same-origin |
58.22% | 61.64% |
unsafe-none |
28.47% | 26.82% |
same-origin-allow-popups |
11.36% | 9.95% |
noopener-allow-popups |
0.03% | 0.03% |
COOPの最も厳格な same-origin 値の使用はモバイルで47.5%から61.6%に引き続き上昇しています。noopener-allow-popups は非常に新しい値で、昨年にはまだ存在しませんでした。今年はこの値を使用する少数の採用者が確認されます。unsafe-none の使用は10%以上低下しました。これらの変化はCOOPの使用において前向きな進化を示しています。
クロスオリジンアイソレーション
SharedArrayBuffer や Performance.now などの特定の機密APIにアクセスするためには、サイトがクロスオリジンアイソレーション状態である必要があります。クロスオリジンアイソレーション状態であるためには、開発者がCOEPを same-origin に設定し、CORPを require-corp または credentialless のいずれかに設定する必要があります。その後、ブラウザはこれらのAPIへのアクセスを再び許可します。これはXS Leaksに対する保護を強化します。最近では、開発者はドキュメントアイソレーションポリシーを使用してクロスオリジンアイソレーションにオプトインすることもできます。
Clear-Site-Dataを使用した攻撃防御
Clear-Site-Data HTTPレスポンスヘッダーを使用することで、開発者はクライアントにブラウジングデータをクリアするよう指示できます。ヘッダーの値はクリアするデータの種類を指定します。これはユーザーがウェブサイトからログアウトするときに役立ち、開発者は認証クッキーが確実にクリアされることを確認できます。
Clear-Site-Data の採用率を正確に推定することは難しいです。その使用はユーザーをログアウトさせる際に最も価値があることが多いためです。使用しているクローラーはウェブサイトにログインしないため、ログアウト後にヘッダーを使用するサイト数を確認するためにログアウトすることもできません。現時点では、Clear-Site-Data ヘッダーを使用している2,024のモバイルホストが確認されており、これはクロールされたホストの総数の0.01%にすぎません。
| クリアサイトデータ値 | デスクトップ | モバイル |
|---|---|---|
cache |
30.82% | 29.25% |
* |
17.74% | 20.61% |
cookies |
7.02% | 8.16% |
"cache" |
8.94% | 7.19% |
"storages" |
5.66% | 6.08% |
cache, cookies, storage |
2.12% | 3.23% |
"cache", "cookies", "storage", "executionContexts" |
2.32% | 2.51% |
"cookies" |
2.78% | 2.46% |
"storage" |
2.27% | 2.03% |
"cache", "storage", "executionContexts" |
1.36% | 1.54% |
Clear-Site-Dataヘッダーの普及率
データは、ほとんどの開発者がキャッシュをクリアするために Clear-Site-Data ヘッダーを使用しようとしていることを示しています。最も普及している値は cache で、次にワイルドカード文字 * と cookies が続きます。上位3つの値はすべて仕様によると無効です。このヘッダーの値は「引用符付き文字列」でなければならず、つまり "cache"、"*"、"cookies" が同等の有効な値です。上位3つの値を合わせると、モバイルの現在のヘッダー値の58.01%をすでに占めているため、これは懸念されます。
これらの数字は年々かなり変動しますが、ヘッダーの採用率が低いため、非常に少数のホストが相対的な割合を大幅に変更できることで説明できると考えられます。
<meta>を使用した攻撃防御
レスポンスヘッダーで設定することに加えて、ウェブのセキュリティメカニズムの一部は <meta> タグを使用してHTMLドキュメント内で直接設定できます。その例として Content-Security-Policy と Referrer-Policy があります。これらのメカニズムへのmetaタグの使用は昨年からほぼ安定しており、CSPとReferrer-Policyでそれぞれ約0.60%と約2.50%です。昨年と同様に、CSPのわずかな減少とReferrer-Policyのわずかな増加が観察されます。
| Metaタグ | デスクトップ | モバイル |
includes Referrer-policy |
2.75% | 2.52% |
includes CSP |
0.64% | 0.59% |
includes not-allowed policy |
0.12% | 0.11% |
他のセキュリティメカニズムは <meta> タグを使用して設定できませんが、毎年開発者がこれを試みているのが確認されます。今年はモバイルでmetaタグを使用して設定できないポリシーが0.07%から0.11%に増加しています。これらの値はブラウザに無視されるため、正しいヘッダーが設定されていない場合、ユーザーが脆弱な状態になる可能性があります。継続的な例として、今年は X-Frame-Options ポリシーを含む5,564のmetaタグが見つかりました。これは昨年より約600ページ多く、懸念されるトレンドです。
ウェブ暗号化API
ウェブ暗号化APIは、基本的な暗号化操作を実行するインターフェースを提供するJavaScript APIです。そのような操作の例は、乱数の生成、ハッシュ化、コンテンツの署名、署名の検証、そしてもちろん暗号化と復号化です。
| 機能 | デスクトップ | モバイル |
|---|---|---|
CryptoGetRandomValues |
34.45% | 40.95% |
SubtleCryptoDigest |
2.65% | 2.98% |
CryptoAlgorithmSha256 |
2.36% | 2.48% |
SubtleCryptoImportKey |
1.29% | 1.68% |
CryptoAlgorithmEcdh |
0.97% | 1.39% |
CryptoAlgorithmSha512 |
0.17% | 0.32% |
CryptoAlgorithmSha1 |
0.21% | 0.26% |
CryptoAlgorithmAesCbc |
0.21% | 0.17% |
SubtleCryptoSign |
0.13% | 0.14% |
SubtleCryptoEncrypt |
0.13% | 0.12% |
CryptoAlgorithmHmac |
0.10% | 0.11% |
CryptoGetRandomValues 関数はこのAPIで最も広く使用されている機能のままですが、昨年と同様に使用が引き続き低下しています。モバイルでの使用は今年12%以上低下し、41%をわずかに下回っています。他の機能は引き続き上昇しており、2番目に人気の機能 SubtleCryptoDigest は1.2%増加して3%弱になっています。
ボット保護サービス
ボットはウェブに長い間存在しており、悪意のあるボットはその大きな部分を占めています。これらの問題のために、異なるベンダーによってウェブサイトをボットから保護するための多くの製品が作成されました。これらの製品の使用は今年も含めて年々増加し続けており、モバイルでの採用率が26.5%から31.1%に急増し、4.5%以上の上昇となっています。
reCAPTCHAが依然として最大のボット保護サービスであり続けていますが、Cloudflare Bot Managementはより急速に成長しており、ボット保護サービスを使用するウェブサイトの中でより大きな相対的なシェアを占めています。これらのトレンドが来年も続く場合、Cloudflare Bot ManagementがreCAPTCHAとの差を縮めるのを見るかもしれません。
HTMLサニタイゼーション
SetHTMLUnsafe と ParseHTMLUnsafe APIは、比較的最近のブラウザへの追加で、開発者はJavaScriptから宣言的なシャドウDOMを使用できます。
開発者が innerHTML を使用して宣言的シャドウDOMの定義（例：<template shadowrootmode="open">...</template>）を含むカスタムHTMLコンポーネントをページに配置しようとする場合、これは期待通りに機能しません。SetHTMLUnsafe または ParseHTMLUnsafe を使用することで、開発者は宣言的シャドウDOMがブラウザによって適切にインスタンス化されることを確認できます。
名前が示すように、開発者はこれらの「unsafe」APIに安全な値のみが渡されることを確認する責任があります。そうでない場合、開発者は危険なコンテンツがページに行き着くリスクを負い、XSS攻撃につながる可能性があります。
| 機能 | デスクトップ | モバイル |
|---|---|---|
ParseHTMLUnsafe |
19869 | 17147 |
SetHTMLUnsafe |
443 | 449 |
昨年以降、これらのAPIの使用が大幅に増加しています。モバイルでは、SetHTMLUnsafe を使用するページの数が2ページから449ページに増加し、ParseHTMLUnsafe を使用するページ数は今年6から17,147に増加しました。後者はクロールされたページの0.06%を占めるに過ぎませんが、興味深い変化であり、翌年も採用が増加し続けることが期待されます。ただし、これらのAPIが近い将来に広く普及することは予想されていません。
セキュリティ機構の採用促進要因
ウェブ開発者がより多くのセキュリティプラクティスを採用することを選ぶ理由はさまざまあります。最も注目すべきものには以下があります：
- 地理的要因: 地域によって、よりセキュリティ指向の教育や知識があるかもしれません。場合によっては、より厳格なセキュリティ衛生を義務付ける地域の法律がある場合もあります。
- 技術的要因: 使用する技術スタックはセキュリティ機構の採用に影響を与えることがあります。使用する技術によっては、開発者が意識して有効にしなくてもいくつかのセキュリティ機能がデフォルトで有効になります。
- 人気: 非常に人気のあるウェブサイトは、特定のサイバー攻撃の標的になりやすいため、セキュリティに大きな予算を持っている場合があります。さらに、これらのサイトはより多くのセキュリティ専門家や場合によってはバグバウンティハンターを引き付け、セキュリティ機能の実装と防御の強化を支援します。
ウェブサイトの所在地
ウェブサイトがホストされている場所や開発者が拠点を置いている場所は、特定のセキュリティ機能の採用に大きな影響を与えることがあります。開発者向けのセキュリティ教育は大きな役割を果たしており、開発者は自分が知らない機能や理解していない機能を実装することができません。さらに、地域の法律が特定のセキュリティプラクティスの採用を要求する場合があります。
HTTPSの採用は年々増加しており、幸いにも今年もこのトレンドが続いています。上位の国々でさえ採用率が数十分の一パーセントずつ増加し続けているのが見られます。下位の国々ではHTTPS採用率がやや大きく上昇し、日本は今や95%未満の採用率を持つ唯一の国となり、98%未満のHTTPS採用率を持つのはわずか5カ国で、非常に良好な結果です。今後数年で、下位の国々が上位の国々の採用率に徐々に追いつくことが期待されますが、完全な100%の採用は近い将来には難しそうです。
より複雑なセキュリティメカニズムを見ると、より多様な状況が見られます。ほとんどのリーダー国でわずかな採用の増加がある一方で、一部の下位国でこれらのポリシーの採用が減少しました。リーダー国はまだウェブサイトの4分の1強にCSPを設定しています。CSPとXFOの差は大きいままですが、わずかに上昇しており、昨年の15%ではなく最大14%にとどまっています。
テクノロジースタック
ウェブサイトのセキュリティは、使用する技術によって異なる場合があります。フレームワークにはデフォルトでセキュリティ機能が含まれており、大手ベンダーはユーザーをセキュアに保つことが利益になるため、これらの基盤技術を使用することでウェブサイトのセキュリティが向上する可能性があります。
| テクノロジー | セキュリティ機能 |
|---|---|
| LiveJournal | Content-Security-Policy (99.99%), Permissions-Policy (99.99%), Referrer-Policy (99.99%) |
| Weblium | X-Content-Type-Options (97.31%), X-XSS-Protection (97.31%) |
| GoDaddy Website Builder | Strict-Transport-Security (95.97%), Content-Security-Policy (95.97%) |
| Sitevision CMS | X-Frame-Options (81.54%) |
| Microsoft Sharepoint | X-Content-Type-Options (57.44%) |
| Liferay | X-Content-Type-Options (52.65%) |
多くのブログウェブサイトとウェブサイトビルダーが、HSTS、CSP、X-Content-Type-Options が最も人気のあるものの中に入る、いくつかの重要なセキュリティメカニズムをほぼすべてのシステムで設定していることが分かります。
ウェブサイトの人気
大規模なユーザーベースを持つ人気サイトは、ユーザーとその信頼を失わないように、最善の方法でユーザーを保護する十分な理由を持っていることが多いです。しばしば機密性の高いデータを保護しながら、より標的を絞った攻撃の対象になる可能性が高い中で、ウェブサイトのセキュリティへの多大な投資が必要ですが、そのトレードオフとして、より一般的にセキュアなウェブサイトにつながります。
X-Frame-OptionsやStrict-Transport-Securityなどのヘッダーに対して大幅に高い採用率を持つ明確なトレンドを示しています。例えば、X-Frame-Optionsの採用率は上位1,000サイトで60%を超えますが、すべてのサイトを合わせると約30%に低下します。X-Frame-Options、Strict-Transport-Security、X-Content-Type-Options、Content-Security-Policy などの最も人気のあるセキュリティヘッダーは、常にモバイルでより人気のあるウェブサイトでより高い採用率を示しています。最も広く採用されているヘッダーである X-Frame-Options は上位1,000サイトの67%で使用されていますが、ブラウザが訪問するすべてのサイトの30%でしか使用されていません。より人気のあるサイトとそうでないサイトの採用率の差は、昨年から事実上同じままであることが分かります。
ウェブサイトカテゴリー
業界によっては、ウェブサイトをよりセキュアに保つことに対してより多くの重要性が帰属される場合があります。ウェブサイトが設定するセキュリティヘッダーの平均数に基づいて、業界ごとのウェブサイトのセキュリティへの取り組みを推定しようとします。セキュリティヘッダーの数は必ずしもウェブサイトがより良くセキュアされているかどうかを示すわけではありませんが（セキュリティメカニズムは誤設定される可能性があります）、セキュリティ機能を実装するための取り組みの良い指標を提供します。
昨年からセキュリティヘッダーの平均数に大きな変化が見られます。 インターネット＆テレコム と コンピューター＆エレクトロニクス カテゴリーのサイトはより多くのセキュリティヘッダーを使用しています。特にモバイルクライアントではこれらのカテゴリーとの差が明確に見えます。これら2つのカテゴリーが良い意味での例外的なケースであるように見える一方で、他の業界のセキュリティヘッダーの平均数はほぼ同じままで、サイトあたり平均約0.1ヘッダーのわずかな変化があるだけです。
セキュリティヘッダーの観点でリードする2つの業界は、インターネットとコンピューターセキュリティの分野に関連した業界です。これらの業界ではセキュリティの関連性が高いため、これらのサイトの開発者は潜在的なリスクをより認識しており、特定のセキュリティメカニズムをより積極的に使用することが考えられます。
ウェブ上の不正行為
暗号通貨はこれまで以上に人気があります。暗号通貨マイニングは何年もの間大きなビジネスであり、攻撃者が被害者のウェブサイトにマルウェアの一形態として暗号マイナーをインストールすることが知られています。過去数年で、ウェブ上での暗号マイナーの使用は着実に減少しています。
暗号マイナーを持つページの数はモバイルでわずか37ページに減少しており、昨年から42%の減少です。これはまた、わずか3年前の2022年9月から83%の減少でもあります。
ウェブ上の暗号マイナーの絶対数は非常に少ないものの、異なる暗号マイナーが代表するシェアを確認します。昨年と比較して、Coinimpを持つページの数がJSEcoinを持つ9ページと一致するまで減少しています。興味深い点は、デスクトップとモバイルページの暗号マイナーの数の違いで、モバイルのページ数はデスクトップのほぼ2倍になっています。
セキュリティの誤設定と見落とし
ウェブとブラウザで利用可能なセキュリティメカニズムは数多くありますが、これらのメカニズムを正しく期待通りに設定することが不可欠です。誤設定されたセキュリティメカニズムは、ユーザーが保護されていると思っている開発者に偽りのセキュリティ感を生み出します。このセクションでは、ウェブサイトのセキュリティを損なう可能性のあるいくつかの誤設定の発生を強調します。
<meta>でサポートされていないポリシー
セキュリティポリシーを設定する際、開発者はポリシーをどのように定義すべきかを理解することが重要です。一部のポリシーはヘッダーとHTML <meta> タグの両方で定義できます。ただし、多くのポリシーは <meta> を通じて定義できません。開発者は時々、これらのポリシーを <meta> タグを通じて設定しようとする間違いを犯します。残念ながらブラウザはこれらのポリシーを無視し、非アクティブなセキュリティポリシーになります。
| ポリシー | デスクトップ | モバイル |
|---|---|---|
X-Frame-Options |
4,584 | 5,564 |
X-Content-Type-Options |
2,440 | 2,854 |
Permissions-Policy |
1,983 | 2,236 |
X-XSS-Protection |
1,691 | 1,702 |
Referrer-Policy |
1,630 | 1,644 |
<meta>を通じて誤って設定されたセキュリティポリシーの上位5件
モバイルサイトの約0.11%が、ブラウザが <meta> タグを通じて明示的にサポートしないセキュリティヘッダーを設定しようとしていることが分かります。最もよく試みられるポリシーは X-Frame-Options、X-Content-Type-Options、Permissions-Policy です。2024年と比較して、<meta> でこれらのポリシーを設定するモバイルサイトの数が絶対数で5,000ページ以上増加しており、これらの誤設定が開発者によってまだ積極的に設定されていることを示しています。
<meta>でサポートされていないCSPディレクティブ
CSPは <meta> タグを通じて設定 できます が、この動作はモバイルページの0.59%で観察されており、特定のCSPディレクティブは <meta> タグの実装では明示的に禁止されており、ブラウザに無視されます。これらのディレクティブは Content-Security-Policy レスポンスヘッダーを使用することでのみ設定できます。
| ディレクティブ | デスクトップ | モバイル |
|---|---|---|
frame-ancestors |
2.37% | 2.11% |
sandbox |
0.004% | 0.003% |
<meta>で定義されたCSPポリシーのうち禁止されたディレクティブを含む割合
<meta> タグを通じてCSPポリシーを設定するモバイルページの2%以上が frame-ancestors ディレクティブを含んでおり、0.003%が sandbox ディレクティブを含んでいることが分かります。後者はクロールされたデータセット全体でわずか3ページに相当します。前回版と比較して、frame-ancestors の誤設定は600ページ多く現れており、0.8%以上上昇しています。これはこの種の誤設定に対するゆっくりだが否定的な進展を表しています。
COOP/COEP/CORPの混同
クロスオリジンポリシーのCOEP、CORP、COOPは類似した命名を持ち、目的が関連しているため、開発者によって混同されることがあります。これらのヘッダーに誤った値を割り当てると、ブラウザはヘッダーがまったく提供されていないかのようにデフォルトのポリシーを適用し、開発者が望む追加の防御が無効になります。
| 無効なCOEP値 | デスクトップ | モバイル |
|---|---|---|
same-origin |
4.43% | 4.02% |
cross-origin |
0.55% | 0.46% |
* |
0.13% | 0.11% |
(unsafe-none|require-corp); report-to='default' |
0.09% | 0.11% |
: require-corp |
0.09% | 0.10% |
合計で、観察されたCOEPヘッダーの5.6%がモバイルで無効な値を含んでいます。これらのヘッダーの4%以上がCORPまたはCOOPヘッダーでのみ有効な値である same-origin を含んでいます。別の0.5%近くはCORPヘッダー用の値である cross-origin を含んでいます。残念ながら、これらの誤設定は昨年からも増加し、COEPヘッダーの same-origin 値で約1%上昇しました。
これらの誤設定に加えて、ブラウザが解析できないため、ヘッダーのデフォルト値に戻ることになる構文エラーを含むいくつかの値も観察しました。これらの構文エラーは少数のケースを表しています。
Timing-Allow-Originワイルドカード
Timing-Allow-Origin（TAO）レスポンスヘッダーはサーバーがResource Timing APIの機能を通じて取得した属性の値にアクセスできるオリジンのリストを指定できるようにします。このヘッダーにリストされたオリジンは、TCPコネクションの開始時間、リクエストの開始、レスポンスの開始など、サーバーへの接続に関する詳細なタイムスタンプにアクセスできます。このアクセスをオリジンに許可する際は、リストされたオリジンがタイミング攻撃や他のクロスサイト攻撃を実行する可能性が生まれるため、慎重に行う必要があります。
CORSが設定されている場合、上記のようなこれらの種類のタイミング値の多くはクロスオリジンリークを防ぐために0として返されます。Timing-Allow-Origin ヘッダーにオリジンをリストすることで、これらの値は元の値を保持し、ゼロアウトされなくなります。
Timing-Allow-Originヘッダーがワイルドカード（*）値に設定されている割合。
オリジンのリストを返すことに加えて、開発者は Timing-Allowed-Origin ヘッダーの値をワイルドカード文字 * に設定して、どのオリジンでもタイミング情報にアクセスできることを示すことができます。TAOヘッダーの84.6%がワイルドカード * 値を含んでおり、昨年から2%上昇していることが分かります。これは多くの開発者がきめ細かなタイミング情報を任意のオリジンに普遍的に公開することに問題がないことを示しています。
サーバー情報ヘッダーの抑制の欠如
ウェブサイトがサーバーとその特定バージョンなど、インフラについての過剰な情報を公開した場合、自動脆弱性スキャナーの標的になるリスクが高くなる可能性があります。この情報を非表示にすることはセキュリティ・バイ・オブスキュリティの一形態であり、システムのコアな脆弱性には対処しないため一般的に眉をひそめられる戦略ですが、特定の攻撃のレーダー下に留まるのに役立つ可能性があるため分析を含めます。
このような情報を報告するために一般的に使用されるヘッダー、すなわち：Server、X-Server、X-Backend-Server、X-Powered-By、X-Aspnet-Version の使用を追跡します。
Serverヘッダーは2025年に91.52%のサイトに現れるほぼ普遍的なままであり、X-Powered-Byヘッダーは23.99%で使用されています。X-Aspnet-Version、X-Server、X-Backend-Serverなどの他の特殊なヘッダーははるかに低い使用率を示しており、すべてのカテゴリーが3年間でわずかだが一貫した下降トレンドを示しています。過去の年と同様に、Server ヘッダーは X-Powered-By を大差で最も広く使用されているヘッダーであり続けています。これらのヘッダーはウェブ上のホストの91.5%と23.9%に表示されます。各ヘッダーについて、表示されるホストの数がわずかに減少しているのが見られます。多くのウェブ技術がこれらのヘッダーの一部を自動的に設定し、開発者はセキュリティ上の利点が小さいため、これらのヘッダーを削除することにあまり興味がないかもしれないため、これらの値が時間とともに大きく変化することは期待されません。
| ヘッダー値 | デスクトップ | モバイル |
|---|---|---|
PHP/7.4.33 |
9.54% | 9.98% |
PHP/7.3.33 |
3.61% | 4.29% |
PHP/5.3.3 |
2.10% | 2.20% |
PHP/5.6.40 |
2.07% | 2.12% |
PHP/8.0.30 |
1.55% | 1.70% |
PHP/7.2.34 |
1.34% | 1.41% |
PHP/8.2.28 |
1.15% | 1.31% |
PHP/8.3.13 |
1.08% | 1.11% |
PHP/8.1.32 |
1.05% | 1.09% |
PHP/8.1.27 |
0.92% | 1.06% |
X-Powered-Byヘッダー値
Server と X-Powered-By 値の中で最も一般的な値を確認すると、PHPが特に X-Powered-By ヘッダーでサーバー上で動作している正確なバージョンを公開する傾向があることが分かります。デスクトップとモバイルの両方で、X-Powered-By ヘッダーの27%以上がバージョン情報を含んでいることが分かります。ヘッダーはデータで観察されるプラットフォームによって自動的に返される可能性があります。興味深いことに、古いPHPバージョン7.xと低いバージョンのわずかな減少と、新しいPHPバージョン8.xのわずかな増加が見られ、少なくとも一部の開発者がサーバーをアップデートしていることの兆しです。
Server-Timingヘッダーの抑制の欠如
Server-Timing HTTPヘッダーはサーバーパフォーマンスメトリクスを通信するために使用できるW3C Editor’s Draftで定義されたレスポンスヘッダーです。開発者はゼロ以上のプロパティを含むメトリクスを送信できます。指定されたプロパティの一つは dur プロパティで、サーバー上の特定のアクションの持続時間を含むミリ秒精度のタイミングを通信するために使用できます。
Server-Timingヘッダーを含んでいることを示しています。個別のレスポンスではなくユニークなホストで測定した場合、採用率はわずかに低く、デスクトップホストの21%とモバイルホストの22%がこの機能を利用しています。Server-Timingヘッダーの使用状況。
server-timing ヘッダーを返すホストの割合は、クローラーが訪問したホストの5分の1以上で15%以上増加しました。これは昨年からの非常に急激な増加です。
Server-Timingヘッダー内の特定の期間メトリクスの普及率を示す棒グラフ。データはこれらのヘッダーのかなりの部分（デスクトップで43%、モバイルで42%）が少なくとも1つのdurプロパティを含んでいることを示しています。さらに、かなりの割合のホスト（デスクトップで29%、モバイルで27%）が2つ以上の別個の期間メトリクスを公開しています。Server-Timingヘッダーのdurプロパティの相対的な使用状況。
ウェブ上の server-timing ヘッダーのうち、42%が少なくとも1つの dur プロパティを持っていることが分かります。これは昨年と比較した場合の相対的な減少ですが、年間のヘッダー使用量の急激な増加を考えると、絶対数は増加しています。これはまた、より多くのヘッダーが dur プロパティを含まず、開発者が特定のメトリクスの説明を設定できる desc プロパティの使用などを通じて、ヘッダーを他の目的で使用していることを意味します。
server-timing ヘッダーに含まれる情報は機密性がある可能性があるため、値へのアクセスは同一オリジンと Timing-Allow-Origin ヘッダーにリストされたオリジンに制限されています。上述のように、多くのウェブサイトはワイルドカード文字で Timing-Allow-Origin を設定しており、潜在的に機密性の高い情報にすべてのオリジンがアクセスできるようにしています。クロスオリジンアクセスがなくても、ブラウザのコンテキスト外でサーバーが機密性の高いタイミング情報を公開している場合、タイミング攻撃をサーバーに直接実行することが可能です。
Well-known URI
Well-known URIはサイト全体のメタデータとサービスのための特定の場所を指定するための標準化されたメカニズムを提供します。RFC 8615で定義されているwell-known URIは、プレフィックス /.well-known/ で始まるパスコンポーネントによって識別されます。これにより、クライアントはサイトのURLスキームに関する事前知識がなくても特定のリソースを発見できます。
security.txt
よく知られているsecurity.txtファイルはウェブサイトが脆弱性報告情報を通信するために使用する標準化されたファイル形式です。ホワイトハットハッカーやペネトレーションテスターはこのファイルを使用して、責任ある開示のための連絡先詳細、PGPキー、ポリシー、その他の情報を見つけることができます。
security.txtファイル内のさまざまなフィールドの実装を示す棒グラフ。データは必須のcontactフィールドが最も広く採用されているプロパティで、ファイルの94%に現れていることを示しており、もう一つの必須フィールドexpiresは実装の約75%に存在します。preferred_language（72%）とhiring（37%）などの他の一般的なオプションフィールドに対して、encryption（9%）、signed（2%）、csaf（0%）などのより技術的または管理的なプロパティははるかに低い使用率です。全体的に、採用率はデスクトップとモバイルデバイスでほぼ同じです。security.txtプロパティの使用状況。
採用率はデスクトップで1.82%、モバイルサイトで1.72%に増加し、どちらも2024年の1%から上昇しており、標準化されたセキュリティ開示プラクティスへの認識が高まっていることを示しています。
security.txt を実装しているサイトの中では、連絡先情報がデスクトップで95%、モバイルで94%とほぼ普遍的に含まれており、2024年の92%と89%からそれぞれ上昇しています。興味深いことに、75%が有効期限を定義しており、2024年のデスクトップで51%、モバイルで48%から大幅に増加しています。優先言語は実装の70〜72%で指定されており、脆弱性報告手順を定義するポリシーはデスクトップで37%、モバイルファイルで34%にのみ現れており、2024年の39%から低下しています。ただし、ポリシーを定義する security.txt ファイルの絶対数は3分の2増加しました。
この分析は、security.txt ファイルの少なくとも25%が完全に有効ではないことを示しています。これはRFC 9116で規定されているように、連絡先情報とともに有効期限を含めることが必要だからです。
change-password
change-password well-known URIは2021年のW3C仕様草案で、それ以来更新されていません。このURIの目的は、ユーザーと外部リソースが特定のサイトのパスワードを変更できる正しい場所をすばやく見つけるためのものです。
/.well-known/change-passwordリダイレクトを実装しているウェブサイトの割合を示す棒グラフ。データはこの機能の非常に低い採用率を示しており、現在エンドポイントを利用しているデスクトップサイトはわずか0.30%、モバイルサイトは0.27%です。デスクトップサイトは0.27%から0.30%にわずかに上昇し、モバイルエンドポイントでは0.27%のまま変化がないことが分かります。この緩やかな採用は、すべてのウェブサイトが認証メカニズムを必要とするわけではないことを考えると、予想外ではありません。
ステータスコードの信頼性検出
ウェブサイトのHTTPレスポンスステータスコードの信頼性を確認するための仕様草案も2021年から変更されていません。この特定のwell-knownエンドポイントの目的は、それが決して存在してはならず、したがってレスポンスステータスコードが決してokステータスであってはならないというものです。サイトがokステータスで応答するリダイレクトが発生した場合、これは不正な動作とみなされます。
.well-known URIプレフィックスへのリクエストの成功率を示す積み上げ棒グラフ。データはこれらのリクエストの圧倒的多数（デスクトップで83%、モバイルで82%）が「not ok」ステータスになり、意図されたリソースが正常に取得または見つけられなかったことを示しています。対照的に、成功した200 OKレスポンスはリクエスト総数の約10%のみを占め、201〜299の範囲のステータスコードは追加の8%を占めています。.well-knownエンドポイントに返されるステータスの分布。
2022年版と2024年版のWeb Almanacと同様の結果が見られます。ただし、誤ったokステータスレスポンスの数はわずかに増加しており、2024年のデスクトップとモバイルページの両方で84%からそれぞれ83%と84%になっています。ウェブ開発者は、これらのステータスコードが意味を失わないようにするために、アプリケーションが受信リクエストに正しいステータスコードで応答し続けるようにする必要があります。
robots.txt内の機密エンドポイント
最後に、よく知られている robots.txt ファイルで機密エンドポイントがクローラーによる訪問を禁止されているかどうかを確認します。このファイルの禁止されたエンドポイントを確認することで、攻撃者は標的にするページを見つける可能性があります。今年は、デスクトップサイトの81%とモバイルサイトの80%が robots.txt ファイルをホストしており、昨年版のWeb Almanacと非常に似ています。
adminが最も頻繁に禁止されている機密用語で、デスクトップのrobots.txtファイルの4.29%に現れ、次いでaccountが2.96%です。login（1.73%）とauth（0.57%）などの他の用語も一般的に制限されており、signinとssoは出現率の0.05%未満です。robots.txtに含むサイトの割合。
これらのファイルの内容も非常に似ています。最大の増加はデスクトップサイトで auth エンドポイントの0.2%であり、最大の減少はデスクトップサイトで login エンドポイントの0.2%でした。
結論
このセキュリティチャプターはウェブセキュリティポリシーの採用において前向きなトレンドを示しています。HTTPSは全体的に100%近くの採用率に達しており、国別のメトリクスは全ての国がHTTPSの普遍的な使用という目標に向けて進んでいることを示しています。Content-Security-Policy は18%以上の使用増加、Permissions-Policy は昨年より50%多く使用されるなど、最新の攻撃からユーザーをより良く保護することを目的とした多くの最新セキュリティポリシーの採用が増加しているのが見られました。また、ドキュメントポリシーのような新しいポリシーが実際の環境に現れているのも見られ、開発者が新しいセキュリティ機能の採用に積極的に取り組んでいることを示しています。
これらの前向きなトレンドにもかかわらず、開発者はこれらのセキュリティメカニズムを活用する際に警戒を続けなければなりません。利用可能な多くのセキュリティメカニズムの複雑さの増大により、ウェブ上での誤設定の数が増加しているのが見られました。ページの0.1%がブラウザでサポートされていないにもかかわらず <meta> HTMLタグでセキュリティポリシーを設定していることが分かりました。もう一つの問題は関連する保護の間の混同です：COEPヘッダーの値の5%は、関連するCORPまたはCOOPヘッダーでのみ有効な無効値です。また、開発者の疲労のような形も観察されており、デプロイをより管理しやすくするか潜在的な問題を防ぐために、保護の最も緩やかな値が設定されています。例えば Timing-Allow-Origin ヘッダーのワイルドカード値はこれらのヘッダーの84%以上に現れています。幸い、開発者が問題を認識すれば、これらの問題を簡単に軽減できます。
将来の新しい攻撃は必然的に世界中のユーザーを安全に保つためのさらに多くの保護メカニズムの設計を推進するでしょう。政策立案者は開発者の混乱を避けるためにこれらの新しいメカニズムの複雑さを減らすことに焦点を当てる必要がありますが、新しいセキュリティ機能の採用に時間がかかる一方で、比較的新しいポリシーが採用され、時間とともに多くの採用を得ており、すべての人にとってより安全なウェブを生み出しています。
