【実務・中級編】JSONPの脆弱性とCORSへの移行 – アプリケーションセキュリティ & 安全な開発防御ガイド

JSONPという「パンドラの箱」を閉じ、CORSでモダンな通信を実装する

こんにちは。現場の最前線でコードとログに向き合っているエンジニアの皆さん、お疲れ様です。

今日は、レガシーなシステムの保守やリプレイスで遭遇する「JSONP（JSON with Padding）」について話をしよう。一見、クロスドメイン通信を解決する便利な魔法のように見えるが、現代のセキュリティ基準から言えば、それは「自らセキュリティホールを掘る行為」に他ならない。

なぜJSONPが危険なのか、そしてなぜ今すぐにCORSへ切り替えるべきなのか。現場の泥臭い実情を交えて解説する。

—

1. JSONPの何が「悪」なのか？

JSONPの仕組みを簡単に振り返ろう。外部ドメインのJSファイルを


ここでの最大の脆弱性は、「スクリプトとして実行される」という性質そのものにある。
攻撃シナリオ：XSSの踏み台
もしAPI側でコールバック関数名（callbackパラメータ）のバリデーションが甘ければ、攻撃者は以下のように罠を仕掛ける。
攻撃URLの例:

https://api.example.com/data?callback=alert(document.cookie)//
ブラウザはこれを以下のJSとして実行してしまう。
alert(document.cookie)//({"id": 1, "status": "ok"});
これだけで、ユーザーのセッションCookieが流出する。さらに悪質なのは、これをCSRF（クロスサイトリクエストフォージェリ）と組み合わせることで、「認証済みユーザーのブラウザ上で、意図しないAPI操作を強制実行する」ことが容易になる点だ。JSONPには「送受信するデータがスクリプトとして解釈される」という、避けるべき特大の設計ミスが最初から埋め込まれている。
---
2. CORS（Cross-Origin Resource Sharing）への移行
CORSは、HTTPヘッダーを用いて「どのドメインからのリクエストを許可するか」をブラウザとサーバー間で安全に交渉する仕組みだ。JSONPのようにスクリプトを強制実行するのではなく、XMLHttpRequestやFetch APIを使って「データだけ」を安全に取得する。
実装の勘所：サーバーサイドの制御
CORSを有効にするには、APIサーバー側で Access-Control-Allow-Origin を適切に設定する。
PHPでの実装例
`` を許可するのは最も危険だ。認証が必要なAPIであれば、必ず特定のオリジンを指定すること。
 'success', 'data' => 'セキュアな通信成功']);

?>
---
3. インフラ・設定レベルでの防御（Nginx）
アプリケーションコードに手を入れるのが難しい場合や、フロントエンドの疎通確認を統制したい場合は、Webサーバー（Nginx）で制御するのも有効な手段だ。
Nginx設定ファイルの一部

location /api/ {

    # プリフライトリクエスト（OPTIONSメソッド）への対応

    if ($request_method = 'OPTIONS') {

        add_header 'Access-Control-Allow-Origin' 'https://your-frontend-app.com';

        add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';

        add_header 'Access-Control-Allow-Headers' 'Content-Type, Authorization';

        add_header 'Access-Control-Max-Age' 86400; # キャッシュ時間

        return 204;

    }
    # 通常のリクエスト

    add_header 'Access-Control-Allow-Origin' 'https://your-frontend-app.com';

}
---
4. セキュリティチーフからのアドバイス
JSONPからCORSへの移行は、単なるコードの書き換えではない。「信頼の境界線」を明確にする作業だ。
1.  「とりあえず動く」を許すな: 開発環境で Access-Control-Allow-Origin:  を設定したまま本番リリースする事故が後を絶たない。環境変数でドメインを管理し、CI/CDパイプラインで自動チェックをかけること。

2.  ブラウザの挙動を信じるな: CORSはブラウザ側の制約だ。サーバー側で Access-Control-Allow-Origin を指定しても、攻撃者が直接サーバーにリクエスト（cURLなど）を投げれば、制限は無効化される。API自体の認証（JWTやOAuth2など）を別途実装することが絶対条件だ。

3.  古いコードを見つけたら即座にリファクタ: 「まだ動いているから」という理由で放置されたJSONPエンドポイントは、将来のインシデントの爆弾になる。定期的な脆弱性スキャンで「スクリプトが返ってくるエンドポイント」を洗い出し、優先的に移行しよう。
セキュリティは「完璧な防御」を目指すのではなく、「攻撃のコストを極限まで引き上げ、攻撃者の興味を失わせること」にある。JSONPを捨て、CORSへ移行することは、そのための最も基本的で強力な一歩だ。
さあ、古い箱を閉じて、モダンで安全な設計へアップデートしよう。何か詰まったら、いつでもコードを見せてくれ。現場からは以上だ。