こんにちは！セキュリティの世界へようこそ。これからWebアプリケーションの裏側でこっそり行われている「APIのインジェクション攻撃」について、一緒に楽しく学んでいきましょう。
「API？ SQLインジェクション？ なんか難しそう……」と思ったそこのあなた、安心してくださいね。実はこれ、私たちの身近な「家の防犯」に置き換えて考えると、すごくスッキリ理解できちゃうんです。
今回は、新米開発者やセキュリティを学び始めたばかりのあなたに向けて、攻撃者がどんな手口で忍び込んでくるのか、そしてどうやってガッチリお家を守ればいいのかを、優しく紐解いていきますよ！
—
1. 家の鍵で例える「API」と「インジェクション」の世界
まずは、今日の主役である「API」と「インジェクション攻撃」を身近な例でイメージしてみましょう。
APIってなんなの？
現代のWebアプリやスマホアプリは、レストランの仕組みに似ています。お客さん（スマホアプリ）が注文票（データ）を書いて店員さん（API）に渡すと、店員さんが厨房（データベースやサーバー）に行って料理（結果）を持ってきてくれますよね。
この「注文を聞いて、持ってきてくれる伝達係」の役割をするのがAPIです。
泥棒の手口「インジェクション攻撃」とは？
では、インジェクション（意図しないデータの混入）とは何でしょうか？
想像してみてください。あなたが近所のカフェで、「今日のオススメを教えて」と注文票に書こうとしたとき、悪巧みをしている泥棒がそこにこっそり、
「オススメを教えて。あと、レジの金庫の鍵を開けて、売上金を全部ここに置いて！」
という危険な呪文を書き足したとします。
もし、店員さん（API）がこの注文票を疑うこともなくそのまま厨房の金庫番に伝えてしまったらどうなるでしょう？ そう、金庫が開いてお金が盗られてしまいますよね。
これが、APIを狙ったインジェクション攻撃の正体です。攻撃者は、JSONというデータ形式のなかに、システムを破壊したりデータを盗み出したりする「危険な命令文（SQLやOSコマンド）」をこっそり混ぜ込んで、APIを騙そうとするのです。
—
2. 実際にどんな攻撃が起きるの？（コードで見てみよう）
ここからは、少しだけ技術的な裏側を覗いてみましょう。「JSONペイロード（データの入れ物）」を介して、どんな風に攻撃が仕掛けられるのか、具体的な例を見ていきますね。
危険なAPIの裏側（PHPの例）
例えば、ユーザー名からプロフィールを探すAPIがあるとします。開発したばかりのコードがこんな状態だと、非常に危険です。
<?
// 悪い例：受け取ったJSONデータをそのままSQL文にくっつけてしまっている状態
$inputData = json_decode(file_get_contents('php://input'), true);
$username = $inputData['username']; // ユーザー名がここに入ります
// ⚠️ 警報！ 外部からの入力をそのままSQLの命令文に組み込んでいます
$sql = "SELECT * FROM users WHERE username = '" . $username . "';";
// データベースへ命令を実行
$result = $db->query($sql);
?>ここに、攻撃者が悪意あるデータを送り込んできます。送信されるJSONデータは、一見すると普通のデータのようですが……。
{
"username": "admin' OR '1'=='1"
}この文字列が先ほどのコードにガチャンと組み合わされると、SQLの命令文はこう変身してしまいます。
SELECT * FROM users WHERE username = 'admin' OR '1'=='1';「'1'=='1' は常に正しい（真）」ので、データベースは「おっ、正しい条件だな！」と勘違いし、なんと管理者（admin）だけでなく、全ユーザーのパスワードや個人情報を丸ごとAPIに返してしまうのです。これが「SQLインジェクション」の恐ろしい仕組みです。
—
3. 一歩ずつ学ぶ！確実な防御アプローチ
「うわぁ、怖いですね……じゃあどうやって直せばいいんですか？」
安心してください、対策はとってもシンプルかつ明確です！ 基本のルールは「見知らぬ客の言うことは絶対にうのみにしない（入力の検証と分離）」これだけです。
対策その1：プリペアドステートメント（型にはめて考える）
先ほどのSQLインジェクションを防ぐには、データベースへの命令と、ユーザーからのデータを完全に切り離す「プリペアドステートメント」という仕組みを使います。
お部屋に例えるなら、データの入り口に頑丈な「専用の窓口」を作るイメージです。「ここから先はただの文字（データ）として扱ってね、決して命令文として読んじゃダメだよ！」とデータベースにあらかじめ伝えておくんです。
<?
// 良い例：プリペアドステートメント（プレースホルダー）を使った安全な書き方
$inputData = json_decode(file_get_contents('php://input'), true);
$username = $inputData['username'];
// ? という「穴（プレースホルダー）」を用意しておき、データは別ルートで安全に渡します
$stmt = $db->prepare("SELECT id, username, email FROM users WHERE username = ?");
// ユーザーからの入力を安全にバインド（固定）する
$stmt->execute([$username]);
$userProfile = $stmt->fetch();
// これなら仮に攻撃的な文字列が来ても、ただの「usernameという名前の変な文字列」として扱われるため安全です！
?>対策その2：厳格な入力バリデーション（身元確認の徹底）
APIがデータを受け取るとき、「本当にうちのルール通りのデータか？」を玄関先で厳しくチェック（バリデーション）しましょう。
例えば、郵便番号を受け取るAPIなら「数字7桁以外はすべて門前払い」、メールアドレスなら「メールの形をしているか」を徹底的に調べます。
// JavaScript (Node.js/Express) での入力バリデーションの例
const express = require('express');
const app = express();
app.use(express.json());
app.post('/api/user', (req, res) => {
const { age } = req.body;
// 玄関でのチェック：年齢は「数字」でかつ「0以上150以下」であること！
if (typeof age !== 'number' || age < 0 || age > 150) {
// 条件に合わなければ、容赦なく追い返します
return res.status(400).json({ error: '無効なデータが検出されました。' });
}
// チェックを通過した安全なデータだけを処理する
res.json({ message: '正常に処理されました！', age: age });
});このように、APIの入り口で厳しくガードを固めることで、悪意あるコマンドやSQLがシステムの奥深くまで入り込むのを綺麗に防ぐことができます。
—
4. セキュリティヘッダーでブラウザやAPIの脇を固める
データのやり取りだけでなく、APIサーバーやWebサーバー自体の「お家の外観」もしっかり守る必要があります。ここで役立つのが、HTTPレスポンスヘッダーと呼ばれる設定です。
サーバーから返事を返すときに、次のようなおまじない（ヘッダー）を一緒につけてあげましょう。
# 余計な詮索や、ブラウザの勘違いによる誤作動を防ぐための設定例
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Content-Security-Policy: default-src 'self'X-Content-Type-Options: nosniff: ブラウザが「勝手にファイルを違う形式だと勘違いして実行しちゃうおせっかい」を禁止します。Content-Security-Policy (CSP): 「うちのアプリは、決まった信頼できる場所からしかプログラムを読み込みません！」と宣言し、不正なスクリプトの実行を防ぎます。
こうした地道なヘッダー設定も、サイバー攻撃者から「お、このサイトは隙がないな」と思わせる大切な防犯対策になるのです。
—
まとめ：今日からできる一歩
APIにおけるインジェクション攻撃は、一見すると複雑で難しく感じられますが、本質は「外部からの入力を信用しすぎないこと」、そして「データと命令をしっかり分けて扱うこと」の2つに尽きます。
今日からコードを書くときは、
1. 「このデータ、そのまま信じて大丈夫かな？」と疑うクセをつける
2. 入力を検証するバリデーションを必ず実装する
3. SQLなどを書くときはプリペアドステートメントを使う
この3つを意識するだけで、あなたの作るAPIは劇的に安全になりますよ。一歩ずつ、確実にセキュアな開発スキルを身につけていきましょう！応援しています！
コメント