oData は、オープン API を通じて構造化データを公開する方法にすぎません。特定の形式のセキュリティは必要ありません。完全にオープンなデータセット (ウィキ データベースのような) や、誰でも読めるが私的な書き込みが可能なデータセット (国会議員による投票のデータベースなど、誰でも読めるが更新できるのは自分だけ) を持つことができます。また、より複雑なセキュリティ構造 (顧客が自分の履歴のみを照会できるビデオ レンタル ストアなど) もサポートしています。
あなたの特定の懸念について:
- ADO.NET Data Services を oData サーバーとして使用している場合、SQL インジェクションは不可能です。
IQueryable
受信した oData リクエストは解析され、すべての値を適切にエスケープする に渡されます。
- ビジネス層/データ層の検証は同じままです。oData は、データ レイヤー (またはデータベースのように見える場合はビジネス レイヤー) 用の API を提供するだけです。
- 許可しない限り、データへの不正アクセスは不可能です。ADO.NET Data Services のデフォルトでは、すべてのアクセス (読み取り専用アクセスであっても) を許可しないため、すべてのアクセスを明示的に承認する必要があります。
- 「ロー ダンプ」シナリオこそが、 oData が非常に便利な理由です。これは、壊れやすい画面スクレイピング「ソリューション」に依存する代わりに、Web を介してデータ ソースの効率的なクエリを実行できるプロトコルです。誰かに情報を知られたくない場合は、公開しないでください。
現在 (私の知る限り)、ADO.NET Data Services は利用可能な唯一の oData プロバイダーであり、既定で安全です。デフォルトで安全でない、または SQL インジェクションを許可する oData プロバイダーを他の誰かが作成できると思いますが、それは愚かなことです。
また、oData は認証の概念とは完全に切り離されていることに注意してください。API にとって意味のある認証を使用するかどうかは、ユーザー次第です。oData がさまざまな形式の認証でどのように機能するかを説明する、WCF チームからの素晴らしい最近の一連のブログ投稿があります。