デモ用データを使用したサンプルレポートです。
Webサイトセキュリティ改善レポート
Webサイトセキュリティレポートのサンプル
株式会社サンプル小売(デモ) · www.client-shop.example
- レポートID
- DEMO-2026-0001
- 診断日
- 2026-10-01
- 再確認の診断日
- 2026-10-08
- 作成者
- NeoShieldSecurity QUANTUM X 制作会社ブランド:準備中
サンプル PDF レポートをダウンロード 同じ内容を顧客向け PDF にしたものです。表紙、エグゼクティブサマリー、検出項目、プラットフォーム別の修正方法、改善スケジュールを含みます。
現在のレポートには NeoShield のブランドが入ります。制作会社のブランド表示は準備中です。 このページの名前、検出項目、スコアはすべて架空の顧客のデモデータです。
エグゼクティブサマリー
観測された設定スコア
55/100 · 評価 D
修正確認後:100点中73点、評価 C
このスコアは、この診断で完了した、公開されている設定のチェックだけを対象にしています。アプリケーションの脆弱性や全体的なビジネスリスクを測るものではありません。
対応が必要
重要度の内訳
高 1 · 中 3 · 低 2
未対応 4件 ・ 修正確認済み 2件 ・ 合格したチェック 11件
ビジネスにとっての意味
Webサイトは有効な証明書による HTTPS で利用できますが、ブラウザのセキュリティ対策がいくつか不足しています。未対応の主な課題は、多層防御の対策である Content-Security-Policy が設定されていないことと、セッション Cookie に Secure と HttpOnly の属性がないことです。2件は修正され、2026-10-08 の確認スキャンで確認されました。残る4件は、設定例とともに優先度順に記載しています。
技術的な概要
公開されている HTTP レスポンスヘッダー、TLS 設定、Cookie、リダイレクト、メール認証の DNS レコード、よく公開されてしまうパスを対象とした受動的な診断です。検出項目6件(高1件、中3件、低2件)、修正確認済み2件、合格したチェック11件。DKIM は未評価です(セレクターの指定なし)。
優先順位別の検出項目
検出項目、証拠、改善方法
F-01 Content-Security-Policy ヘッダーが設定されていない 中
- 検出項目ID
- DEMO-2026-0001-F-01 · ルール csp
- 確度
- 高
- 対象URL
- https://www.client-shop.example/
- 検出方法
- HTTP レスポンスヘッダーの受動的な確認(GET /、リダイレクト追従)。
- 証拠
- GET / は HTTP/2 200 を返し、Content-Security-Policy ヘッダーも Content-Security-Policy-Report-Only ヘッダーもありませんでした。 (確認日時 2026-10-01T09:14:05Z)
- ビジネスへの影響
- Content Security Policy がない場合、コンテンツインジェクションやクロスサイトスクリプティングの脆弱性が悪用されたときに、その影響を抑えるためにブラウザが適用できる制限が少なくなります。 プラグインなどを通じてスクリプトインジェクションの欠陥が生じた場合に、注入されたコードが読み込んだり送信したりできる内容を制限する、ブラウザ側の対策がありません。
- 技術的な影響
- ブラウザによる script-src、object-src、base-uri、frame-ancestors の制限が適用されていません。
- 制約事項
- Content Security Policy がないことだけで、Webサイトにクロスサイトスクリプティングの脆弱性があると証明されるわけではありません。CSP は多層防御のための対策です。
- 改善方法
- まずレポート専用のポリシーで始め、レポートを確認してから適用します。
- 確認の基準
- 再診断で、スクリプトの読み込み元を制限する強制モードの Content-Security-Policy ヘッダーが確認されること。レポート専用ポリシーの場合は一部解決として記録されます。
- 確認状況
- 検証のための再スキャンでも引き続き観測されました
- ステータス
- 新規
- 参考資料
- developer.mozilla.org · owasp.org
設定例
プラットフォーム別の設定例
Nginx
# server { } block (or http { })
add_header Content-Security-Policy-Report-Only "default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'" always;まず Report-Only モードで始め、ページで実際に使っている読み込み元を追加してから、ヘッダー名を Content-Security-Policy に変えて適用します。 反映:nginx -t && systemctl reload nginx。location ブロック内の add_header は、server レベルで設定したヘッダーを置き換えます。
Apache HTTP Server
# Requires mod_headers (a2enmod headers)
Header always set Content-Security-Policy-Report-Only "default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'"まず Report-Only モードで始め、ページで実際に使っている読み込み元を追加してから、ヘッダー名を Content-Security-Policy に変えて適用します。 VirtualHost または .htaccess に記述し、apachectl configtest を実行してから再読み込みします。
Microsoft IIS
<?xml version="1.0" encoding="utf-8"?>
<!-- web.config: merge into the existing <configuration> element -->
<configuration>
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Content-Security-Policy-Report-Only" value="default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'" />
</customHeaders>
</httpProtocol>
</system.webServer>
</configuration>まず Report-Only モードで始め、ページで実際に使っている読み込み元を追加してから、ヘッダー名を Content-Security-Policy に変えて適用します。 この web.config を持つサイトまたはアプリケーションに適用されます。
Cloudflare
Rules > Transform Rules > Modify Response Header > Create rule
1. Apply to: All incoming requests (or this hostname)
2. Action: Set static
3. Header name: Content-Security-Policy-Report-Only
4. Value: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'
5. Deployまず Report-Only モードで始め、ページで実際に使っている読み込み元を追加してから、ヘッダー名を Content-Security-Policy に変えて適用します。 Cloudflare は、プロキシ経由(オレンジクラウド)の通信に対してのみエッジでヘッダーを設定します。
WordPress
<?php
// In a small site-specific plugin (or the child theme's functions.php)
add_action( 'send_headers', function () {
header(
"Content-Security-Policy-Report-Only: "
. "default-src 'self'; "
. "object-src 'none'; "
. "base-uri 'self'; "
. "frame-ancestors 'self'"
);
} );まず Report-Only モードで始め、ページで実際に使っている読み込み元を追加してから、ヘッダー名を Content-Security-Policy に変えて適用します。 ヘッダーは Web サーバーまたは CDN で設定するのが望ましく、これは WordPress しか操作できない場合の方法です。
AWS CloudFront
CloudFront > Policies > Response headers > Create response headers policy
1. Security headers or Custom headers: add Content-Security-Policy-Report-Only = default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'
2. Origin override: enabled
3. Attach the policy to the distribution's cache behavior(s)まず Report-Only モードで始め、ページで実際に使っている読み込み元を追加してから、ヘッダー名を Content-Security-Policy に変えて適用します。 変更は数分以内にすべてのエッジロケーションに反映されます。
設定の変更は、本番環境に反映する前にステージング環境で検証してください。ポリシーに誤りがあると、スクリプト、サインイン、購入手続き、埋め込みサービス、アクセス解析、外部サービスとの連携が動作しなくなる場合があります。
参考資料: MDN: Content-Security-Policy · OWASP Content Security Policy Cheat Sheet
F-03 セッション Cookie に Secure と HttpOnly 属性がない 中
- 検出項目ID
- DEMO-2026-0001-F-03 · ルール cookies
- 確度
- 高
- 対象URL
- https://www.client-shop.example/
- 検出方法
- 公開ページの Set-Cookie ヘッダーの受動的な確認。
- 証拠
- Set-Cookie: PHPSESSID=[redacted]; path=/ (確認日時 2026-10-01T09:14:05Z)
- ビジネスへの影響
- Secure がないと Cookie が暗号化されていない HTTP で送信されることがあり、HttpOnly がないとページ内のスクリプトから読み取れます。 ログイン中のお客様のセッション盗用やアカウント乗っ取りのリスクが高まります。
- 技術的な影響
- セッション ID がページ内のスクリプトから読み取れ、平文の HTTP で送信される可能性があります。
- 制約事項
- 受動的な診断で確認できるのは、公開ページで設定される Cookie だけです。
- 改善方法
- セッション Cookie に Secure、HttpOnly、SameSite=Lax を設定します。
- 確認の基準
- 再診断で、セッション Cookie に Secure と HttpOnly の属性が確認されること。
- 確認状況
- 検証のための再スキャンでも引き続き観測されました
- ステータス
- 修正予定
- 参考資料
- developer.mozilla.org
設定例
プラットフォーム別の設定例
Nginx
# When Nginx proxies an application (nginx 1.19.3+)
proxy_cookie_flags ~ secure httponly samesite=lax;プロキシ先のアプリケーションが設定する Cookie に適用されます。アプリケーション自体で属性を修正するのが望ましい方法です。
Apache HTTP Server
# Requires mod_headers. Prefer fixing the application; use this as a stopgap.
Header edit Set-Cookie "(?i)^((?:(?!;\s?HttpOnly).)+)$" "$1; HttpOnly"
Header edit Set-Cookie "(?i)^((?:(?!;\s?Secure).)+)$" "$1; Secure"各ルールは、属性がない場合にのみ追加します。アプリケーションが設定する Cookie に適用されるよう、"always" ではなく "Header edit" を使ってください。ログインが引き続き動作することを確認してください。
Microsoft IIS
<?xml version="1.0" encoding="utf-8"?>
<!-- web.config (ASP.NET): merge into the existing <configuration> element -->
<configuration>
<system.web>
<httpCookies requireSSL="true" httpOnlyCookies="true" sameSite="Lax" />
</system.web>
</configuration>sameSite 属性には .NET Framework 4.7.2 以降が必要です。
WordPress
; php.ini (or .user.ini) for the PHP session cookie
session.cookie_secure = 1
session.cookie_httponly = 1
session.cookie_samesite = "Lax"WordPress 自身のログイン Cookie は、HTTPS のサイトではすでに HttpOnly と Secure が付いています。独自の Cookie を設定するプラグインは更新が必要な場合があります。
設定の変更は、本番環境に反映する前にステージング環境で検証してください。ポリシーに誤りがあると、スクリプト、サインイン、購入手続き、埋め込みサービス、アクセス解析、外部サービスとの連携が動作しなくなる場合があります。
参考資料: MDN: Set-Cookie · OWASP Session Management Cheat Sheet
F-04 クリックジャッキング対策がない 中
- 検出項目ID
- DEMO-2026-0001-F-04 · ルール xfo
- 確度
- 高
- 対象URL
- https://www.client-shop.example/
- 検出方法
- HTTP レスポンスヘッダーの受動的な確認。
- 証拠
- X-Frame-Options も CSP の frame-ancestors ディレクティブも返されませんでした。 (確認日時 2026-10-01T09:14:05Z)
- ビジネスへの影響
- ほかのWebサイトが、これらのページを見えないフレームに読み込み、訪問者をだましてクリックさせることができます。 訪問者が、アカウント設定の変更など意図しない操作をさせられるおそれがあります。
- 技術的な影響
- ページを別オリジンのフレームに埋め込むことができます。
- 改善方法
- X-Frame-Options: SAMEORIGIN、または CSP の frame-ancestors 'self' を送信します。
- 確認の基準
- 再診断で、X-Frame-Options(DENY または SAMEORIGIN)または CSP の frame-ancestors ディレクティブが確認されること。
- 確認状況
- 検証のための再スキャンでも引き続き観測されました
- ステータス
- 確認中
- 参考資料
- developer.mozilla.org
設定例
プラットフォーム別の設定例
Nginx
# server { } block (or http { })
add_header X-Frame-Options "SAMEORIGIN" always;すでに Content-Security-Policy を送信している場合は、frame-ancestors 'self' を追加すると、最新のブラウザで同じ保護が得られます。 反映:nginx -t && systemctl reload nginx。location ブロック内の add_header は、server レベルで設定したヘッダーを置き換えます。
Apache HTTP Server
# Requires mod_headers (a2enmod headers)
Header always set X-Frame-Options "SAMEORIGIN"すでに Content-Security-Policy を送信している場合は、frame-ancestors 'self' を追加すると、最新のブラウザで同じ保護が得られます。 VirtualHost または .htaccess に記述し、apachectl configtest を実行してから再読み込みします。
Microsoft IIS
<?xml version="1.0" encoding="utf-8"?>
<!-- web.config: merge into the existing <configuration> element -->
<configuration>
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="X-Frame-Options" value="SAMEORIGIN" />
</customHeaders>
</httpProtocol>
</system.webServer>
</configuration>すでに Content-Security-Policy を送信している場合は、frame-ancestors 'self' を追加すると、最新のブラウザで同じ保護が得られます。 この web.config を持つサイトまたはアプリケーションに適用されます。
Cloudflare
Rules > Transform Rules > Modify Response Header > Create rule
1. Apply to: All incoming requests (or this hostname)
2. Action: Set static
3. Header name: X-Frame-Options
4. Value: SAMEORIGIN
5. Deployすでに Content-Security-Policy を送信している場合は、frame-ancestors 'self' を追加すると、最新のブラウザで同じ保護が得られます。 Cloudflare は、プロキシ経由(オレンジクラウド)の通信に対してのみエッジでヘッダーを設定します。
WordPress
<?php
// In a small site-specific plugin (or the child theme's functions.php)
add_action( 'send_headers', function () {
header(
"X-Frame-Options: "
. "SAMEORIGIN"
);
} );すでに Content-Security-Policy を送信している場合は、frame-ancestors 'self' を追加すると、最新のブラウザで同じ保護が得られます。 ヘッダーは Web サーバーまたは CDN で設定するのが望ましく、これは WordPress しか操作できない場合の方法です。
AWS CloudFront
CloudFront > Policies > Response headers > Create response headers policy
1. Security headers > X-Frame-Options: SAMEORIGIN
2. Origin override: enabled
3. Attach the policy to the distribution's cache behavior(s)すでに Content-Security-Policy を送信している場合は、frame-ancestors 'self' を追加すると、最新のブラウザで同じ保護が得られます。 変更は数分以内にすべてのエッジロケーションに反映されます。
設定の変更は、本番環境に反映する前にステージング環境で検証してください。ポリシーに誤りがあると、スクリプト、サインイン、購入手続き、埋め込みサービス、アクセス解析、外部サービスとの連携が動作しなくなる場合があります。
参考資料: MDN: X-Frame-Options · OWASP Clickjacking Defense Cheat Sheet
F-06 サーバーソフトウェアのバージョンが表示されている 低
- 検出項目ID
- DEMO-2026-0001-F-06 · ルール server_banner
- 確度
- 中
- 対象URL
- https://www.client-shop.example/
- 検出方法
- Server と X-Powered-By レスポンスヘッダーの受動的な確認。
- 証拠
- Server: Apache/2.4.41 (Ubuntu)
X-Powered-By: PHP/7.4.3 (確認日時 2026-10-01T09:14:05Z) - ビジネスへの影響
- 正確なバージョン番号があると、既知の脆弱性とサイトを照合しやすくなります。 新しい脆弱性が公表されたときに、攻撃者がこのサイトを優先的に狙う手がかりになります。
- 技術的な影響
- ソフトウェア名とバージョンがすべての訪問者に公開されています。
- 制約事項
- バージョン表示は正確でない場合があります。ディストリビューションでは、バージョン表記を変えずにセキュリティ修正を取り込むことがよくあります。
- 改善方法
- Web サーバーと PHP の設定でバージョン情報を隠し、両方を最新に保ちます。
- 確認の基準
- 再診断で、Server と X-Powered-By ヘッダーにバージョン番号が確認されないこと。
- 確認状況
- 検証のための再スキャンでも引き続き観測されました
- ステータス
- 新規
- 参考資料
- owasp.org
設定例
プラットフォーム別の設定例
Nginx
# http { } block
server_tokens off;バージョン番号は隠れますが、Server ヘッダーには "nginx" と表示されたままです。
Apache HTTP Server
# Main server configuration (not .htaccess)
ServerTokens Prod
ServerSignature OffServer ヘッダーが "Apache" だけになります。X-Powered-By は php.ini で expose_php = Off を設定します。
Microsoft IIS
<?xml version="1.0" encoding="utf-8"?>
<!-- web.config, IIS 10 (version 1709+): merge into the existing <configuration> element -->
<configuration>
<system.webServer>
<security>
<requestFiltering removeServerHeader="true" />
</security>
<httpProtocol>
<customHeaders>
<remove name="X-Powered-By" />
</customHeaders>
</httpProtocol>
</system.webServer>
</configuration>removeServerHeader は IIS 10 バージョン 1709 以降で利用できます。
WordPress
; php.ini (or .user.ini): removes the X-Powered-By: PHP/x.y header
expose_php = OffServer ヘッダー自体は、WordPress ではなく Web サーバー(Nginx または Apache)が制御します。
設定の変更は、本番環境に反映する前にステージング環境で検証してください。ポリシーに誤りがあると、スクリプト、サインイン、購入手続き、埋め込みサービス、アクセス解析、外部サービスとの連携が動作しなくなる場合があります。
F-02 Strict-Transport-Security ヘッダーがない 高
- 検出項目ID
- DEMO-2026-0001-F-02 · ルール hsts
- 確度
- 高
- 対象URL
- https://www.client-shop.example/
- 検出方法
- HTTPS での HTTP レスポンスヘッダーの受動的な確認。
- 証拠
- HTTPS は利用できますが、応答に Strict-Transport-Security ヘッダーがありません。 (確認日時 2026-10-01T09:14:05Z)
- ビジネスへの影響
- HSTS は、このサイトでは常に HTTPS を使うようブラウザに指示し、最初のリクエストが HTTP に格下げされる余地をなくします。 信頼できないネットワークの訪問者が、安全でないサイトに誘導されるおそれがあります。
- 技術的な影響
- サイトへの最初の平文 HTTP リクエストが、ブラウザによって HTTPS に切り替えられません。
- 改善方法
- すべてのサブドメインで HTTPS が安定したら、max-age を1年以上にした Strict-Transport-Security を送信します。
- 確認の基準
- 再診断で、HTTPS レスポンスに max-age が 31536000 以上の Strict-Transport-Security が確認されること。
- 確認状況
- 2026-10-08 の再診断で修正を確認
- ステータス
- 解決
- 参考資料
- developer.mozilla.org
F-05 X-Content-Type-Options ヘッダーがない 低
- 検出項目ID
- DEMO-2026-0001-F-05 · ルール xcto
- 確度
- 高
- 対象URL
- https://www.client-shop.example/
- 検出方法
- HTTP レスポンスヘッダーの受動的な確認。
- 証拠
- 応答に X-Content-Type-Options ヘッダーがありません。 (確認日時 2026-10-01T09:14:05Z)
- ビジネスへの影響
- ブラウザがファイルの種類を推測し、アップロードされたテキストをスクリプトとして扱うおそれがあります。 単独での影響は小さいものの、コンテンツタイプの取り違えに対する防御が一層なくなります。
- 技術的な影響
- MIME タイプの推測(スニッフィング)が無効化されていません。
- 改善方法
- X-Content-Type-Options: nosniff を送信します。
- 確認の基準
- 再診断で X-Content-Type-Options: nosniff が確認されること。
- 確認状況
- 2026-10-08 の再診断で修正を確認
- ステータス
- 解決
- 参考資料
- developer.mozilla.org
合格したチェック
- 信頼されたチェーンを持つ有効な TLS 証明書
- 証明書の有効期限に余裕あり(残り74日)
- HTTP は HTTPS にリダイレクト
- 診断したページに混在コンテンツなし
- Referrer-Policy あり
- Permissions-Policy あり
- 重複または矛盾するセキュリティヘッダーなし
- よく公開されてしまうファイル(.git、.env、バックアップ)は見つかりませんでした
- security.txt を公開
- SPF レコードあり
- DMARC レコードあり
範囲と方法
- 対象:https://www.client-shop.example/(公開Webサイト1件、ルートドメインと www)
- 方法:公開ページへの非侵入的なリクエストと DNS の照会
- 許可:診断前にアカウント所有者が確認済み
- 確認項目:HTTP セキュリティヘッダー、TLS と証明書、Cookie、HTTP から HTTPS へのリダイレクト、SPF、DMARC、security.txt、よく公開されてしまうファイル
制約
- これは受動的な設定診断であり、ペネトレーションテストではありません。
- ログイン後の領域、アプリケーションのロジック、インジェクションの不具合、業務ロジックの問題は診断していません。
- 結果は診断時に確認した応答に基づきます。CDN やロードバランサーにより、ほかの訪問者には異なるヘッダーが返される場合があります。
- 設定例は、本番に反映する前にステージング環境で検証してください。
顧客Webサイトでこのレポートを作成
無料診断では、スコアと最大3件の詳細な検出項目を確認できます。Pro では、PDF・CSV出力、修正の再確認、監視を含む完全なレポートを作成できます。