ハッキングせずにできるウェブサイトのセキュリティチェック

ECサイト向けのパッシブなセキュリティチェック。TLS証明書の有効期限、HSTS、CSP、nosniff、Cookie属性、混在コンテンツ、古いjQuery、security.txt、DMARCを確認します。

FixReports 編集部2分で読めます

ECサイトのセキュリティ設定の多くは、サイトがすべての訪問者にすでに送っている情報を読むだけで、外部から確認できます。TLS証明書、リダイレクト、HTTPレスポンスヘッダー、Cookie、読み込んでいるスクリプト、公開DNSレコードです。こうしたパッシブ（受動的）なチェックは攻撃のための通信を一切送らず、ログインも不要なので、ストアにかかる負荷は通常の訪問と変わりません。有効期限が迫った証明書、HSTSの未設定、安全でないCookie、混在コンテンツ、既知の脆弱性があるバージョンのjQueryといった設定の不備を見つけられます。ただし、ペネトレーションテスト（侵入テスト）ではなく、ストアが安全であることを証明するものでもありません。

要点

どのようなものがパッシブなセキュリティチェックにあたりますか？

パッシブなチェックとは、通常のリクエストに対してサイトやDNSが返す内容を読むだけのものです。

具体的には、公開ページを読み込む、証明書とレスポンスヘッダーを読む、ページが設定するCookieとスクリプトを一覧にする、公開DNSレコードを照会する、といった作業です。パスワードを推測したり、インジェクションのペイロードを送ったり、管理画面のURLを探ったり、ポートスキャンをしたりはしません。以下の内容はすべて、ブラウザー、curl、openssl、digで実施できます。

TLS証明書とその有効期限はどう確認しますか？

証明書の日付と名前を直接読み取り、更新が自動化されていることを確認します。

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

notAfterが十分に先の日付であること、example.comとwww.example.comの両方を使っている場合は証明書が両方をカバーしていること（ブラウザーの証明書ビューアーで名前の一覧を確認できます）、ブラウザーに警告が表示されないことを確認します。証明書の有効期間は、2025年4月11日に採択されたBallot SC-081v3 （新しいタブで開きます）に基づき、CA/Browser ForumのBaseline Requirements（セクション6.3.2、2026年10月時点でバージョン2.3.1）のもとで短縮されつつあります。

証明書の発行日最大有効期間
2026年3月15日より前398日
2026年3月15日から2027年3月14日まで200日
2027年3月15日から2029年3月14日まで100日
2029年3月15日以降47日

有効期間が短いと手動での更新はリスクが高くなるため、ホスティング会社や証明書ツールが自動で更新する設定になっているか確認してください。あわせて、平文のHTTPがHTTPSにリダイレクトされることも確認します。

curl -sI http://example.com/ | grep -i -E "^HTTP|^location"

locationヘッダーがhttps://で始まる301（または308）のレスポンスが返れば問題ありません。

ECサイトはどのセキュリティヘッダーを送信すべきですか？

少数のレスポンスヘッダーで、ブラウザー側でよくある攻撃を、ほとんどコストをかけずに防げます。

ヘッダー役割一般的な値出典
Strict-Transport-SecurityブラウザーにHTTPSだけを使うよう指示し、ユーザーが証明書エラーを無視して先に進めないようにしますmax-age=31536000; includeSubDomainsMDN （新しいタブで開きます）
Content-Security-Policy: frame-ancestorsどのサイトがページを埋め込めるかを制御し、クリックジャッキングを防ぎますframe-ancestors 'self'MDN （新しいタブで開きます）
X-Frame-Options従来のフレーム制御。OWASPによると、対応ブラウザーではframe-ancestorsに取って代わられていますDENYまたはSAMEORIGINOWASP （新しいタブで開きます）
X-Content-Type-OptionsMIMEスニッフィングを止め、誤ったタイプで配信されたスクリプトやスタイルシートをブロックしますnosniffMDN （新しいタブで開きます）
Referrer-Policyほかのサイトに送られるURL情報の量を制限しますstrict-origin-when-cross-originOWASP
X-XSS-ProtectionブラウザーのXSSフィルター用のヘッダー。OWASPによると、本来は安全なサイトにXSS脆弱性を生むことがあります設定しない、または0OWASP

ストアが送信している内容を確認します。

curl -sI https://example.com/

Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Security-Policy: frame-ancestors 'self'
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin

注意点が2つあります。includeSubDomainsは、HTTPでしか動作しないサブドメインをすべてブロックするため、先にサブドメインを確認してください。HSTSのプリロードには、31536000以上のmax-ageとincludeSubDomainsが必要なので、preloadはすべてのサブドメインがHTTPSに対応してから追加します。スクリプトを制限する本格的なCSPは導入する価値がありますが、OWASPは設定と保守が複雑だと指摘しており、多くのアプリを入れているストアでは慎重にテストする必要があります。

CookieにはSecure、HttpOnly、SameSiteが設定されていますか？

セッションやカートのCookieには3つの属性すべてが必要で、Set-Cookieレスポンスヘッダーで確認できます。

属性効果（MDN （新しいタブで開きます）による）重要になる場面
SecureHTTPS経由でのみ送信されます。平文のHTTPのサイトでは設定できませんHTTPSのストアのすべてのCookie
HttpOnlyJavaScriptからdocument.cookieで読み取れなくなり、XSS対策になりますログインセッションとカート
SameSite=LaxまたはStrictクロスサイトのリクエストでCookieが送信される場面を制限しますセッション。Strictは認証用とカート用のCookieに適しています
SameSite=Noneクロスサイトのリクエストでも送信されます。Secureとの併用が必須ですそれを必要とする、埋め込み型のサードパーティ機能だけ

SameSite属性が設定されていない場合、ブラウザーはそのCookieをLaxとして扱います。自社のスクリプトで読み取る必要があるCookieはHttpOnlyにできないため、ログイン中の顧客や管理者を識別するCookieに重点を置いてください。

curl -sI https://example.com/ | grep -i "^set-cookie"

ブラウザーの開発者ツールでも同じ情報を確認でき、ページの読み込み後にスクリプトが設定したCookieも表示されます。

混在コンテンツはどう見つけますか？

混在コンテンツとは、HTTPSで配信されるページ上でHTTP経由で読み込まれるリソースのことで、ブラウザーのコンソールに一覧表示されます。

MDN （新しいタブで開きます）は、混在コンテンツを2つのグループに分けています。画像、音声、動画は「アップグレード可能」で、ブラウザーが自動的にHTTPSでリクエストします。スクリプト、スタイルシート、iframe、フォント、fetch()リクエストは「ブロック可能」で、ブラウザーがブロックするため、それに依存していた部分が動かなくなります。IPアドレスを直接指定したリクエストは、アップグレードされてもブロックされます。

見つけるには、主要なテンプレート（トップ、コレクション、商品、カート）でコンソールを開き、テーマのコード、ページのコンテンツ、アプリの設定からhttp://を検索します。Shopifyのヘルプセンターは、HTTPSで配信されていないアセットを含むストアのページは安全でないと見なされる （新しいタブで開きます）としており、アセットをShopifyでホストするか、HTTPSで配信するよう推奨しています。WooCommerceでは、サイトが過去にhttp://で運用されていた場合、古い投稿のコンテンツやテーマのオプションを確認してください。

既知のCVEがある古いJavaScriptライブラリはどう見つけますか？

各ページが読み込むライブラリを一覧にしてバージョンを確認し、National Vulnerability Database（NVD）と照合します。

まずはjQueryから始めます。ブラウザーのコンソールで$.fn.jqueryを実行すると、読み込まれているバージョンが返ります（jQuery API （新しいタブで開きます））。注意すべきバージョンは次のとおりです。

CVE影響を受けるバージョン問題NVDスコア（v3.1）
CVE-2020-11022 （新しいタブで開きます）1.12.0以上3.5.0未満.html()や.append()などのメソッドに信頼できないHTMLを渡すと、コードが実行されるおそれがあります6.1 Medium
CVE-2020-11023 （新しいタブで開きます）1.0.3以上3.5.0未満同様の問題で、<option>要素を含むHTMLが対象。2025年1月23日からCISAのKEVカタログに掲載6.1 Medium
CVE-2019-11358 （新しいタブで開きます）3.4.0未満jQuery.extend(true, ...)によるプロトタイプ汚染6.1 Medium

2020年の2つの問題は、いずれもjQuery 3.5.0で修正されています。脆弱なバージョンであることは、欠陥のあるコードが存在することを意味します。実際に悪用できるかどうかは、サイトがそのコードにどのようにデータを渡しているかによります。WordPressはバージョン5.6以降 （新しいタブで開きます）jQuery 3.5.1を同梱しているため、WooCommerceのストアで古いjQueryが使われている場合は、WordPressが古いか、テーマやプラグインが独自のjQueryを読み込んでいることを示しています。Shopifyでは、テーマファイルと、スクリプトを挿入しているアプリを確認してください。

security.txtとは何で、ストアに必要ですか？

セキュリティ研究者に、脆弱性の報告方法を伝えるためのプレーンテキストファイルです。

RFC 9116 （新しいタブで開きます）（2022年4月。情報提供（Informational）のRFCのため、準拠は任意）によると、このファイルはHTTPSで/.well-known/security.txtにtext/plainとして配信する必要があります。ContactとExpiresは必須で、RFCはExpiresの日付を1年未満先にすることを推奨しています。

Contact: mailto:security@example.com
Expires: 2027-09-30T23:00:00.000Z
Preferred-Languages: en
Policy: https://example.com/security-policy

WooCommerceでは、サーバーにファイルを置けます。ホスティング型のプラットフォームでは、このパスにファイルを公開できるか確認してください。できない場合でも、お問い合わせページにセキュリティの連絡窓口をわかりやすく記載しておけば役立ちます。

DMARCはなりすましメールからストアをどう守りますか？

DMARCを使うと、アライメントの取れたSPFやDKIMに合格しないまま自社ドメインをFromアドレスに使っているメールを、隔離または拒否するようメールボックスプロバイダーに求めることができます。

p=noneのレコードはレポートを集めるだけで、なりすましメールは止められません。顧客は注文確認やパスワード再設定のメールが自社ドメインから届くと考えているため、自社のドメインそのものを表示するフィッシングメールはブロックする価値があります。ポリシーはdig +short TXT _dmarc.example.comで確認でき、仕様はRFC 9989 （新しいタブで開きます）で確認できます。DMARCが対象とするのはレコードを公開しているドメインだけで、よく似た別のドメインには効果がありません。

Shopifyが管理するのはどこまでで、WooCommerceでは何を自分で管理しますか？

Shopifyはストアフロントを支えるサーバーを運用していますが、セルフホストのWooCommerceストアでは、サーバーの設定はストア運営者とホスティング会社に委ねられます。

確認項目ShopifyWooCommerce（セルフホスト）
TLS証明書Shopifyに追加したすべてのドメインで無料 （新しいタブで開きます）。サードパーティのドメインでは最大48時間かかる場合ありホスティング会社または自前の設定
HTTPからHTTPSへのリダイレクトプラットフォームウェブサーバー、CDN、ホスティングの設定
セキュリティヘッダーShopifyのサーバーが送信ウェブサーバー、CDN、プラグイン
Cookieの属性Shopify独自のCookieはプラットフォームが設定。アプリとテーマのCookieは運営者の責任WordPressコア、プラグイン、サーバー
混在コンテンツとJSライブラリ自社のテーマ、コンテンツ、アプリ自社のテーマ、コンテンツ、プラグイン
security.txtとDMARC自社のドメインとDNS自社のドメインとDNS

2026年10月に当社がShopifyでホストされている複数のストアフロントを確認したところ、レスポンスにはmax-ageが約91日のHSTS、X-Content-Type-Options: nosniff、upgrade-insecure-requestsを含むCSPが含まれていましたが、frame-ancestorsはストアによって異なりました。ShopifyはPCI DSSレベル1準拠の認定を受けている （新しいタブで開きます）としています。テーマとインストールしたアプリは、引き続きストア運営者の責任です。

WooCommerceについては、WordPressのセキュリティ強化ガイド （新しいタブで開きます）が、WordPressとプラグインを最新の状態に保つこと、使っていないプラグインを削除すること、ホスティング会社にどのようなセキュリティ対策を講じているか確認することを勧めています。

なぜこれはペネトレーションテストではないのですか？

ペネトレーションテストは実際に攻撃を試みますが、パッシブなチェックは観察するだけです。

NIST SP 800-115は、ペネトレーションテストを、評価者が現実の攻撃を模倣し、システムのセキュリティ機能を回避する方法を見つけるセキュリティテストと定義しています（NISTの用語集 （新しいタブで開きます））。パッシブなチェックでは、プラグインのサーバー側の欠陥、脆弱な管理者パスワードや使い回しのパスワード、二要素認証の未設定、アクセス制御の不備、ページのソースに現れない脆弱なコードは見えません。いつでも繰り返せるベースラインとして活用してください。より確かな保証が必要な場合は、自社が所有している、またはテストの許可を得ているシステムを対象に、範囲を文書で定めたペネトレーションテストを依頼してください。

無料スキャンで、ストアの最初のチェックを実施できます。ウェブサイトセキュリティレポートは、TLSやリダイレクトからヘッダー、Cookie、混在コンテンツ、古いライブラリ、security.txt、DMARCまで、この記事で紹介したパッシブなチェックを網羅し、指摘事項ごとに修正方法を示します。ほかのパッシブな診断と同様に、ストアが安全であることを保証するものではありません。

よくある質問

パッシブなセキュリティチェックはストアにリスクをもたらしますか？

リスクは通常の訪問と変わりません。ブラウザーやメールサーバーがリクエストするのと同じ公開ページとDNSレコードを要求するだけで、ログインを試みたり、攻撃用のペイロードを送ったりはしません。

Shopifyでセキュリティヘッダーを追加できますか？

ストアフロントのレスポンスヘッダーはShopifyのサーバーから送られるため、必要なヘッダーがない場合はShopifyサポートに問い合わせてください。テーマにCSPの<meta>タグを入れれば一部のディレクティブは追加できますが、MDNによるとframe-ancestorsは<meta>ではサポートされていません。

古いバージョンのjQueryが使われていたら、ストアはハッキングされているということですか？

いいえ。既知の脆弱性があるコードが読み込まれているということであり、サイトが影響を受けるメソッドに信頼できないHTMLを渡している場合にリスクが高まります。jQueryを更新するか、それを読み込んでいるテーマやプラグインを削除してください。

現在、TLS証明書の有効期間は最長どのくらいですか？

2026年3月15日以降に発行された、公的に信頼された証明書の有効期間は最大200日です。この上限は2027年3月15日から100日、2029年3月15日から47日に短縮されます。

security.txtファイルは必須ですか？

RFC 9116は情報提供（Informational）のRFCなので、規格上、ファイルの公開は任意です。公開の手間は小さく、研究者にとって明確な連絡手段になります。

パッシブスキャンで問題がなければ、ストアは安全ですか？

いいえ。公開されている設定が正しく見えることを示すだけです。サーバー側の脆弱性、アカウントのセキュリティ、ビジネスロジックの欠陥には、別のテストが必要です。

出典

すべてのガイド