Web APIのセキュリティ

前回でお話ししたとおり、Web APIは便利に使える反面、コンピュータが利用できるという特性から悪用の幅も広がってしまいます。

利用者側で悪用されないための対策（APIを利用するためのトークンなどの機密情報管理）といったものも必要ですが、サービス提供側でもしっかり対策をしておく必要があります。

権限範囲の制限

Slackはアプリの作成段階で、API利用時に与える権限を細かく指定することができました。
アプリの新規作成段階では何の権限もついていないため、権限設定は利用者からするとめんどくさい設定ではあるのですが、逆に権限を最小限にしておくことで、悪用の被害の拡大を防ぐためのセキュリティ機構を備えていることになります。
（実は昔はほぼすべての操作を実施できる権限のあるトークンを発行することもできました。※現在は廃止）

利用者が事細かに指定する必要があるということは利用者にも「こういった権限を付けても問題ないか？」ということを考えさせ、セキュリティへの責任を担わせるという側面もあります。

機能の制限

また、サービスによってはユーザによってできる操作の一部の範囲の機能のみしかWeb APIでは提供されていないということもあります。

要するにWeb画面操作では全機能が使えるが、Web APIでは一部の機能しか使えないということです。

たしかにデータを大量に削除したりするような機能をWeb APIで使うことはほぼ無いでしょうし、そういった使われることが少ないであろう機能をわざわざ実装しても操作ミスや悪用による被害を受けるリスクが大きくなってしまいます。

データサイズの上限

Web画面は人間が見るために作られるため、表示データが多い場合はページ分割をするなどして一度に見せる情報を調整します。

一方、Web APIの場合は一度リクエスト/レスポンスでやり取りが完結するため必要なデータは一回のレスポンスで送信し、処理自体はリクエスト側に委ねることになります。

しかし、レスポンスデータが大きくなりすぎるとサーバ自体やネットワークに負荷がかかってしまうため、それを防ぐために「Web APIではレスポンスに含まれるデータは○件まで」という制限が入っていることもあります。

認証

Web APIは基本的にリクエストデータに認証情報を入れて、その情報が正しいときにのみレスポンスが返されるという形でリクエスト元を認証します。

認証情報としてSlackで用いられているようなWeb画面操作にて発行されたトークンを使う場合は、そのトークンが他社に漏れると簡単に悪用されてしまうことに注意が必要です。

そのため、トークンに有効時間をつけておいて、有効期限が切れたら発行元に前のトークンと別の認証情報をリクエストとして送信することで新しい期限付きのトークンを発行してもらうという手法や、Web APIを利用するたびに一度別の認証情報を使ったログイン処理を行い、ワンタイムパスワードとしてのトークンを発行してもらうという手法といった、「同じトークンを使い回さない」方法が利用されることも多くなってきています。

つまり、Web画面とWeb APIは別物

基本的に同じ機能が使えるとはいえ、入力方式も応答方式も異なるので、あくまでデータを提供するアプリケーションが同じなだけで、Web画面とWeb APIは別物だと考えたほうが良いです。

外部からの入力をWeb画面もしくはWeb APIが受け取り、アプリケーションに適切にデータ取得要求を行うことでそれぞれの用途に応じた（ユーザが人間なのかプログラムなのかに応じた）応答を返す仕組みなので、必要とされる機能だったり応答形式だったり細かな違いが多く存在します。

ゆえに、セキュリティもWeb画面とは異なる観点で考える必要があるのです。