Prompt
あるサービスのAPIのURLを入手したとする。
そして、そのURLにリクエストを送ると…(正常なものか、それとも不正なものか…)
まあ、セキュリティが良ければ、あまり変なことにはならないのかな？
そうだね、その認識は基本的に正しいよ！👍
あるサービスのAPIのURLを見つけて、そこにリクエストを送ったとしても、そのAPIのセキュリティがしっかりしていれば、変なことにはならないように設計されているはずだ。
APIセキュリティの基本
APIのセキュリティは、**「誰が」「何を」「どのように」**アクセスしようとしているかを厳密にチェックすることによって保たれている。
-
認証 (Authentication): 「誰が」アクセスしているかを特定するプロセス。
-
APIキー、トークン、OAuthといった方法で、リクエストを送っているのが正規のユーザーかどうかを確認する。
-
もし認証情報がない、または間違っているリクエストが来たら、HTTP 401 Unauthorizedや403 Forbiddenといったエラーを返してアクセスを拒否する。
-
-
認可 (Authorization): 「何に」アクセスできるかを制御するプロセス。
-
例えば、ユーザーAは自分のプロフィールデータにはアクセスできるけど、他のユーザーBのデータにはアクセスできない、といった権限を設定する。
-
仮に認証は通っても、アクセス権限がないリクエストにはエラーを返す。
-
-
入力値の検証 (Input Validation): 「どのように」アクセスされているかをチェックする。
-
APIが期待するデータ形式（例えばJSON）以外のものが送られてきた場合、それを拒否する。
-
データベースを破壊しようとするSQLインジェクションや、コマンドを実行しようとする悪意のあるデータが含まれていないかチェックする。
-
不正なリクエストをするとどうなる？
例えば、SNSの投稿を削除するAPIを考えてみよう。
DELETE /api/posts/{postId}
-
認証なしでリクエスト →
401 Unauthorized- 「お前は誰だ？」と怒られて、リクエストは即座に拒否される。
-
認証済みだけど、他人の投稿IDを指定してリクエスト →
403 Forbidden- 「君にはこの投稿を削除する権限がないよ」と拒否される。
-
許可されていないデータ形式でリクエスト →
400 Bad Request- 「送られてきたデータがおかしいよ」と拒否される。
このように、セキュリティがしっかりしたAPIは、想定外のデータやアクセスをすべて弾くように作られている。
もちろん、これは「完璧な」APIの場合だ。世の中には、まだセキュリティの甘いAPIも存在するかもしれない。ただ、最近のモダンなAPI開発では、こうしたセキュリティ対策は基本中の基本。
君がAPIを触るなら、まずは認証や認可の方法をドキュメントで確認して、正しい方法でリクエストを送るのが一番安全で確実な方法だよ！😉