あるべき姿一覧（100点満点の基準）
本ツールが確認している全22項目について、「何を確認しているのか」「100点状態（あるべき姿）」「なぜ重要か」「自社での確認方法」「改善の方向性」をまとめています。診断結果と合わせて、商談・社内検討の材料としてご活用ください。
Web基本対策
9項目HTTPS対応
確認していること
公式WebサイトURLに対してHTTPSで接続できるか、200系のステータスを返すか。
あるべき姿（100点状態）
Webサイトの全てのページがHTTPSで提供されており、HTTP/2以上が有効になっている。
なぜ重要か
通信内容の盗聴・改ざんを防ぐ最も基本的な対策。HTTPS非対応はブラウザの警告表示や検索順位低下にも直結する。
自社での確認方法
ブラウザのアドレスバーが鍵マークになっていることを確認。`https://`で問題なくアクセスできるか確認する。
改善の方向性
Webサーバーで有効なSSL/TLS証明書を導入し、全コンテンツをHTTPSで提供する。
HTTP→HTTPS転送
確認していること
HTTPアクセスがHTTPSに301/302リダイレクトされているか。
あるべき姿（100点状態）
HTTPでアクセスされた場合、サーバー側で必ずHTTPSへ301リダイレクトされる設定になっている。
なぜ重要か
HTTPアクセスが残っていると、初回接続時に通信内容が傍受されうる。HTTPSに強制誘導することでこのリスクを最小化する。
自社での確認方法
`http://example.com`にアクセスして、自動的に`https://`に切り替わるか確認する。
改善の方向性
Webサーバー設定（nginx/Apache等）でHTTP→HTTPSの恒久的リダイレクト（301）を設定する。
参照ソース（公的ガイドライン・標準）
SSL/TLS証明書
確認していること
証明書の有効性、有効期限、発行者、対象ホスト名の一致を確認する。
あるべき姿（100点状態）
公的認証局が発行する有効な証明書を使用し、有効期限まで十分な余裕があり、対象ドメインと一致している。
なぜ重要か
証明書の不正・期限切れはブラウザ警告で顧客の信頼を損なう。サイト全体の安全性に関わる根幹要素。
自社での確認方法
ブラウザの鍵アイコン→証明書情報で発行者・有効期限・対象ドメインを確認する。
改善の方向性
Let's Encryptや商用認証局で適切な証明書を取得し、自動更新を設定する。
HSTS
確認していること
`Strict-Transport-Security`レスポンスヘッダーの有無と設定値。
あるべき姿（100点状態）
`max-age=31536000`以上、`includeSubDomains`指定、可能であれば`preload`登録済み。
なぜ重要か
ブラウザにHTTPS接続のみを強制させ、ダウングレード攻撃や中間者攻撃に対する防御を強化する。
自社での確認方法
ブラウザの開発者ツール（Network）→対象リクエスト→Response Headersで`Strict-Transport-Security`を確認。
改善の方向性
Webサーバーで`Strict-Transport-Security: max-age=31536000; includeSubDomains`を追加する。
CSP（Content Security Policy）
確認していること
`Content-Security-Policy`ヘッダーの有無と読み込み元制限の状況。
あるべき姿（100点状態）
`default-src 'self'`を基準に、必要最小限のドメインのみ許可されたポリシーが定義されている。
なぜ重要か
XSS（クロスサイトスクリプティング）・データ改ざん・不正なスクリプト読み込みに対する強力な多層防御。
自社での確認方法
開発者ツール→Network→Response Headersで`Content-Security-Policy`を確認。
改善の方向性
段階的にCSPを導入する（最初は`Content-Security-Policy-Report-Only`で観測→本適用）。
X-Frame-Options
確認していること
`X-Frame-Options`ヘッダー（または同等のCSP `frame-ancestors`）の有無。
あるべき姿（100点状態）
`X-Frame-Options: DENY`または`SAMEORIGIN`、もしくはCSPで`frame-ancestors 'self'`が設定されている。
なぜ重要か
サイトを悪意ある第三者がiframeに埋め込むクリックジャッキング攻撃を防止する。
自社での確認方法
開発者ツール→Network→Response Headersで`X-Frame-Options`を確認。
改善の方向性
Webサーバーで`X-Frame-Options: SAMEORIGIN`またはCSPの`frame-ancestors`を設定する。
Referrer-Policy
確認していること
`Referrer-Policy`レスポンスヘッダーの有無と設定値。
あるべき姿（100点状態）
`strict-origin-when-cross-origin`または`no-referrer`が設定され、外部サイト遷移時にURLパス・クエリ情報が漏れない。
なぜ重要か
URLにセッション情報・トークン・個人識別情報を含むケースで、外部サイトへのリーク防止に直結する。
自社での確認方法
開発者ツール→Network→Response Headersで`Referrer-Policy`を確認。
改善の方向性
Webサーバーで`Referrer-Policy: strict-origin-when-cross-origin`を設定する。
参照ソース（公的ガイドライン・標準）
Permissions-Policy
確認していること
`Permissions-Policy`（旧Feature-Policy）ヘッダーの有無。
あるべき姿（100点状態）
カメラ・マイク・位置情報・支払い等の不要な機能が明示的に無効化されている。
なぜ重要か
iframe等から不要なブラウザAPIを呼び出される攻撃や、サードパーティスクリプトの権限濫用を防げる。
自社での確認方法
開発者ツール→Network→Response Headersで`Permissions-Policy`を確認。
改善の方向性
`Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()`等、用途に応じて設定する。
参照ソース（公的ガイドライン・標準）
Cookie属性（Secure/HttpOnly/SameSite）
確認していること
`Set-Cookie`ヘッダーに`Secure`・`HttpOnly`・`SameSite`属性が付与されているか。
あるべき姿（100点状態）
発行する全てのCookieに`Secure; HttpOnly; SameSite=Lax`以上が付与されており、セッションCookieは`SameSite=Strict`を推奨。
なぜ重要か
Cookie盗難（XSS経由）・通信傍受・CSRF攻撃に対する標準的な防御。属性欠落はOWASP Top 10にも該当する基本不備。
自社での確認方法
開発者ツール→Application→Cookiesで各Cookieの属性列を確認。
改善の方向性
アプリケーションのCookie発行コードで全Cookieに3属性を付与する。フレームワーク既定値の確認も推奨。
メール・ドメイン
3項目SPF
確認していること
メールドメインのTXTレコードに`v=spf1`から始まる有効なSPFが設定されているか。
あるべき姿（100点状態）
送信元として認可されたサーバーのみが指定され、末尾が`-all`（厳格）になっている。
なぜ重要か
送信元IPの正当性を受信側が検証可能になり、なりすましメールが受信者側で迷惑メール扱いされる確率が上がる。
自社での確認方法
`dig TXT example.com`または公開のSPFチェッカーで確認する。
改善の方向性
認可された送信サーバーのIPを指定するSPFレコードをDNSに登録する。
DKIM
確認していること
セレクタを使用するため外部公開情報からは直接判定できないが、送信メールヘッダーで確認可能。
あるべき姿（100点状態）
送信メールにDKIM署名が付与されており、受信側で署名検証に通る。
なぜ重要か
メールの改ざん検知と送信ドメイン認証ができ、なりすまし対策の中核を担う。
自社での確認方法
自社から自分にテストメールを送り、ヘッダーの`Authentication-Results`に`dkim=pass`が含まれるか確認する。
改善の方向性
メールサーバー（Microsoft 365 / Google Workspace / 自社SMTP）でDKIM署名鍵を設定し、DNSにセレクタTXTを登録する。
DMARC
確認していること
`_dmarc.example.com`のTXTレコードに`v=DMARC1`があり、ポリシー（p=）が`quarantine`または`reject`であるか。
あるべき姿（100点状態）
`v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com`のように、本番運用としてrejectまたはquarantine、レポート受信先まで設定されている。
なぜ重要か
なりすましメールを受信側でブロックでき、自社ドメインの悪用による顧客への被害・ブランド毀損を防げる。2024年以降Gmail・Yahoo!受信者向け一斉送信の必須要件にもなっている。
自社での確認方法
`dig TXT _dmarc.example.com`または公開のDMARCチェッカーで確認する。
改善の方向性
SPF・DKIM整備後、`p=none`からスタートしてレポートを観測し、段階的に`quarantine`→`reject`へ強化する。
公開情報管理
3項目プライバシーポリシー
確認していること
公式Webサイトに「プライバシーポリシー」「個人情報保護方針」等のページが公開されているか。
あるべき姿（100点状態）
個人情報の利用目的・第三者提供・保管期間・問い合わせ窓口が明記された方針が公式サイトのフッター等から1クリックで到達可能。
なぜ重要か
個人情報保護法（改正法）への対応の根幹であり、取引先・顧客への説明責任を果たすうえでも必須。
自社での確認方法
Webサイトのフッター・ヘッダー等から「プライバシーポリシー」ページに到達できるか確認する。
改善の方向性
公開テンプレートを参考に、自社の事業内容に合わせたプライバシーポリシーを整備し、フッターからリンクする。
情報セキュリティ方針
確認していること
「情報セキュリティ基本方針」「情報セキュリティポリシー」等の公開ページの有無。
あるべき姿（100点状態）
経営層が承認した情報セキュリティ基本方針が公式サイトで公開され、定期的に見直しの記録が更新されている。
なぜ重要か
取引先からのセキュリティチェックリスト対応、官公庁・大企業との取引において必須となる説明資料。SECURITY ACTION等の自己宣言制度の前提でもある。
自社での確認方法
Webサイト内検索や Google検索で「サイト名 情報セキュリティ方針」を確認する。
改善の方向性
経済産業省・IPAが公開する雛形をベースに自社向けに整備し、経営会議で承認後、公式サイトに掲載する。
問い合わせフォーム保護
確認していること
問い合わせフォームの存在と、reCAPTCHA等のスパム・自動送信対策の挙動。
あるべき姿（100点状態）
フォームはHTTPS提供、reCAPTCHA v3等の不正検知、送信レート制限、入力値バリデーションが実装されている。
なぜ重要か
問い合わせフォームはスパム送信・SQLインジェクション・大量送信の標的になりやすく、業務妨害や情報窃取の起点になる。
自社での確認方法
フォームページのHTMLソースで`recaptcha`等の記述を確認、または短時間に複数送信を試して制限がかかるか確認する。
改善の方向性
reCAPTCHAまたはhCaptchaを導入し、送信頻度制限・入力サニタイズを実装する。
参照ソース（公的ガイドライン・標準）
技術露出
3項目公開技術情報の露出
確認していること
Serverヘッダー・X-Powered-By・metaのgenerator・採用ページ等から、使用技術・バージョン情報が漏れていないか。
あるべき姿（100点状態）
サーバー種別やフレームワーク・バージョンが外部から判別できないよう設定され、採用ページにも特定可能な構成情報が記載されていない。
なぜ重要か
使用技術とそのバージョンが判ると、既知の脆弱性を狙ったピンポイント攻撃の対象になりやすくなる。
自社での確認方法
開発者ツール→NetworkのResponse Headersや、`view-source:`でHTMLメタタグを確認。採用情報も「技術スタック」記載をレビュー。
改善の方向性
Webサーバー設定でServerヘッダー・X-Powered-Byを削除/匿名化する。採用ページの技術スタック記載は粒度を調整する。
robots.txtの整備
確認していること
`/robots.txt`の存在、クローラー制御の意図、sitemap指定の有無。
あるべき姿（100点状態）
クローラーに公開してよい範囲が明示され、管理画面や非公開ディレクトリは`Disallow`で除外、sitemapが正しく指定されている。
なぜ重要か
robots.txtに非公開ディレクトリのパスを書きすぎると、逆に攻撃者にディレクトリ構造を教えてしまう。一方、未設置の場合はクローラーへの意図が示せず、SEOにも影響する。
自社での確認方法
ブラウザで`https://自社ドメイン/robots.txt`にアクセスし、内容と各ディレクティブを確認。
改善の方向性
公開してよい範囲のみを記載し、機密パスは記載しない方針で見直す。sitemap指定を追加する。
エラーページの技術情報露出
確認していること
存在しないパスへアクセスした際の404応答で、サーバー種別・フレームワーク名・スタックトレース等が露出していないか。
あるべき姿（100点状態）
カスタム404ページが用意され、技術スタック・バージョン・スタックトレースを一切含まない汎用的なメッセージのみ表示される。
なぜ重要か
エラー画面は攻撃者の偵察情報源として頻繁に活用される。スタックトレースが見えるとアプリケーション内部構造が判明し、攻撃難易度が大きく下がる。
自社での確認方法
ブラウザで存在しないパス（例：`/__test-404-xyz__`）にアクセスし、表示内容と開発者ツールのレスポンスを確認。
改善の方向性
本番環境ではデバッグモードを無効化し、汎用的なカスタム404・500ページを設置する。サーバーヘッダーも匿名化する。
運用体制
3項目情報セキュリティ基本方針の公開
確認していること
経営層が承認した情報セキュリティ基本方針が公開されているか。
あるべき姿（100点状態）
基本方針が公式サイトに掲載され、最終改訂日・承認者が明示されている。
なぜ重要か
情報セキュリティへの組織的コミットメントを社外に示し、取引先からの信頼を得るための土台。
自社での確認方法
公式サイトのフッターや会社概要セクションから到達できるか確認する。
改善の方向性
IPA等の雛形を参考に整備し、経営会議で承認後に公開する。
セキュリティ連絡窓口
確認していること
セキュリティに関する問い合わせ・脆弱性報告の連絡窓口が外部から確認できるか。
あるべき姿（100点状態）
`security@example.com`等の専用窓口が公開され、脆弱性情報の取り扱いポリシー（VDP）が明示されている。
なぜ重要か
外部の善意のセキュリティリサーチャーや取引先からの報告経路が明確になり、深刻な脆弱性の早期発見・対応が可能になる。
自社での確認方法
公式サイトに「security.txt」または「セキュリティ問い合わせ」窓口が存在するか確認する。
改善の方向性
`/.well-known/security.txt`を設置し、専用連絡先と対応ポリシーを公開する。
security.txt（脆弱性開示窓口）
確認していること
`/.well-known/security.txt`または`/security.txt`（RFC 9116準拠）の設置と必須フィールドの有無。
あるべき姿（100点状態）
RFC 9116準拠で設置され、`Contact:`（連絡先）と`Expires:`（有効期限）が記載されている。可能であれば`Policy:`（VDP文書のURL）・`Encryption:`（PGP鍵）も整備。
なぜ重要か
脆弱性情報の善意の報告窓口を一元化することで、攻撃者よりも先に修正対応に着手できる。BugBounty・取引先要請にも対応しやすくなる。
自社での確認方法
ブラウザで`https://自社ドメイン/.well-known/security.txt`にアクセスし、`Contact:`等の記載を確認する。
改善の方向性
`Contact: mailto:security@…`と`Expires: YYYY-MM-DDT00:00:00Z`を最低限含む`security.txt`を`/.well-known/`配下に設置する。
取引先説明力
1項目取引先へ提示可能な基本方針
確認していること
プライバシーポリシー・情報セキュリティ方針が揃って公開され、取引先のセキュリティチェックリストに即答できる状態か。
あるべき姿（100点状態）
両方針が公開済みで、加えてSECURITY ACTIONの二つ星宣言、ISMS等の認証取得状況も明示されている。
なぜ重要か
BtoB取引、特に大企業・官公庁案件では、契約前のセキュリティチェックで方針提示が求められる場面が多い。
自社での確認方法
「会社概要」「セキュリティ」「情報管理」等のセクションから両方針に到達できるか確認する。
改善の方向性
両方針を整備したうえで、SECURITY ACTION自己宣言や認証取得に進むロードマップを策定する。
本ページは「外部公開情報から確認できる範囲」の基準を整理したものです。
実際の情報セキュリティ運用には、内部ネットワーク・業務システム・アカウント管理・端末管理・委託先管理・社員教育等、本ツールでは確認していない領域も含まれます。詳細な評価をご希望の場合は、内部診断をご検討ください。