【ITニュース解説】A 20-minute website security audit: CSP, HSTS, SPF/DMARC, and CAA explained for developers

Webサイトを公開する上で、セキュリティ対策は極めて重要だ。システムエンジニアを目指す初心者も、Webサイトの基本的なセキュリティ監査は外部から簡単に実施できることを知っておくべきだ。この解説では、Webサイトの基礎的なセキュリティを20分程度で監査する方法について説明する。これは高度な侵入テストではなく、最も見落とされがちな標準的な保護が適切に設定されているかを確認するためのものだ。主にHTTPレスポンスヘッダーといくつかのDNSレコードをチェックし、curlとdigといった基本的なコマンドがあれば十分だ。

まず、Webサイトが常にHTTPSを使用しているかを確認する。HTTPでアクセスされた場合にHTTPSへ正しくリダイレクトされることが、安全な通信への切り替えの基本だ。次にHSTS（Strict-Transport-Security）ヘッダーを確認する。このヘッダーを設定すると、一度HTTPSでアクセスしたブラウザは次回以降そのサイトへ直接HTTPSで接続するようになり、HTTP通信を傍受しようとするダウングレード攻撃を防ぐ。max-ageは設定の記憶期間、includeSubDomainsはサブドメインへの適用を意味する。preloadオプションは強力だが、解除が困難なため慎重な導入が求められる。

Content-Security-Policy（CSP）ヘッダーは、Webサイトのセキュリティ対策の中でも特に価値が高く、設定が難しい項目だ。これはWebブラウザに対し、スクリプト、スタイルシート、画像、フレームなどのコンテンツを、どのドメインから読み込むことを許可するかを指示する。悪意のある第三者がスクリプトを埋め込むXSS（クロスサイトスクリプティング）攻撃を仕掛けた場合でも、CSPが適切に設定されていれば、許可されていないドメインからのスクリプト実行を防ぎ、被害を軽減できる。監査では、'unsafe-inline'やワイルドカードのような緩い設定がないかを確認する。また、object-src 'none'、base-uri 'none'、frame-ancestorsといった設定の有無もチェックする。特にframe-ancestorsは、他のサイトが自分のサイトをフレーム内に埋め込むこと（クリックジャッキング攻撃）を防ぐ現代的な方法だ。CSPが設定されていない場合、いきなり厳格なポリシーを導入するとサイト機能が壊れる可能性があるため、まずはContent-Security-Policy-Report-Onlyモードで導入し、問題を修正してから本格的に適用することが推奨される。

他にも重要なHTTPヘッダーがある。X-Content-Type-Options: nosniffは、ブラウザがレスポンスのMIMEタイプを推測するのを防ぎ、XSS攻撃のリスクを軽減するため、すべてのWebページで有効にすべきだ。Referrer-Policy: strict-origin-when-cross-originは、他のサイトへ移動した際にドメイン名のみを送信するように設定し、不要な情報漏洩を防ぐ。Permissions-Policyは、カメラやマイクなどのブラウザ機能の利用可否を制御し、不要な機能を無効にしてセキュリティを強化できる。X-Frame-Optionsは古いブラウザ向けのクリックジャッキング対策だが、現代のブラウザではCSPのframe-ancestorsが優先される。X-XSS-Protectionは非推奨のため、設定しないか0に設定することが推奨される。

Webサイトのセッション管理において重要なのがCookieのセキュリティだ。ログイン後に発行されるセッションクッキーは、ユーザー認証情報を保持するため厳重な保護が必要となる。セッションクッキーには、Secure属性を設定しHTTPS接続でのみ送信されるようにする。また、HttpOnly属性を設定しJavaScriptからのアクセスを禁止することで、XSS攻撃によるクッキー情報窃取のリスクを軽減する。これはXSS攻撃に対する第二の防御線となる。さらに、SameSite=LaxまたはStrict属性を設定することで、CSRF（クロスサイトリクエストフォージェリ）攻撃に対する耐性を高めることができる。__Host-プレフィックスを持つクッキーは、サブドメインが侵害された場合でもセッションクッキーが上書きされるのを防ぐ効果がある。

HTTPヘッダーだけでなく、DNSレコードもWebサイトのセキュリティに深く関わる。特にメールの認証に関わるSPF、DKIM、DMARCは、ドメインのなりすましを防ぎ、フィッシング詐欺からブランドを保護するために不可欠だ。SPF（Sender Policy Framework）は、ドメインからメールを送信することを許可されたメールサーバーをDNSのTXTレコードとして公開し、受信者がメールの送信元が正規かを確認できるようにする。設定上の注意点として、SPFレコードはドメインにつき一つしか許可されず、DNSルックアップ回数が10回を超えるとエラーとなる。DKIM（DomainKeys Identified Mail）は、送信されるメールに電子署名を付与する技術で、メールの送信元が詐称されていないことと内容が改ざんされていないことを検証できるようになる。DMARC（Domain-based Message Authentication, Reporting, and Conformance）は、SPFとDKIMの検証が失敗した場合に、受信側メールサーバーがどのようにメールを処理すべきかを指示し、検証結果のレポートを送信元に送る仕組みを提供する。DMARCは、まずp=noneでレポート収集から始め、正規のメールが認証を通るようになったらp=quarantine、最終的にp=rejectへと段階的にポリシーを強化することが推奨される。最近ではGmailやYahooが大量メール送信者に対してDMARCの導入を義務付けており、必須の対策となっている。メールを送信しないドメインであっても、なりすまし防止のために明示的にSPFとDMARCを設定しておくべきだ。

もう一つ重要なDNSレコードがCAA（Certificate Authority Authorization）だ。CAAレコードは、どの認証局（CA）が自分のドメインに対してSSL/TLS証明書を発行することを許可するかをリスト化するものだ。2017年以降、CAは証明書発行前にCAAレコードの存在を確認することが義務付けられている。このレコードがない場合、どのCAでも証明書を発行できてしまうリスクがある。CAAレコードを設定することで、特定のCAのみからの発行を許可したり、ワイルドカード証明書の発行を禁止したり、不正な発行があった場合にどこへ報告すべきかを指定できる。設定時には、実際に証明書を発行しているすべてのCAを含めることを忘れてはならない。

最後に、Webサイトの脆弱性報告窓口を示すsecurity.txtファイルの設置についてだ。これはRFC 9116で定義されており、セキュリティ研究者が脆弱性を発見した際に、どこに連絡すればよいかを示す標準的な場所となる。Contact情報とExpires情報が必須項目として含まれる。

これらの監査項目を確認したら、見つかった問題点を優先順位をつけて記録することが重要だ。例えば、HTTPSリダイレクトやHSTSの欠如、セッションクッキーのSecureやHttpOnly属性の不足は、即座に対応すべき重大な脆弱性と言える。DMARCの未導入やSPFの不備、CSPの不適切な設定も優先度が高い。各項目について、どのような設定が見つかり、どのような設定に変更すべきか、そしてその変更をどのように確認するかを具体的に記録することで、セキュリティ対策を確実に実施し、Webサイトの安全性を高めることができる。