セキュリティヘッダー設定

目次

• 概要
• 使用場面
• クイックスタート
• リファレンスガイド
• ベストプラクティス

概要

XSS、クリックジャッキング、MIME スニッフィング、およびその他のブラウザベースの攻撃からウェブアプリケーションを保護するための包括的な HTTP セキュリティヘッダーを実装します。

使用場面

• 新しいウェブアプリケーションのデプロイ
• セキュリティ監査の修復
• コンプライアンス要件
• ブラウザセキュリティの強化
• API セキュリティ
• 静的サイト保護

クイックスタート

最小限の動作例：

// security-headers.js
const helmet = require("helmet");

function configureSecurityHeaders(app) {
  // Helmet の包括的な設定
  app.use(
    helmet({
      // Content Security Policy
      contentSecurityPolicy: {
        directives: {
          defaultSrc: ["'self'"],
          scriptSrc: [
            "'self'",
            "'unsafe-inline'", // 本番環境では削除
            "https://cdn.example.com",
            "https://www.google-analytics.com",
          ],
          styleSrc: [
            "'self'",
            "'unsafe-inline'",
            "https://fonts.googleapis.com",
          ],
          fontSrc: ["'self'", "https://fonts.gstatic.com"],
          imgSrc: ["'self'", "data:", "https:", "blob:"],
          connectSrc: ["'self'", "https://api.example.com"],
// ... (完全な実装についてはリファレンスガイドを参照)

リファレンスガイド

references/ ディレクトリの詳細な実装:

ベストプラクティス

✅ すべき事

• 全てで HTTPS を使用する
• 厳密な CSP を実装する
• HSTS をプリロード有効で有効化する
• X-Frame-Options でフレーミングをブロックする
• MIME スニッフィングを防止する
• CSP 違反を報告する
• ヘッダーを定期的にテストする
• セキュリティスキャナーを使用する

❌ してはいけない事

• CSP で unsafe-inline を許可する
• サブドメインで HSTS をスキップする
• CSP 違反を無視する
• 過度に許容的なポリシーを使用する
• 変更をテストするのを忘れる