導入
現代のシステム開発において、APIはWebアプリケーション、モバイルアプリ、IoTデバイスを繋ぐ重要なインフラとなっています。しかし、従来のWebアプリケーション向けのセキュリティ対策だけでは、API特有の脆弱性を防ぎきれないケースが増えています。「OWASP API Security Top 10 2023」は、APIに特化したリスクを整理したガイドラインです。本記事では、このガイドラインの重要性と、一般的な「OWASP Top 10」との違い、そして実務でどのように活用すべきかを解説します。
基礎知識：OWASP Top 10との違い
OWASP Top 10（Webアプリケーション向け）とOWASP API Security Top 10（API向け）は、補完関係にあります。
OWASP Top 10 (2021)：Webアプリケーション全体を対象とし、インジェクションや暗号化の欠如など、幅広い開発工程を網羅しています。
OWASP API Security Top 10 (2023)：APIに特化しており、認可の不備がより細分化されています。また、自動化された攻撃や、API特有のインベントリ管理（古いAPIの放置など）といった、現代のAPI開発で特に見落とされがちなリスクが強調されています。
API開発者は、両方のガイドラインを組み合わせることで、より堅牢なセキュリティ体制を構築できます。
実装/解決策：認可不備（BOLA）への対策
APIにおいて最も多い脆弱性が「オブジェクトレベルの認可の不備（BOLA）」です。これは、攻撃者がURLパラメータ等のIDを書き換えるだけで、他人のデータにアクセスできてしまう問題です。
解決策のポイント：
1. 推測不可能なIDの利用：連番のID（例: /api/users/123）ではなく、UUID（例: /api/users/550e8400-e29b-41d4-a716-446655440000）を使用する。
2. 認可チェックの徹底：リクエストされたIDが、ログイン中のユーザーに紐づいているかをサーバー側で必ず検証する。
サンプルプログラム
Node.js (Express) を用いた、認可チェックのサンプルコードです。
// 脆弱な実装例：IDのみで判定している
app.get(‘/api/orders/:orderId’, (req, res) => {
const order = db.orders.find(req.params.orderId);
res.json(order); // 誰の注文でも取得できてしまう可能性あり
});
// 安全な実装例：ユーザーIDと注文の紐付けを確認する
app.get(‘/api/orders/:orderId’, (req, res) => {
const userId = req.user.id; // セッション等から取得
const order = db.orders.findOne({
id: req.params.orderId,
ownerId: userId // 自分のデータのみにアクセス制限
});
if (!order) {
// 存在しない場合やアクセス権がない場合は404または403を返す
return res.status(403).send(‘アクセス権限がありません’);
}
res.json(order);
});
応用・注意点
現場で役立つ補足情報として、以下の点に注意してください。
1. 不要なプロパティの公開（API3:2023）
レスポンス時にオブジェクト全体をそのままJSON変換して返していませんか？内部IDやハッシュ値、管理用フラグが含まれていると、情報の漏洩に繋がります。必要なフィールドだけを抽出する「DTO（Data Transfer Object）パターン」の実装を推奨します。
2. インベントリ管理（API9:2023）
開発中のAPIや古いバージョンのAPIが公開されたままになっていないか確認してください。特にステージング環境のAPIに本番環境のデータを流用している場合、強力な攻撃対象となります。APIゲートウェイ等で、意図しないエンドポイントへのアクセスを遮断する設定を行いましょう。
3. レート制限の導入
API4:2023（制限のないリソース消費）を防ぐため、特定のIPやユーザーごとのリクエスト数を制限（レートリミット）することは必須です。これにより、ブルートフォース攻撃やDoS攻撃からAPIを守ることができます。
コメント