皆さん、こんにちは！日々の開発やインフラの管理、本当にお疲れ様です。
新米のIT担当者として、あるいはアプリを作る開発者として、「セキュリティってなんだか難しそうだな…」「専門用語が多くてパンクしそう…」と感じていませんか？
大丈夫です、安心してくださいね。セキュリティは、私たちの身の回りにある「防犯」の仕組みと同じなんです。今回は、APIが返す「エラーメッセージ」に隠された思わぬ落とし穴と、その優しく確実な対策について、一緒に一歩ずつ学んでいきましょう！
—
家の鍵に例えて考えてみよう：APIのエラーってなんだろう？
まずは身近な防犯の例えから入りますね。
想像してみてください。あなたが頑丈な二重ロックの家を建てたとします。泥棒がやってきて、合鍵を探そうとガチャガチャとドアノブを回しました。
もし、この時にドアからこんな音声が流れてきたらどうでしょう？
> 「エラー：2階の寝室の窓の鍵が閉まっていません！さらに、合鍵は玄関マットの下に隠してあります！」
……泥棒は大喜びですよね。わざわざ鍵をピッキングする苦労をしなくても、一発で弱点が分かってしまいます。
実は、Webの世界で動くAPI（他のプログラムとデータをやり取りする仕組み）でも、これと同じことが起きてしまうんです。プログラムが動く中で「おっと、データが見つからないぞ！」や「データベースと接続エラーが起きたぞ！」となったとき、親切心のつもりでその詳細をそのまま画面やレスポンス返してしまうと……それは泥棒に家の間取り図を渡しているようなものなんです。
—
攻撃者はどうやってそこを狙うの？（攻撃のメカニズム）
レッドチーム（攻撃側）の視点から、少しだけ裏側の話をしますね。私たちが新しいターゲットのAPIを調査するとき、最初に何をするか知っていますか？
それは、「わざと間違ったリクエストを送る」ことです。
例えば、存在しないIDを指定してデータを要求したり、本来は「数字」を入れるべき場所に「' OR 1=1 --」といった変な文字を混ぜ込んでみます。
すると、脆弱なAPIはこう答えてくれます。
{
"error": "SQLSyntaxErrorException: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the server version... near 'WHERE id = '' at line 1",
"table": "users_master",
"query_time": "0.04s"
}私たち攻撃者は、このエラーメッセージを見た瞬間に「ガッツポーズ」をします。なぜなら、以下の情報が丸見えになってしまうからです。
1. 使っているデータベースの種類が分かる（今回はMySQLの特定のバージョンだと分かります）
2. テーブルの名前が分かる（users_masterという名前の顧客データがありそうだな、と特定できます）
3. プログラムの内部構造や使っている言語が分かる
これだけの情報があれば、次の攻撃（データベースを乗っ取るためのSQLインジェクション攻撃など）のハードルが劇的に下がってしまいます。「あ、ここに穴がありそうだな」と一目で分かってしまうんですね。
—
汎用的なエラーコードへ置き換えよう！具体的な実装指針
じゃあ、どうすればいいのでしょうか？
答えは簡単です。「エラーの詳細は裏側（サーバーのログ）だけにこっそり記録して、ユーザー（外部）には当たり障りのないシンプルな返事だけを返す」ようにすればいいのです。
身近な例で言えば、銀行のATMで暗証番号を間違えたとき、「暗証番号の2桁目が違います！」なんて親切（すぎる）エラーは出ませんよね？ただ一言、「暗証番号または口座番号が正しくありません」とだけ表示されます。あれと同じです。
それでは、実際のコードを見てみましょう。今回はよく使われるNode.js（Express）を例に、安全なエラーハンドリングの方法を見ていきますね。
悪い例：内部の仕組みをペラペラ喋ってしまう実装
まずは、やってはいけない「おしゃべりな」コードです。
// 【危険な実装例】
app.get('/api/user/:id', async (req, res) => {
try {
const userId = req.params.id;
// データベースからユーザーを取得する処理（仮）
const user = await database.query(`SELECT * FROM users WHERE id = ${userId}`);
if (!user) {
return res.status(404).json({ error: "ユーザーが見つかりませんでした" });
}
res.json(user);
} catch (err) {
// ⚠️【危険】エラーの内容（スタックトレースやDBのエラー）をそのまま返している！
res.status(500).json({
error: err.message,
stack: err.stack
});
}
});この書き方だと、データベースの接続情報やエラーが起きたプログラムの行数まで外の世界に飛び出してしまいます。
良い例：外部には優しく、裏側には厳格な実装
次に、安全できちんと防犯対策がされたコードを見てみましょう。
// 【安全な実装例】
app.get('/api/user/:id', async (req, res) => {
try {
const userId = req.params.id;
// プレースホルダーを使った安全なクエリ（SQLインジェクション対策も兼ねる）
const user = await database.query('SELECT id, name FROM users WHERE id = ?', [userId]);
if (!user) {
// ユーザーが存在しない場合も、抽象的なメッセージにする
return res.status(404).json({
success: false,
message: "リソースが見つかりませんでした。"
});
}
res.json({ success: true, data: user });
} catch (err) {
// 1. 詳しいエラー情報は、開発者・管理者だけが見られるサーバーのログに記録する！
console.error('[Internal Error]:', err.stack);
// 2. 外部（クライアント）には、汎用的で中身のないエラーメッセージだけを返す
res.status(500).json({
success: false,
message: "サーバー側で予期せぬエラーが発生しました。時間をおいて再度お試しください。"
});
}
});このように、try-catch の中で起きた具体的なシステムエラー (err.message や err.stack) はクライアントに返さず、console.error でサーバーのログファイルにしっかり残すようにします。これで、外部の攻撃者には何も情報を与えず、自分たち開発者は後からログで何が起きたのかを調査できるようになります！
—
まとめと、今日からできる一歩
いかがでしたでしょうか？
不適切なエラーメッセージによる情報漏洩は、ほんの少しの油断（デバッグモードの切り忘れや、エラーをそのまま返す実装）で起きてしまいます。
- 外部の人には、余計な情報を教えない（ATMの暗証番号エラーのように！）
- 詳しいエラーの中身は、裏側のログファイルにこっそり残す
- フレームワークの「本番モード（Production Mode）」を正しく設定し、デバッグ画面が出ないようにする
セキュリティ対策は、一度にすべてを完璧にする必要はありません。「あ、うちのAPI、エラーの時に変なこと喋ってないかな？」と気づけたことが、今日の一番大きな前進です。
一歩ずつ、安全で信頼されるシステムを作っていきましょう！応援しています！
コメント