Skip to main contentSkip to navigation

セキュリティヘッダー アナライザー

HTTPレスポンスヘッダーのセキュリティを分析

HTTP Response Headers

Paste raw response headers (from your server, curl -I, or browser devtools).

Analysis

HSTS
Header not present
Forces HTTPS and protects against protocol downgrade attacks.
CSP
Header not present
Mitigates XSS by whitelisting sources.
X-Frame-Options
Header not present
Prevents clickjacking in iframes.
X-Content-Type-Options
Header not present
Prevents MIME sniffing.
Referrer-Policy
Header not present
Controls referer leakage.
Permissions-Policy
Header not present
Restricts powerful browser features.
COOP
Header not present
Isolates browsing context for security.
COEP
Header not present
Required for certain isolation models.
CORP
Header not present
Restricts cross-origin resource loading.

セキュリティヘッダーアナライザー - HTTPレスポンスヘッダーをチェック

HTTP セキュリティヘッダーは Web 脆弱性に対する第一の防衛線です。ブラウザーにセキュリティポリシーの適用を指示し、XSS、クリックジャッキング、MITM、情報漏えいからユーザーを守ります。本アナライザーは応答ヘッダーをベストプラクティスに照らして評価し、欠落を特定し、堅牢化のための実践的な提案を行います。適切な設定はコンプライアンス・信頼・新たな脅威への備えに不可欠です。

必須セキュリティヘッダーと保護メカニズム

Content‑Security‑Policy（CSP）はリソースの取得元やインラインスクリプトを制御して XSS を抑制します。Strict‑Transport‑Security（HSTS）は HTTPS を強制しダウングレード攻撃を防ぎます。X‑Frame‑Options と frame‑ancestors は iframe 埋め込みを制御しクリックジャッキングを防止します。X‑Content‑Type‑Options は MIME スニッフィングを阻止。Referrer‑Policy は参照情報の漏えいを抑制。Permissions‑Policy はカメラ等の API アクセスを制限。総合して多層防御を実現します。

CSP の高度な設定とベストプラクティス

CSP は機能性との両立が鍵です。まずは制限的な方針（例：default‑src 'self'; img‑src 'self' data:; style‑src 'self' 'unsafe‑inline'; script‑src 'self'）から始め、必要に応じて緩和します。'unsafe‑inline' ではなく nonce/hash を用いましょう。report‑only で導入→互換性課題を修正→本適用、の段階導入が有効です。レポートを監視して攻撃/誤設定を検知し、複雑なアプリではページ毎のポリシーや strict‑dynamic の活用も検討します。

HSTS の導入とサブドメインの考慮点

HSTS は将来の接続で HTTPS を強制し、SSL ストリッピングを防ぎます。テストでは短い max‑age、運用では段階的に延長を。'includeSubDomains' で配下全体を保護する前に、すべてのサブドメインが HTTPS 対応か確認しましょう。初回訪問から保護する 'preload' も検討を。HSTS は「粘着性」があり、削除後もブラウザに保持されるため、導入前に十分な検証が必要です。

よくある落とし穴とトラブルシュート

過度に緩い CSP（script‑src '*' や 'unsafe‑eval'）は効果を損ないます。ログインで HSTS がないとダウングレード攻撃に弱くなります。不適切な X‑Frame‑Options は正当な iframe を壊したり、クリックジャッキングを防げなかったりします。X‑Frame‑Options と frame‑ancestors の競合にも注意。複数ブラウザと動線でテストし、DevTools で CSP 違反、HSTS の有効性、機密ページでのヘッダー有無を確認しましょう。

API／SPA におけるヘッダー運用

API では従来ページと異なる設定が必要です。CORS はクロスオリジンアクセスを制御し、JSON エンドポイントでは CSP の重要度は下がる場合があります。SPA では動的読み込みを許容しつつ XSS を防ぐため、緻密な CSP 設計が不可欠です。COEP/COOP による分離強化も検討を。API Gateway や CDN はオリジンのヘッダーを保持し、全環境（開発/ステージング/本番）で一貫運用しましょう。

監視・コンプライアンス・大規模運用

Security Headers や Mozilla Observatory、CI/CD の自動スキャンでモニタリングしましょう。CSP 違反や HSTS レポートを記録して、攻撃や誤設定を検知します。大規模環境では構成管理と “ポリシー as Code” で一貫性を担保。定期監査で有効性を確認し、新たな標準も評価します。SOC 2 や PCI DSS などの枠組みでは、これらのヘッダー実装が求められることがあります。

Further reading

Security headers provide essential protection against web vulnerabilities with minimal performance impact. Implement progressively, monitor violations, test thoroughly across browsers and user flows, and maintain policies as your application evolves. Regular security header audits should be part of your security maintenance routine.