セキュアコーディングとは｜1位は「危険な関数を避ける」ではなくアクセス制御

着手順が変わった｜アクセス制御が7位から1位へ

2024年版の1位はアクセス制御。2018年版では7位だった。攻撃の分類と開発の指針が、別々の経路で同じ結論に到達している。

セキュアコーディングの指針として OWASP が開発者向けにまとめているのが Proactive Controls です。公式は位置づけをこう定義しています。“a catalog of better practices, a set of items developers can embrace and implement in their code bases”。実装するものの目録であって、攻撃の一覧ではありません。

この目録の並び順が、2018年版と2024年版で大きく変わりました。アクセス制御が7位から1位へ繰り上がっています。逆に2018年版で1位だった「セキュリティ要件の定義」は、2024年版では4位に相当する位置へ移りました。

2024年版の10項目——3つが新設され、2つが姿を消した

攻撃の分類と開発の指針が、同じ場所で一致した

OWASP には性格の違う2つの一覧があります。攻撃側の分類が Top 10、開発側の指針が Proactive Controls です。2024〜2025年版では、両方の1位がアクセス制御になりました。

順位の意味を詳しく知りたい場合はOWASP Top 10の解説記事を参照してください。あちらは「順位が出現率ではない」ことを扱っています。

C1の実装｜取得条件に所有者を入れる、それだけ

認可の実装は難しい理屈ではなく、クエリの条件を1つ増やすこと。IDだけで引くのをやめれば、他人のデータを返す経路が閉じる。

セキュアコーディングでアクセス制御が抜ける典型は、認証を実装し終えた直後です。ログインは通っている、セッションも有効——だからデータを返してよい、と書いてしまいます。認証（誰か）と認可（何をしてよいか）は別の判定です。

実際に動かす｜条件を1つ足すと何が変わるか

違いを文章で説明するより、動かした方が早いので実行しました。請求書を2件持つデータに対し、user_A がログインした状態で user_B の請求書IDを指定します。

const invoices = [
  { id: 'inv_1001', ownerId: 'user_A', amount: 12000, memo: 'Aさんの請求書' },
  { id: 'inv_1002', ownerId: 'user_B', amount: 98000, memo: 'Bさんの請求書' },
];

// 認可なし: IDが一致すれば誰にでも返す
function findInvoiceUnsafe(invoiceId) {
  return invoices.find((v) => v.id === invoiceId) ?? null;
}

// 認可あり: IDと所有者の両方が一致したときだけ返す
function findInvoiceSafe(invoiceId, requesterId) {
  return invoices.find((v) => v.id === invoiceId && v.ownerId === requesterId) ?? null;
}

// user_A がログイン中。他人（user_B）の請求書IDを指定して叩く
const attacker = 'user_A';
const target = 'inv_1002';

--- 認可チェックなし ---
返却: Bさんの請求書 / 98000円
--- 認可チェックあり ---
返却: null（403にする）
--- 本人が自分のものを取得 ---
返却: Aさんの請求書 / 12000円

差分は && v.ownerId === requesterId の一節だけです。これが無いと 98,000円という他人の金額がそのまま返ります。あるとnullになり、本人の取得は通常どおり成功します。

ORMでも同じ｜findUnique ではなく所有者つきで引く

実際のアプリではORMを使いますが、原理は変わりません。主キーだけで引く関数（Prismaなら findUnique({ where: { id } })）は、所有者の条件を書く場所がありません。所有者を条件に含められる関数へ置き換えます。

1. データ取得箇所を全件洗い出す。IDをURLやリクエストボディから受け取っている処理が対象
2. 取得条件に所有者を足す。where: { id, userId: 現在のユーザー } の形にする
3. 更新・削除も同じ扱いにする。読み取りだけ直して更新系が残ると意味がない
4. 管理者専用の操作には役割の確認を入れる。所有者条件では管理者を表現できない

書いたあとの確認｜他人のIDを入れて叩くだけ

認可の検証に道具は要らない。自分のアカウントで他人のIDを指定し、データが返らないことを確かめる。返ったら穴がある。

セキュアコーディングが事後対応を避けるための営みであることは、公式の説明に表れています。“prevent common vulnerabilities during an application's inception”。作り始めの段階で防ぐ、という発想です。ただし書いた後の確認は必要で、認可については特別な道具が要りません。

実装済みと言える条件——設計3つと、実行1つ

確認手順｜2つのアカウントを作って往復する

1. テスト用にアカウントを2つ作り、それぞれでデータを1件ずつ作る
2. アカウントAでログインした状態のまま、URLやAPIのIDをBのものに書き換えて叩く
3. データが返ってきたらその時点で穴。403または404が返るのが正しい
4. 読み取りだけでなく更新と削除も同じ手順で試す

この検証の具体例はIDORの記事で扱っています。IDORはアクセス制御の失敗のうち、他人のIDを指定するだけで成立する形態を指します。