BOPLA：オブジェクトIDの保護だけでは不十分な理由（壊れたオブジェクトプロパティレベルの認可） 🔍

APIセキュリティの急速に進化する環境では、開発者はついに「IDチェック」の技術を習得し始めています。ほとんどの現代アプリケーションでは、ユーザーAがURLのuser_idを変更するだけでユーザBのプライベートデータにアクセスできないことを確認しています。これはBOLA（Broken Object Level Authorization：壊れたオブジェクトレベルの認可）と呼ばれる脆弱性です。

しかし、より巧妙な脅威が出現しています。それは、標準的なIDレベルのチェックを回避し、オブジェクトを定義する属性そのものをターゲットにするものです。これがBOPLA（Broken Object Property Level Authorization：壊れたオブジェクトプロパティレベルの認可）の世界です。

OWASP API Security Top 10のAPI3:2023にランクインしているBOPLAは、次世代のAPI脆弱性を代表します。もはや、「このユーザーはこのオブジェクトを見ることができるか？」と尋ねるだけでは不十分です。セキュリティチームは今や、「このユーザーはこのオブジェクト内の特定のフィールドを見るまたは変更できるか？」と問い直す必要があります。

この記事では、BOPLAの起源、その仕組み（特にMass AssignmentとExcessive Data Exposure）、そして2025年や2026年の高度な攻撃からAPIを守る方法について詳しく解説します。

1. 進化の過程：BOLAからBOPLAへ

まず、BOPLAを理解するために、その前身を理解しましょう。BOLA（旧IDOR）は、アプリケーションがユーザー提供のIDに基づいてオブジェクトにアクセスを許可する際に、そのユーザーがそのレコードにアクセスする権限を持っているかどうかを検証しない場合に発生します。

BOPLA（Broken Object Property Level Authorization）は、BOLAのより詳細な兄弟分です。APIが、ユーザーが正当なアクセス権を持つオブジェクトの特定のプロパティにアクセスまたは変更を許可してしまう場合に起こります。

OWASPの統合

2023年のAPI Security Top 10の更新では、OWASPは従来のカテゴリーであったExcessive Data Exposure（API3:2019）とMass Assignment（API6:2019）を統合し、「BOPLA」という単一のカテゴリーにまとめました。

その理由はシンプルです。両者の脆弱性は根本的に同じ原因、すなわちオブジェクトレベルだけでなく、プロパティレベルでの認可検証の失敗に由来しているからです。

2. なぜ「オブジェクトレベル」のセキュリティは失敗するのか

例としてデジタルバンキングAPIを想像してください。ユーザーのアリスがログインし、自分の口座詳細をリクエストします：GET /api/v1/accounts/12345。

オブジェクトレベルのチェック（BOLA）: サーバーはアカウント12345がアリスに属しているかを確認します。属しているのでアクセス許可。

プロパティレベルのチェック（BOPLA）: サーバーはJSONオブジェクトを返しますが、残高やアカウント名だけでなく、internal_credit_score、is_premium_member、anti_fraud_flagsなどの全データ行を返してしまいます。

アリスは自分の内部信用評価や詐欺ステータスを知ることになり、これは本来見せるべきではない情報です。これがExcessive Data Exposureです。

逆に、アリスが表示名を更新したい場合、PATCHリクエストを送ります：

{
  "display_name": "Alice The Great",
  "internal_credit_score": 850
}

もしバックエンドがJSON本文のすべてのフィールドを無条件に更新してしまうと、アリスは自分の信用スコアを改ざんしてしまいます。これがMass Assignmentです。

どちらの場合も、Object IDのチェックは通過していますが、Property Levelの認可が失敗しています。

3. 最初の柱：Excessive Data Exposure（読み取り漏洩）

Excessive Data Exposureは、APIがクライアント（フロントエンド）にデータをフィルタリングさせることに依存しているときに起こります。開発者はしばしば、データベースから「完全なオブジェクト」をフロントエンドに送信し、UIがユーザーネームだけを表示すれば他のフィールド（password_hashやssn）は安全だと考えがちです。

「隠された」危険性

ハッカーはUIを使いません。Burp Suite、Postman、Insomniaなどのツールを使って生のJSONレスポンスを調査します。

2025年の一般的なシナリオ例:

• ユーザーオブジェクトの罠: SNSアプリのAPIは、プロフィールをクリックすると完全なユーザーオブジェクトを返します。UIはバイオだけを表示しますが、JSONにはlast_login_ip、email_verified_status、backup_emailなどの内部情報も含まれています。

• IoTリーク: スマートホームAPIは、Wi-Fi SSIDや内部デバイストークンなどの技術メタデータを返すことがあり、これを利用してネットワーク内での横展開が可能です。

• PIIの金鉱: 2025年の調査では、多くの自動APIドキュメントツール（AutoSwaggerなど）が内部専用のフィールドを誤って公開し、PII（個人識別情報）の漏洩につながった例もあります。

実世界への影響

ハッシュ化されたパスワードや内部ロールを返すAPIは、攻撃者にとって辞書攻撃のターゲットとなります。内部の役割情報を返すと、権限昇格の手がかりになります。

4. 第二の柱：Mass Assignment（書き込みハック）

Mass Assignmentは、BOPLAの「書き込み」側の脆弱性です。これは、アプリケーションがクライアントから提供されたデータを、厳格な「許可リスト」なしに内部データモデルに自動的にバインドしてしまう場合に起こります。

現代のWebフレームワーク（Ruby on Rails、Spring Boot、Express.jsなど）は、ORM（Object-Relational Mapping）を使って開発を高速化します。1行のコードでJSON本文を受け取り、直接データベースに保存できます。

仕組みの脆弱性

攻撃者は、リクエストに「推測」したプロパティを追加してAPIを試します。

入力例： PATCH /api/users/me

正当な本文： {"bio": "Hello world"}

攻撃者の本文： {"bio": "Hello world", "role": "admin", "is_verified": true}

もし開発者がUser.update(req.body)のような汎用更新関数を使っていると、攻撃者は自分を管理者に昇格させることが可能です。

歴史的な例：”is_admin”プロパティ

有名なケースでは、研究者がGitHubに公開鍵をアップロードするリクエストにadmin: 1を追加するだけで管理者になれることを発見しました。GitHubはこれを修正しましたが、多くのマイクロサービスでは今もそのロジックが残っています。

5. 技術的深掘り：脆弱なコードと安全なコード

Node.js/Express環境で、ORM（MongooseやSequelize）を使った例を見てみましょう。

❌ 脆弱な方法（Mass Assignment）

app.patch('/api/profile/update', async (req, res) => {
    const user = await User.findById(req.user.id);
    // 脆弱：req.bodyのすべてのプロパティを無条件に割り当て
    Object.assign(user, req.body); 
    await user.save();
    res.json(user); // これも脆弱：過剰なデータ露出
});

このコードでは、{"is_premium": true}や{"account_balance": 99999}を送信されると、データベースがそれに従って更新されてしまいます。

✅ 安全な方法（プロパティレベルの認可）

const _ = require('lodash');

app.patch('/api/profile/update', async (req, res) => {
    const user = await User.findById(req.user.id);
    // 安全：許可された安全なフィールドだけを更新（Allow-list）
    const allowedUpdates = _.pick(req.body, ['bio', 'display_name', 'profile_picture']);
    Object.assign(user, allowedUpdates);
    await user.save();
    // 安全：必要なフィールドだけを返す（データ露出防止）
    const publicProfile = _.pick(user, ['id', 'username', 'bio', 'display_name']);
    res.json(publicProfile);
});

6. 2025年のBOPLA：AIと自動発見の台頭

BOPLAの脅威は、以下の二つの大きなトレンドにより強まっています：

1. 自動API発見ツール

AutoSwaggerやParam Minerのようなツールは、より高度になっています。攻撃者はこれらを使って「隠された」パラメータをスキャンします。APIの命名規則（例：first_nameがあればlast_nameもある可能性）を分析し、AI駆動のファジングリクエストでinternal_notesやpartner_idなどの敏感なフィールドを発見します。

2. GraphQLのインスペクション

GraphQLは特にBOPLAに脆弱です。なぜなら、GraphQLはユーザーに「正確に欲しい情報だけ」を問い合わせさせることができるためです。フィールドレベルの認可が厳格でなければ、ユーザーはアクセスすべきでない敏感なフィールドをクエリできてしまいます。@authディレクティブが個々のフィールドに適用されていない場合、設計上「BOPLA脆弱」となります。

7. BOPLAのビジネスへの影響

BOPLAは単なる技術的な「バグ」ではなく、重大なビジネスリスクです。

• データ漏洩: 全データベースを失わなくても、Excessive Data Exposureにより何千ものメールアドレスやSSNが漏洩し、GDPRやCCPAの報告義務が発生します。

• 金融詐欺: Fintech分野では、Mass Assignmentにより無許可のクレジット増額や手数料免除、VIPステータスの獲得が可能になります。

• 評判の損失: ユーザの信頼を最も早く失わせるのは、「ロジックの欠陥」であり、これによりプライベート設定や権限変更が誰でもできてしまいます。

8. BOPLAを防ぐための最終チェックリスト

APIをProperty Levelの認可問題から守るには、「Shift Left」の考え方が必要です。セキュリティは設計段階から組み込むべきです。

1. 厳格なDTO（Data Transfer Objects）の導入

データベースモデルを直接APIにマッピングしない。リクエストとレスポンスごとに別のクラスやインターフェース（DTO）を作成します。

• 入力DTO: APIが受け付ける正確なフィールドを定義
• 出力DTO: APIが返す正確なフィールドを定義

2. Allow-lists（ホワイトリスト）の使用

オブジェクト更新時に、「安全な」フィールドだけを明示的に許可します。

• 悪例: 「roleやidフィールドは無視」
• 良例: 「phone_numberとaddressだけを受け付ける」

3. .toJSON()やJSON.stringify()の自動化を避ける

これらのメソッドは、フレームワークによってはオブジェクト全体をシリアライズします。代わりに、ActiveModel::Serializers（Ruby）やJackson Views（Java）などのシリアライザを使い、敏感なプロパティをフィルタリングします。

4. フィールドレベルの認可ロジック

sensitiveなフィールド（例：is_adminやsubscription_tier）には、二次的なチェックを実装します。

擬似コード例： if (req.body.role && !currentUser.is_superuser) { return 403; }

5. 本番環境でのインスペクション無効化

GraphQLやSwagger/OpenAPIでは、インスペクションや公開スキーマアクセスを本番環境で無効にし、攻撃者による「マッピング」を防ぎます。

6. 自動化テスト（DAST）の実施

Mass Assignmentを検出するためのDynamic Application Security Testing（DAST）ツールを使用します。これらのツールは、有効なPOSTリクエストに対して、adminやrole、is_staffなどの管理者用フィールドを追加してサーバーの反応を試します。

9. BOPLAのテスト：ペンテスター向けミニガイド

セキュリティ研究者やQAエンジニア向けに、BOPLAを見つける方法を紹介します：

• レスポンスの分析: GETリクエストをキャプチャし、UIに表示されていないフィールド（内部IDやハッシュ値、is_internalなど）が含まれていないか確認します。

• 「推測と検証」の更新: PUTやPATCHエンドポイントを見つけ、GETレスポンスにあるが変更できないはずのフィールドを追加してみます。

例: GETで"is_verified": falseが返ってきたら、PATCHで"is_verified": trueを送信してみる。

• パラメータの極性: notifications_enabled: trueのようなフィールドがあれば、その逆や関連する推測（例：admin_access: true）を試します。

• 古いバージョンの確認: APIのv2は安全でも、v1（まだ稼働中）はMass Assignmentの脆弱性が残っていることがあります。

10. 結論：セキュリティは細部に宿る

2026年に向けて、APIの複雑さは増す一方です。BOLAからBOPLAへの移行は、より詳細で論理的なセキュリティへのシフトを意味します。

オブジェクトIDの保護は、APIセキュリティの「入場料」に過ぎません。本当の保護は、アプリケーション内の各プロパティのデータライフサイクルを理解し、DTOや厳格なAllow-list、堅牢なプロパティレベルの認可を実装することにあります。これにより、APIは正しい扉だけを開き、ゲストには正しい部屋だけを見せることができるのです。

重要なポイント: APIセキュリティにおいて、「Less is More」。返すプロパティが多いほど漏洩のリスクが高まり、未検証のプロパティを受け入れることはハッキングの可能性を高めます。ペイロードをスリムに保ち、ホワイトリストを厳格にし、認可を粒度細かく管理しましょう。