「とりあえず “ にしてない？」CORS設定の落とし穴と、泥棒に入られないための正しい鍵の管理術
こんにちは！セキュリティの世界へようこそ。
日々、コードを書いていると「あれ、ブラウザからAPIを叩いたらエラーが出る…面倒だからとりあえず `Access-Control-Allow-Origin: ` にしちゃえ！」なんて経験、ありませんか？
実はそれ、「家の玄関の鍵を全開にして、誰でも自由に入ってきてください」と看板を出しているようなものなんです。今回は、CORS（Cross-Origin Resource Sharing）という、Web開発における「身近だけど実は一番怖い」設定について、一緒に紐解いていきましょう。
—
1. CORSって、そもそも何者？
Webブラウザには「同一生成元ポリシー（Same-Origin Policy）」という、非常に厳格な「門番」がいます。
例えば、あなたが銀行のサイト（A銀行）にログインしているとしましょう。その状態で、別の怪しいサイト（Bサイト）を閲覧したとき、もし門番がいなかったらどうなるでしょうか？Bサイトは、あなたのブラウザ経由で、勝手にA銀行へ「残高を見せて」「送金して」という命令を送れてしまいますよね。
この「勝手なアクセス」を防ぐのが門番の役目です。しかし、開発をしていると「自分の作ったフロントエンドから、自分の作ったAPIを叩きたい」というケースが必ず出てきます。この時、門番に「この相手なら通していいよ」と許可証を出す仕組みが、CORSです。
—
2. なぜ “（ワイルドカード）が危険なのか？
冒頭で触れた “ という設定は、「誰からのアクセスでも受け入れます」という意味です。
家の防犯に例えるなら、「合鍵を町中の全員に配っている」のと同じ状態です。もしあなたのAPIが、ログインユーザーの個人情報や、重要な操作を扱うものだったら…？ 攻撃者はその隙をついて、あなたのサイトの利用者の情報を盗み出すことができます。
攻撃のメカニズム：身近な泥棒の例
1. 下見： 攻撃者は、あなたのAPIが “ を許可していることを知っています。
2. 侵入： 攻撃者が用意した罠サイトにユーザーがアクセスすると、ブラウザがユーザーのログイン情報（Cookieなど）を自動的に付与して、あなたのAPIへリクエストを送ります。
3. 盗難： サーバー側は「誰から来てもいい設定（“）」になっているので、疑うことなく重要なデータを返してしまいます。
—
3. 正しい鍵の管理術：CORSポリシーの設計
では、どうすれば安全なのでしょうか？答えはシンプル。「信頼できる相手だけをリストアップする」ことです。
安全な設定例（サーバーサイドの擬似コード）
例えば、あなたのフロントエンドのドメインが `https://my-app.com` だとしたら、以下のように設定します。
// Node.js (Express) の例
const cors = require(‘cors’);
const corsOptions = {
// 「誰でもOK」ではなく、特定の信頼できるドメインだけを許可する
origin: ‘https://my-app.com’,
// 認証情報（CookieやAuthorizationヘッダー）を扱う場合は必須
credentials: true,
// 許可するメソッドを絞る（無駄にDELETEやPUTを全開放しない）
methods: [‘GET’, ‘POST’],
optionsSuccessStatus: 200
};
app.use(cors(corsOptions));
ポイント解説
- `origin` を固定する: “ を使わず、必ず許可するドメインを明記しましょう。
- `credentials: true` の取り扱い: ログイン情報を送受信する場合は、この設定が必要です。この時、`origin` に “ を指定することはブラウザ側で禁止されています。つまり、安全な設定をしないとそもそも認証が動かないようになっているのです。これはブラウザがあなたを守るための「安全装置」です。
—
4. 現場で使える「泥臭い」チェックリスト
システムを構築する際、以下の3点を意識するだけでセキュリティレベルは劇的に向上します。
1. 「まずは “ で動くか試す」という癖を捨てる: 最初から正規のドメインを指定して開発する癖をつけましょう。
2. 環境ごとに切り替える: 開発環境（localhostなど）と本番環境で、許可するドメインを環境変数で出し分ける設定を最初から仕込んでおきます。
3. 不要なメソッドを許可しない: APIでデータを取得するだけなら `GET` だけを許可し、`POST` や `DELETE` は必要最低限の場所だけに限定します。
—
最後に：セキュリティは「面倒くさい」を乗り越えた先にある
セキュリティ対策は、最初は少し面倒に感じるかもしれません。でも、あなたが書いたコードを守ることは、そのサービスを使ってくれるユーザーを守ることに直結します。
「とりあえず動けばいい」という甘い誘惑を断ち切って、正しい鍵をかける。そんなエンジニアこそが、現場で本当に信頼されるプロフェッショナルです。
一歩ずつ、一緒に学んでいきましょう！もし設定で迷ったら、いつでもこの記事を読み返してくださいね。皆さんの安全な開発ライフを応援しています！
コメント