【入門編】CORS (Cross-Origin Resource Sharing) の不適切な設定とリスク – アプリケーションセキュリティ & 安全な開発防御ガイド

「とりあえず動いたからOK」は命取り!CORS設定の盲点をプロが解説します

こんにちは。現場で泥臭いインシデント対応を繰り返していると、「便利さ」と「安全性」のバランスをどう取るかに頭を悩ませる日々です。

今日は、Web開発の現場で最も「魔が差しやすい」設定の一つ、CORS(Cross-Origin Resource Sharing)についてお話しします。「なぜかエラーが出るから、とりあえずワイルドカード(“)にしちゃえ!」という経験、心当たりはありませんか?

その小さな妥協が、実はあなたの家の鍵を誰にでも渡しているのと同じ状態だとしたら……?今日は、新人のエンジニアさんにもわかるよう、身近な防犯に例えて紐解いていきましょう。

—

1. CORSってそもそも何?「家の鍵」で例えると

ブラウザには「同一オリジンポリシー(Same-Origin Policy)」という、非常に厳格な「門番」がいます。

例えば、あなたが自分の銀行口座にログインしているとき、悪意のある怪しいサイトが裏で勝手にあなたの銀行サイトへ「送金して!」というリクエストを送ることを防ぐためのルールです。この門番がいるおかげで、Webの世界は守られています。

しかし、時には「信頼できる外部のサービス」とデータをやり取りしたい時もありますよね。その時に「この人なら中に入れてもいいよ!」と門番に許可証を渡す仕組み、それがCORSです。

  • 門番(ブラウザ): 基本的に知らない人は全員シャットアウト。
  • CORSヘッダー: 「この人ならOK」と書かれた招待状。

2. なぜ「ワイルドカード」が危険なの?

一番やってはいけないのが、この招待状の宛名に「誰でもOK!(Access-Control-Allow-Origin: )」と書いてしまうことです。

これを家の鍵で例えると、「表札に『誰でも入っていいよ!』とデカデカと書いて、玄関を開けっ放しにしている状態」です。

攻撃者は、あなたのサービスを利用しているユーザーのブラウザを操り、あなたのサーバーにある機密データ(個人情報やセッション情報など)を、本来許可されていない場所へこっそりと持ち出そうとします。これがCORS設定の不備を突いた攻撃の正体です。

—

3. 正しい設定の「鉄則」:ホワイトリスト運用

では、どうすれば安全なのでしょうか?答えはシンプルで、「信頼できる相手の名前だけを名指しする」ことです。

悪い例(絶対NG!)

誰でも受け入れる設定
Access-Control-Allow-Origin:

良い例(ホワイトリスト方式)

サーバー側で、リクエストが来た「オリジン(送信元)」をチェックし、信頼リストに入っている場合のみ応答を返します。

// Node.js (Express) でのイメージ
const allowedOrigins = [‘https://www.your-app.com’, ‘https://api.partner.com’];

app.use((req, res, next) => {
const origin = req.headers.origin;

// 送信元がリストに入っているかチェック
if (allowedOrigins.includes(origin)) {
res.setHeader(‘Access-Control-Allow-Origin’, origin); // 許可されたオリジンのみを返す
}

next();
});

このように、「誰でもいい」ではなく「お前は知っているから入れてやる」という姿勢を貫くのが、セキュリティの基本中の基本です。

—

4. 現場でよくある「正規表現の罠」

少し慣れてくると、「サブドメインがいっぱいあるから、正規表現で楽をしよう」と考えがちです。

// 危険な例:これだと攻撃者のサイトも許可してしまう可能性が!
if (origin.match(/.\.your-app\.com$/)) {
res.setHeader(‘Access-Control-Allow-Origin’, origin);
}

一見賢そうに見えますが、例えば attacker-your-app.com のような巧妙なドメインが来た時、正規表現の書き方によってはスルーしてしまうことがあります。

「正規表現で頑張るより、配列にベタ書きする」。これが最もミスが少なく、メンテナンスもしやすい「泥臭いけれど確実な」方法です。

—

まとめ:一歩ずつ堅牢な開発を

Web開発をしていると、つい実装のスピードを優先したくなりますよね。でも、セキュリティの穴は一度空くと、後から塞ぐのに数倍のコストがかかります。

1. Access-Control-Allow-Origin: は開発環境まで!
2. 本番環境では許可するドメインを厳格にリスト化する。
3. 「楽をしよう」と思ったら一度立ち止まる。

これらを意識するだけで、あなたの作るアプリケーションの安全性は劇的に向上します。セキュリティは、難しい技術を詰め込むことではなく、こうした「当たり前」を丁寧に積み重ねることです。

さあ、今日からコードを見直して、あなたの「門番」を最強にアップデートしましょう!応援しています。

コメント

タイトルとURLをコピーしました