アプリケーションセキュリティ入門｜世界ランキング1位の脆弱性は、今日あなたが書いたコードにある

OWASP Top 10という地図——2025年版で何が1位か

Top 10は「順番に全部やる」リストではなく、優先順位の地図。1位のアクセス制御から着手すれば、投資対効果が最大になる。

アプリケーションセキュリティの世界標準の出発点がOWASP Top 10です。公式の定義は“a standard awareness document for developers and web application security”——開発者のための、意識合わせの標準文書。実際の侵害データと専門家の合意から、最も危険な脆弱性カテゴリを10個並べています。

2025年版の顔ぶれ

1位の正体——「ログイン確認」と「所有確認」は別物

1位のアクセス制御の不備（Broken Access Control）の典型が、認可の確認漏れです。「ログインしているか」は確認しても、「そのデータがその人のものか」を確認していない——コードで書くとこの差は1行です。

// ❌ ログイン確認だけ: 誰でも他人の注文をIDで取れる（IDOR）
const order = await db.order.findUnique({
  where: { id: orderId },
});

// ✅ 所有確認つき: 自分の注文しか取れない
const order = await db.order.findFirst({
  where: { id: orderId, userId: req.user.id },
});

この形の脆弱性はIDOR（Insecure Direct Object Reference）と呼ばれます。対策は難しくありません——データを取るクエリすべてに、所有者の条件を機械的に入れる。難しいのは技術ではなく、全部のクエリで徹底する規律の方です。

個人開発が実際に落ちる穴——編集部が自分たちのコードで踏んだもの

穴は「知らない技術」ではなく「知っているのに全箇所で徹底できていない基本」に開く。チェックリスト化して機械的に回すのが唯一の対策。

アプリケーションセキュリティの記事は他人事の脅威話になりがちなので、編集部自身の実例を出します。当メディアの運営元はマーケットプレイス（ServiceDock）を開発しており、自分たちのコードレビューで実際にこの種の穴を見つけて直してきました。

実際にあった3つの穴

• IDORそのもの ── 注文取得のクエリが id だけで引いており、userId の条件が抜けていた。修正は1行、見つけるまでが仕事
• エラーの内部情報漏れ ── 例外の error.message をそのままAPIレスポンスで返していた。DB構造やファイルパスが攻撃者へのヒントになる
• 更新系の競合 ── 「残数を読む→確認→減らす」が別々の処理で、同時アクセスで枠を超えて使える状態だった。トランザクションで原子化して修正

対策はリスト化して「新しい画面を作るたび」に回す

この経験から学んだのは、セキュリティは知識ではなく運用だということです。編集部では新しいAPIを作るたびに固定のチェックリスト（認証→所有確認→入力上限→エラー整形→レート制限）を回しています。1回作れば数分で回せて、穴の大半はこの数分で防げます。

今週末にやる順番——3時間のセキュリティ改善プラン

全部やろうとして何もやらないのが最悪。アクセス制御→認証→注入系の順に、手を動かす範囲を絞る。

アプリケーションセキュリティの学習は範囲が広く、完璧を目指すと着手できません。個人開発の現実に合わせて、効果の大きい順に3ステップへ絞ります。

ステップ1（1時間）: 自分のアプリを攻撃してみる

開発環境で、別ユーザーのアカウントを2つ作り、片方でログインしたままURLのID・APIのパラメータをもう片方のものに変えて叩きます。見えてしまったらそれがIDORで、該当クエリに所有者条件を足します。データ取得系のエンドポイントを上から順に、機械的に。

ステップ2（1時間）: 認証まわりの既定値を確認する

• パスワードはbcrypt/argon2等でハッシュしているか（平文・MD5は即修正）
• セッション・トークンの有効期限があるか。ログアウトで無効化されるか
• ログイン試行にレート制限があるか（総当たり対策）

ステップ3（1時間）: 注入系の「作法外れ」を探す

SQL文字列の連結・HTMLへの変数直接埋め込みを grep で探します。ORMのパラメータ化・テンプレートの自動エスケープというフレームワークの標準の書き方に戻すだけで、インジェクション系はほぼ塞がります。認証・認可のより深い設計はAPI連携の記事の最小権限の考え方と、Webhook受信の署名検証もあわせて確認してください。