« 米国NIST SP 800-172 Rev. 3 管理対象非機密情報の保護に関する強化されたセキュリティ要件、SP 800-172A Rev. 3 管理対象非機密情報(CUI)に対する強化されたセキュリティ要件の評価 | Main | 英国 NCSC 深刻なサイバー脅威への備え:リーダーが今すぐ行動すべき理由 - 英国のレジリエンスを共に築くための呼びかけ (2026.04.20) »

2026.05.22

米国 NIST SP 800-228A(初期公開草案)RESTful Web APIの安全な導入に関するガイドライン (2026.05.18)

こんにちは、丸山満彦です。

NISTがSP 800-228A(初期公開草案)RESTful Web APIの安全な導入に関するガイドラインを公表し、意見募集をしていますね...

SP 800-228Aは、 NIST SP 800-228 Guidelines for API Protection for Cloud-Native Systems を補完する文書です。

SP 800-228 が、「あらゆるAPIに共通するセキュリティの"基本ルール"を定める文書」で、REST、gRPC、GraphQL など全API種別を対象とし、設計から運用まで、ゼロトラスト原則に基づく保護策を体系的に整理して者であるのに対し、

SP 800-228A

は、「RESTful API 特有の"落とし穴"と対策をまとめた専門ガイド」で、予測しやすいURL、HTTP動詞、JSON形式などREST固有の仕組みに起因する脆弱性に焦点をあてたもので、SP 800-228の「基本ルール」に、REST専用の追加対策を上乗せする補完文書という関係になりますかね...

 

NIST - ITL

・2026.05.18 NIST SP 800-228A (Initial Public Draft) Guidelines for the Secure Deployment of RESTful Web APIs

NIST SP 800-228A (Initial Public Draft) Guidelines for the Secure Deployment of RESTful Web APIs NIST SP 800-228A(初期公開草案)RESTful Web APIの安全な導入に関するガイドライン
Announcement 通知
A RESTful API platform is a stateless architectural framework that leverages standard HTTP protocols to manage and exchange data as "resources," serving as the primary bridge for communication between modern web applications. These Web APIs are the most prevalent API type. Their inherent simplicity, universal compatibility with browsers, robust ecosystem of developer tools, and superior caching efficiency align with existing web infrastructure to provide scope for introducing vulnerabilities and accompanying threats of exploitation. RESTful APIプラットフォームは、標準的なHTTPプロトコルを活用してデータを「リソース」として管理・交換するステートレスなアーキテクチャフレームワークであり、現代のWebアプリケーション間の通信における主要な架け橋としての役割を果たしています。これらのWeb APIは、最も普及しているAPIタイプです。その本質的なシンプルさ、ブラウザとの普遍的な互換性、開発者ツールの堅牢なエコシステム、そして優れたキャッシュ効率は、既存のWebインフラストラクチャと調和する一方で、脆弱性の導入やそれに伴う悪用リスクの余地も生み出しています。
This document: 本文書では:
・Analyzes threats to RESTful APIs across the pre-runtime and runtime phases ・実行前および実行段階におけるRESTful APIへの脅威を分析する
・Provides guidelines for implementing a set of controls to mitigate threats ・脅威を軽減するための一連の対策を実装するためのガイドラインを提供する
・Complement the detailed set of controls provided in SP 800-228 by including parameters that are specific to the architectural style of RESTful Web APIs ・RESTful Web API のアーキテクチャ様式に固有のパラメータを含めることで、SP 800-228 で提供される詳細な一連の対策を補完する
Abstract 要約
A RESTful API platform is a stateless architectural framework that leverages standard HTTP protocols to manage and exchange data as "resources," serving as the primary bridge for communication between modern web applications. This alignment with Web is the reason they are also called Web APIs and remain the most prevalent API type. Their inherent simplicity (creating a low barrier for entry), universal compatibility with browsers, robust ecosystem of developer tools and superior caching efficiency that aligns naturally with existing web infrastructure gives scope for introducing vulnerabilities and accompanying threats of exploitation. This document analyzes those threats to RESTful APIs and provides guidance for implementing a set of associated mitigating controls. Thus, it also complements the detailed set of controls provided in SP 800-228 by including parameters that are specific to the architectural style of RESTful Web APIs. RESTful API プラットフォームは、標準的な HTTP プロトコルを活用してデータを「リソース」として管理・交換するステートレスなアーキテクチャフレームワークであり、現代の Web アプリケーション間の通信における主要な架け橋として機能します。Webとのこの整合性こそが、RESTful APIがWeb APIとも呼ばれ、最も普及しているAPIタイプであり続けている理由である。その本質的なシンプルさ(参入障壁の低さ)、ブラウザとの普遍的な互換性、開発者ツールの堅牢なエコシステム、そして既存のWebインフラと自然に調和する優れたキャッシュ効率は、脆弱性の導入やそれに伴う悪用リスクの余地を生み出している。本ドキュメントでは、RESTful APIに対するこれらの脅威を分析し、関連する一連の軽減対策を実装するためのガイダンスを提供する。したがって、本ドキュメントは、RESTful Web APIのアーキテクチャ様式に特有の要素を含めることで、SP 800-228で規定されている詳細な対策セットを補完するものである。

 

・[PDF] SP.800-228A.ipd

20260521-80739

 

目次...

Executive Summary エグゼクティブサマリー
1. Introduction 1. はじめに
1.1. Document Goals 1.1. 本文書の目的
1.2. Relationship With Other NIST Documents 1.2. 他のNIST文書との関係
1.3. Document Structure. 1.3. 本文書の構成
2. Conceptual Framework of RESTful APIs 2. RESTful APIの概念的枠組み
2.1. Detailed Architectural Features of Resource-Oriented RESTful AP  2.1. リソース指向のRESTful APIの詳細なアーキテクチャ的特徴
2.1.1. Consistent Resource Identifiers 2.1.1. 一貫性のあるリソース識別子
2.1.2. Consistent Resource Structure 2.1.2. 一貫性のあるリソース構造
2.1.3. Consistent Field Naming Within and Across APls 2.1.3. API内およびAPI間における一貫したフィールド命名
2.1.4. Use of Standard HTTP Methods and Semantics 2.1.4. 標準HTTPメソッドおよびセマンティクスの使用
2.2. Example of Resource-Oriented RESTful APIs 2.2. リソース指向RESTful APIの例
2.3. Advantages of Building Applications With RESTful APls for Services 2.3. サービス向けRESTful APIを用いたアプリケーション構築の利点
2.3.1. Advantages of RESTful API Deployment With Consistency Across Architectural Components. 10 2.3.1. アーキテクチャコンポーネント全体にわたる一貫性を伴うRESTful API導入の利点。 10
2.3.2. Advantages of RESTful API Deployment Due to Inherent Architectural Features 2.3.2. 固有のアーキテクチャ的特徴によるRESTful API導入の利点
2.4. Drawbacks of Building Applications With RESTful APls for Services 2.4. サービス向けRESTful APIを用いたアプリケーション構築の欠点
3. Protection Requirements Common to All API Types 3. すべてのAPIタイプに共通する保護要件
4. Threats Specific to REST APIs 4. REST APIに特有の脅威
4.1. Threats Due to URL-Based Resource Addressing and Querying 4.1. URLベースのリソースアドレス指定およびクエリによる脅威
4.1.1. Easy Enumeration of Resources Due to Direct Object Reference (RAPI-URL-TH1) 4.1.1. 直接的なオブジェクト参照によるリソースの容易な列挙 (RAPI-URL-TH1)
4.1.2. CRLF Injection (Header Splitting) (RAPI-URL-TH2) 4.1.2. CRLFインジェクション(ヘッダー分割)(RAPI-URL-TH2)
4.2. HTTP Protocol-Related Information Threat 4.2. HTTPプロトコル関連情報の脅威
4.2.1. Illegal Access Due to the Lack of Verb-Specific Security Filter (RAPI-HTTP-TH1) 4.2.1. 動詞固有のセキュリティフィルタの欠如による不正アクセス(RAPI-HTTP-TH1)
4.2.2. Improper Handling of Parameters in HTTP Requests (RAPI-HTTP-TH2) 4.2.2. HTTP リクエストにおけるパラメータの不適切な処理 (RAPI-HTTP-TH2)
4.2.3. Threats Due to Protocol and Data Format Conversion 4.2.3. プロトコルおよびデータ形式の変換による脅威
4.2.4. Threats Due to HTTP Internal Headers (RAPI-HTTP-TH8) 4.2.4. HTTP 内部ヘッダーによる脅威 (RAPI-HTTP-TH8)
4.2.5. Server-Side Request Forgery (SSRF) Threats (RAPI-SSRF-TH1) 4.2.5. サーバーサイドリクエストフォージェリ (SSRF) による脅威 (RAPI-SSRF-TH1)
4.2.6. Misconfiguration of Cross-Origin Resource Sharing (CORS) 4.2.6. クロスオリジンリソース共有(CORS)の設定ミス
4.3. Service Discovery Threats 4.3. サービスディスカバリの脅威
4.3.1. Threats During Service Registration Phase (RAPI-SDS-TH1). 4.3.1. サービス登録フェーズにおける脅威 (RAPI-SDS-TH1)
4.3.2. Threats Due to Illegal Write Access Leading to Malicious Misdirection (RAPI-SDS-TH2) 4.3.2. 悪意のあるリダイレクトにつながる不正な書き込みアクセスによる脅威 (RAPI-SDS-TH2)
4.3.3. Threats Due to the Enumeration of Services in the Service Registry (RAPI-SDS-TH3) 4.3.3. サービスレジストリにおけるサービスの列挙に起因する脅威 (RAPI-SDS-TH3)
4.3.4. Threat Due to a Denial of Service on the SDS (RAPI-SDS-TH4) 4.3.4. SDS に対するサービス拒否(DoS)に起因する脅威 (RAPI-SDS-TH4)
4.3.5. Threats Due to the Operational Status of Services Listed in the Registry (RAPI-SDS-TH5) 4.3.5. レジストリに登録されたサービスの運用状況に起因する脅威 (RAPI-SDS-TH5)
4.4. Data Leaks via Side Channels 4.4. サイドチャネルを介したデータ漏洩
4.5. Threats Due to Query Execution Features in Some Frameworks 4.5. 一部のフレームワークにおけるクエリ実行機能に起因する脅威
4.6. REST Authentication Layer Threats 4.6. REST認証レイヤーの脅威
4.7. Threats to REST APIs Accessed by Al Agents 4.7. AIエージェントがアクセスするREST APIに対する脅威
4.7.1. The Confused Deputy Problem 4.7.1. コンフューズド・デピュティ問題
4.7.2. Indirect Prompt Injection 4.7.2. 間接的なプロンプトインジェクション
4.7.3. Business Logic Probing at Scale 4.7.3. 大規模なビジネスロジックのプロービング
5. Controls for the Secure Deployment of RESTful Apls 5. RESTful Aplsの安全な導入のための対策
5.1. Mitigating Threats Due to URL-Based Resource Addressing and Querying (RAPI-URL-TH1) 5.1. URLベースのリソース指定およびクエリによる脅威の軽減 (RAPI-URL-TH1)
5.2. Mitigating Threats Due to HTTP Protocol and Data Format-Related Information 5.2. HTTPプロトコルおよびデータ形式に関連する情報による脅威の軽減
5.2.1. Mitigating Threats Due to the Lack of a Verb-Specific Security Filter (RAPI-HTTP-TH1) 5.2.1. 動詞固有のセキュリティフィルタの欠如による脅威の軽減 (RAPI-HTTP-TH1)
5.2.2. Mitigating Threats Due to the Improper Handling of Parameters in HTTP Requests (RAPI-HTTP-TH2)  5.2.2. HTTPリクエストにおけるパラメータの不適切な処理による脅威の軽減 (RAPI-HTTP-TH2)
5.2.3. Mitigating Threats Due to Protocol and Data Format Encoding/Conversions RAP:H-T RAPI-HTTP-TH7) 5.2.3. プロトコルおよびデータ形式のエンコード/変換による脅威の軽減 (RAPI-HTTP-TH7)
5.2.4. Mitigating Threats Due to HTTP Internal Headers (RAPI-HTTP-TH8) 5.2.4. HTTP内部ヘッダーによる脅威の軽減 (RAPI-HTTP-TH8)
5.2.5. Mitigating Threats Due to Server-Side Request Forgery (SSRF) Attacks (RAPI-SSRF-TH1) 5.2.5. サーバーサイドリクエストフォージェリ(SSRF)攻撃による脅威の軽減 (RAPI-SSRF-TH1)
5.2.6. Mitigating Threats Due to the Misconfiguration of Cross-Origin Resource Sharing (CORS) (RAPI-CORS-TH1) to (RAPI-CORS-TH3) 5.2.6. クロスオリジンリソース共有(CORS)の設定ミスによる脅威の軽減 (RAPI-CORS-TH1) ~ (RAPI-CORS-TH3)
5.3. Mitigating Threats in the Service Discovery Service (SDS) Infrastructure  5.3. サービスディスカバリーサービス(SDS)インフラストラクチャにおける脅威の軽減
5.3.1. Mitigating Threats During the Service Registration Phase (RAPI-SDS-TH1) 5.3.1. サービス登録フェーズにおける脅威の軽減 (RAPI-SDS-TH1)
5.3.2. Mitigating Threats Due to Service Registry Poisoning (RAPI-SDS-TH2) 5.3.2. サービスレジストリのポイズニングによる脅威の軽減 (RAPI-SDS-TH2)
5.3.3. Mitigating Threats Due to Services Enumeration Using the Registry (RAPI-SDS-TH3) 5.3.3. レジストリを使用したサービス列挙による脅威の軽減 (RAPI-SDS-TH3)
5.3.4. Mitigating Threats Due to DoS Attacks on the Service Registry (RAPI-SDS-TH4) 5.3.4. サービスレジストリに対する DoS 攻撃による脅威の軽減 (RAPI-SDS-TH4)
5.3.5. Mitigating Threats Due to the Operational Status of Services Listed in the Registry (RAPI-SDS-TH5) 5.3.5. レジストリにリストされているサービスの稼働状況に起因する脅威の軽減 (RAPI-SDS-TH5)
5.4. Mitigating Threats Due to Data Leaks via Side Channels 5.4. サイドチャネルを介したデータ漏洩に起因する脅威の軽減
5.5. Mitigating Threats Due to the Query Execution Features 5.5. クエリ実行機能に起因する脅威の軽減
5.5.1 Addressing Threats due to the Auto-binding Feature 5.5.1 自動バインディング機能に起因する脅威への対処
5.5.2 Addressing Threats due to Expression Language Evaluation Feature 5.5.2 式言語評価機能に起因する脅威への対処
5.6. Mitigating Threats Due to REST Authentication and Authorization Layers 5.6. REST認証および認可レイヤーに起因する脅威の軽減
5.7. Mitigating Threats to REST APIs From Al Agent Clients 5.7. AIエージェントクライアントによるREST APIへの脅威の軽減
6. Conclusions and Summary 6. 結論とまとめ
References 参考文献
Appendix A. REST-Specific Manifestations of OWASP Top 10 API Security RisksRAPI-HTTP-TH7). 附属書 A. OWASP Top 10 APIセキュリティリスクのREST特有の現れ(RAPI-HTTP-TH7)
Appendix B. Threat Categories and Mitigating Controls for RESTFul APIs 附属書 B. RESTful API の脅威カテゴリと緩和策

 

 

Executive Summary  エグゼクティブサマリー 
A RESTful API (commonly called REST API) is the most prevalent API type because of its close alignment with Web infrastructure (hence sometimes called Web API) such as use of browsers as clients, Web server as the server component and use of HTTP protocol for communication between the two. Their inherent simplicity (creating a low barrier for entry), universal compatibility with browsers, robust ecosystem of developer tools and superior caching efficiency that aligns naturally with existing web infrastructure gives scope for introducing vulnerabilities and accompanying threats of exploitation. This document analyzes those threats to RESTful APIs and provides guidance for implementing a set of associated mitigating controls. Thus, it also complements the detailed set of controls provided in SP 800-228 by including parameters that are specific to the architectural style of RESTful Web APIs.  RESTful API(一般に REST API と呼ばれる)は、クライアントとしてブラウザを使用し、サーバーコンポーネントとして Web サーバーを使用し、両者の間の通信に HTTP プロトコルを使用するなど、Web インフラストラクチャと密接に連携しているため(そのため Web API と呼ばれることもある)、最も普及している API タイプです。その本質的なシンプルさ(参入障壁が低いこと)、ブラウザとの普遍的な互換性、開発者ツールの堅牢なエコシステム、そして既存のWebインフラストラクチャと自然に調和する優れたキャッシュ効率は、脆弱性の導入やそれに伴う悪用リスクの余地を生み出しています。本書は、RESTful APIに対するこれらの脅威を分析し、一連の関連する緩和策を実装するためのガイダンスを提供します。したがって、本ドキュメントは、RESTful Web APIのアーキテクチャ様式に固有のパラメータを含めることで、SP 800-228で提供されている詳細な対策セットを補完するものである。
To develop the appropriate controls, threats were analyzed across the following phases and associated activities:   適切な対策を策定するため、以下のフェーズおよび関連する活動にわたって脅威を分析した:
• Pre-run time phase of RESTful APIs  • RESTful APIのランタイム前フェーズ
o Resource representation   o リソースの表現
o HTTP protocol parameters representation   o HTTPプロトコルパラメータの表現
o Exchange (or Transfer) Data format representation  o 交換(または転送)データ形式の表現
o Design of error codes  o エラーコードの設計
• Runtime phase of RESTful APIs  • RESTful APIのランタイムフェーズ
o Service discovery service (SDS)   o サービスディスカバリーサービス(SDS)
o Query evaluation features  o クエリ評価機能
o Authentication layer mechanisms   o 認証レイヤーのメカニズム
1. Introduction   1. はじめに  
A RESTful Application Programming Interface (API) is the predominant architectural style of API because of its use for web applications. API users primarily interact with a resource (e.g., image, document) and a representation of that resource (i.e., Uniform Resource Identifier [URI]). Typical activities involve creating resources, accessing or retrieving those resources, modifying or manipulating their values, and transferring resource representation.   RESTfulアプリケーションプログラミングインターフェース(API)は、Webアプリケーションでの利用が一般的であるため、APIの主要なアーキテクチャスタイルとなっています。APIユーザーは主に、リソース(例:画像、文書)およびそのリソースの表現(すなわち、Uniform Resource Identifier [URI])とやり取りを行います。典型的な活動には、リソースの作成、それらのリソースへのアクセスまたは取得、値の変更または操作、およびリソース表現の転送が含まれます。
Several entities enable these activities and can be broadly classified as:  これらの活動を可能にするいくつかのエンティティがあり、大まかに次のように分類できる:
• Software entities, such as components and connectors  • コンポーネントやコネクタなどのソフトウェアエンティティ
• Encoding or representation schemes for resources, operations on resources, and communication protocols and formats for data or information transfer between artifacts  • リソースのエンコーディングまたは表現スキーム、リソースに対する操作、およびアーティファクト間のデータや情報の転送のための通信プロトコルやフォーマット
These entities collectively define the conceptual framework (or architectural elements) for RESTful APIs and are further described in Sec. 2.   これらのエンティティは、RESTful API の概念的フレームワーク(またはアーキテクチャ要素)を総体として定義しており、第 2 節でさらに詳しく説明する。
1.1. Document Goals  1.1. 文書の目的
The objectives of this document are to:  本文書の目的は以下の通りである:
1. Identify and analyze threats that are specific to RESTful APIs  1. RESTful APIに特有の脅威を特定し、分析すること
2. Provide a recommended set of mitigating controls or countermeasures for the secure design, deployment, and operation of RESTful APIs  2. RESTful APIの安全な設計、導入、および運用に向けた、推奨される一連の緩和策または対策を提供すること
1.2. Relationship With Other NIST Documents    1.2. 他のNIST文書との関係
This document follows NIST Special Publication (SP) 800-228 [1], which provides extensive analysis of threats to APIs and a comprehensive set of basic and advanced controls for protecting all API types at the pre-runtime and runtime stages of API life cycle. This document focuses on threats that are specific to RESTful APIs and provides a set of recommended controls for their secure deployment.  本ドキュメントは、NIST特別刊行物(SP)800-228 [1] に準拠している。同刊行物は、APIに対する脅威に関する詳細な分析と、APIライフサイクルの実行前および実行段階におけるあらゆるAPIタイプを保護するための基本的および高度な制御策の包括的なセットを提供している。本ドキュメントは、RESTful APIに特有の脅威に焦点を当て、その安全な導入のための推奨制御策のセットを提供する。
1.3. Document Structure  1.3. 文書の構成
This document is organized as follows:  本ドキュメントの構成は以下の通りである:
• Section 2 provides an overview of the building blocks and architectural constraints of RESTful APIs. It also outlines the advantages and drawbacks of building applications with services based on RESTful API architecture.  セクション2では、RESTful APIの構成要素とアーキテクチャ上の制約について概説する。また、RESTful APIアーキテクチャに基づくサービスを用いてアプリケーションを構築する際の利点と欠点についても概説する。
• Section 3 describes common protection requirements for APIs and briefly reviews the controls outlined in SP 800-228 [1].  セクション3では、APIに対する一般的な保護要件について記述し、SP 800-228 [1] で概説されている制御策について簡単に概観する。
• Section 4 identifies and analyzes threats that are specific to RESTful APIs in both the preruntime and runtime phases. セクション4では、実行前および実行時の両フェーズにおけるRESTful API特有の脅威を特定し、分析する。
• Section 5 provides a set of controls that are specific to secure RESTful APIs in both the 191 pre-runtime and runtime phases. セクション5では、実行前および実行時の両フェーズにおけるRESTful APIのセキュリティ確保に特化した一連の制御策を提供する。
• Section 6 provides a summary and conclusions. セクション6では、要約と結論を述べる。

 

 

 


 

まるちゃんの情報セキュリティ気まぐれ日記

・2026.03.18 米国 NIST SP 800-228 更新版 クラウドネイティブシステム向けAPI防御ガイドライン (2026.03.13)

・2025.07.04 米国 NIST SP 800-228 クラウドネイティブシステムのための API 保護に関するガイドライン (2025.06.27)

・2025.03.26 米国 NIST SP 800-228(初期公開ドラフト)クラウドネイティブシステムのAPI防御ガイドライン

 

 

|

« 米国NIST SP 800-172 Rev. 3 管理対象非機密情報の保護に関する強化されたセキュリティ要件、SP 800-172A Rev. 3 管理対象非機密情報(CUI)に対する強化されたセキュリティ要件の評価 | Main | 英国 NCSC 深刻なサイバー脅威への備え:リーダーが今すぐ行動すべき理由 - 英国のレジリエンスを共に築くための呼びかけ (2026.04.20) »

Comments

Post a comment



(Not displayed with comment.)


Comments are moderated, and will not appear on this weblog until the author has approved them.



« 米国NIST SP 800-172 Rev. 3 管理対象非機密情報の保護に関する強化されたセキュリティ要件、SP 800-172A Rev. 3 管理対象非機密情報(CUI)に対する強化されたセキュリティ要件の評価 | Main | 英国 NCSC 深刻なサイバー脅威への備え:リーダーが今すぐ行動すべき理由 - 英国のレジリエンスを共に築くための呼びかけ (2026.04.20) »