【入門編】 API Gatewayにおけるレスポンスヘッダーのセキュリティ強化 – インフラ・ネットワーク & クラウドセキュリティ防御ガイド

皆さん、こんにちは！
日々の開発やインフラの管理、本当にお疲れ様です。新人のIT担当者さんや、「セキュリティってなんだか難しそうだな…」と少し不安を感じている一般開発者の皆さんに向けて、今日はとっても大切なテーマをお届けしますね。

私たちが日々作り上げるWebアプリやAPIですが、実は「家」と同じように、見えないところで泥棒（攻撃者）が侵法のスキを狙っています。今回は、その泥棒の侵入を防ぐための重要なおまじない、「API Gatewayでのセキュリティヘッダーの強制付与」について、身近な例えを交えながら一歩ずつ優しく紐解いていきましょう！

—

1. 家の鍵と防犯ガラスに例えるセキュリティヘッダー

まずは、私たちが普段暮らしている「家」を想像してみてください。
頑丈な玄関の鍵を閉めることは、皆さん当たり前のようにやっていますよね。ITの世界で言うなら、これはパスワード認証や通信の暗号化（HTTPS）にあたります。

では、泥棒が「窓ガラスをこじ開けて侵入しようとしたり」、あるいは「郵便受けから郵便物をそっと盗み見ようとしたり」したらどうでしょう？鍵だけが頑丈でも、家全体の防備が甘いと危ういですよね。

Webアプリにおける「セキュリティヘッダー」とは、まさにこの「防犯ガラス」や「二重ロック」のような役割を持っています。
ブラウザ（皆さんがネットを見るアプリ）に対して、「この家（サイト）はこういうルールで安全に守られているから、怪しい動きをする奴が来ても絶対に扉を開けないでね！」と、あらかじめ強い命令（お墨付き）を出しておく仕組みなんです。

そして、この「安全ルール」を個々の家（バラバラに作られたマイクロサービスやAPI）でバラバラに管理するのは大変だし、設定漏れも起きやすい。だからこそ、みんなが必ず通る門番である「API Gateway」という一箇所で、まとめてガッチリとルールを貼り付けてしまおう！というのが今回の作戦になります。

—

2. 攻撃者はどうやって私たちのスキを突くのか？

ここで、今回私たちが防ぎたい代表的な2つの攻撃のメカニズムを、こっそり覗いてみましょう。

攻撃その1：MIMEタイプ・スニッフィング（勝手に解釈しちゃう泥棒）

ブラウザはとても親切で、「あれ？このファイル、拡張子はないけど中身を見たら画像っぽいわね。画像として表示してあげよっと！」と、気を利かせて勝手に判断してくれる機能（スニッフィング）を持っています。

しかし、攻撃者はここに付け込みます。掲示板やアップロード機能などに、悪意のあるプログラム（例えば <script> タグを含んだJavaScript）を仕込んだファイルを「テキストです」と偽って投稿させます。ブラウザが親切心から「お、これはスクリプトだな！実行しちゃお！」と勘違いして実行してしまうと、サイトが乗っ取られたり、ユーザーのクッキーが盗まれたりしてしまいます。

攻撃その2：中間者攻撃（通信をのぞき見・改ざんする泥棒）

「うちはHTTPSを使っているから安全だよ！」と思ったそこのあなた、油断は禁物です。
ユーザーが初めてアクセスするときに、うっかり http://example.com と「s」を付けずにアクセスしてしまった瞬間を狙って、途中の怪しいWi-Fiスポットなどが「やあ、私公式サーバーだよ！」と偽って偽サイトに誘導してしまう攻撃（SSL剥ぎ取り攻撃）が存在します。

—

3. 泥棒を撃退する主役のヘッダーたち

こうした攻撃から身を守るために、API Gatewayからブラウザへ向かう「レスポンス」に、特定の合言葉（セキュリティヘッダー）を混ぜてあげる必要があります。代表的なものを2つ見てみましょう。

① X-Content-Type-Options: nosniff

意味： 「ブラウザさん、勝手にファイルの形を推測（スニッフィング）しちゃダメ！私が指定した通りの形式でだけ扱いなさい！」という強い命令です。
効果： 先ほど説明した、偽装された悪意あるファイルの誤実行を防ぐ、強力な防犯ガラスになります。

② Strict-Transport-Security (通称：HSTS)

意味： 「このサイトと通信するときは、今後は何があっても絶対に暗号化された安全な通信（HTTPS）を使いなさい。HTTPでのアクセスは一切禁止！」というお触れ書です。
効果： 初回アクセス時のうっかりミスや、通信ののぞき見・改ざんを根元からシャットアウトします。

—

4. 【実務編】API Gatewayでの設定とコード例

「概念は分かったけれど、実際にどう設定すればいいの？」という不安がありますよね。
今回は、クラウドインフラでよく使われる AWS API Gateway（HTTP API / REST API） や、一般的なリバースプロキシの代表格である Nginx を例に、具体的な設定を見ていきましょう。一歩ずつ設定していけば大丈夫ですよ！

パターンA：AWS API Gateway (HTTP API) のレスポンスヘッダー設定

AWSのAPI Gatewayでは、「レスポンスヘッダーの設定（Response headers）」機能を使って、バックエンドのプログラムをいじらなくても、Gateway層で自動的にヘッダーを付与することができます。

AWS管理コンソールや、IaC（Terraformなど）を使って以下のような設定を行います。

{
  "Op": "add",
  "Path": "/inet/corsConfiguration", // ※環境によりパスは異なります
  "Value": {
    "Headers": [
      "X-Content-Type-Options",
      "Strict-Transport-Security"
    ]
  }
}

Terraformを使う場合は、以下のようにAPI Gatewayのステージ設定や統合レスポンス（Integration Response）にヘッダーマッピングを記述します。

# AWS API Gatewayでセキュリティヘッダーを強制付与するイメージ（Terraform設定例）
resource "aws_apigatewayv2_stage" "example" {
  api_id      = aws_apigatewayv2_api.example.id
  name        = "production"
  auto_deploy = true

  # レスポンスヘッダーのデフォルト設定
  default_route_settings {
    throttling_burst_limit = 100
    throttling_rate_limit  = 50
  }
}

# ※実際の現場では、API Gatewayの前段にあるCloudFrontや、
# API Gateway自体のレスポンスヘッダーポリシー(Response Headers Policy)をアタッチして付与するのが一般的です。

パターンB：NginxをAPI Gatewayとして使っている場合の例

もし自社でNginxなどのサーバーをAPI Gatewayとして立てているなら、設定ファイル（nginx.conf など）にたった数行書き加えるだけですべてのAPIレスポンスにヘッダーが強制付与されます。とてもスマートですね！

server {
    listen 443 ssl;
    server_name api.example.com;

    # SSL証明書の設定などは省略...

    # すべてのAPIレスポンスにセキュリティヘッダーを強制追加する
    # これにより、バックエンドのアプリが付け忘れてもGatewayがカバーします
    add_header X-Content-Type-Options "nosniff" always;
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
    add_header X-Frame-Options "DENY" always; # おまけ：クリックジャッキング対策も一緒に！

    location / {
        proxy_pass http://backend_app_servers;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

ワンポイントアドバイス：

Nginxの add_header ディレクティブを使うときは、後ろに always をつけるのがプロの技です。これをつけておかないと、エラーレスポンス（例えばHTTP 400や500番台）のときにヘッダーが削られてしまい、セキュリティの網にかかり損ねてしまうことがあるため、「どんなステータスコードであっても常時 (always) 付ける！」と指定するのが鉄則です。

—

5. まとめとこれからのステップ

いかがでしたでしょうか？
「API Gatewayにおけるレスポンスヘッダーのセキュリティ強化」と聞くと、何やら難解な呪文のようですが、要するに「家の門番であるAPI Gatewayに、泥棒よけの看板や防犯ガラスをしっかり持たせること」に他なりません。

個々のプログラマーがうっかり設定を忘れてしまっても、門番であるAPI Gatewayがしっかりカバーしていれば、システム全体としての安全性を高く保つことができます。これが、インフラエンジニアと開発者が力を合わせる「多層防御」の醍醐味です。

まずは身の回りの開発環境やステージング環境から、curl コマンドなどでレスポンスヘッダーを覗いてみてくださいね。
「おっ、ちゃんと X-Content-Type-Options: nosniff が返ってきてるぞ！」と確認できたときは、セキュリティエンジニアとしての小さな達成感を味わえるはずです。

一歩ずつ、確実に安全なシステムを作っていきましょう！それではまた次回の記事でお会いしましょう。