API設定ミスで情報漏洩？事例から学ぶセキュリティ対策

APIを使うWebサイトで、設定ミスによる情報漏洩が起きていないか不安ではありませんか？

APIは画面から見えにくいため、どこを確認すればよいか迷いやすい部分です。

専門用語が多く、確認方法が難しく感じられるかもしれません。

APIでは、利用者の確認、渡すデータの範囲、エラー表示の設定が安全性を左右します。

ここでは、情報漏洩につながる事例を整理し、自社で確認したい項目をご紹介します。

セキュリティー診断さん

APIって何？ それを使うと何が便利なのかも知らないけど、まずいかな…？

そもそもAPIって何？便利な反面、潜む危険

APIとは、Webサイトやアプリとサーバーの間で、決められた方法に沿って情報を受け渡す仕組みです。

レストランに置き換えて考えるAPIの仕組み

レストランでは、お客様がウェイターへ注文し、ウェイターが厨房へ内容を伝えて料理を運びます。

APIも同じように、アプリから受けた注文にあたるリクエストをサーバーへ渡し、料理にあたるレスポンスを返します。

この比喩では、注文者が本人か確かめることが「認証」です。

認証とは、アクセスした人が名乗った本人かを確認することを指します。

料理を渡してよい相手か、注文できる範囲かを確かめることが「認可」です。

認可とは、認証済みの人が閲覧・操作してよい範囲を確認することを指します。

この二つを混同すると、ログイン済みでも他人の情報を見られる設定が残ることがあります。

画面上では正しく動いているように見えても、APIへ直接送るIDを書き換えると他人のデータが返るケースがあります。

そのため、画面の操作確認だけでなく、APIがリクエストごとに認可を判断しているかを確かめる必要があります。

APIを含むWeb脆弱性・技術診断の全体像も確認しておくと、点検範囲を整理しやすくなります。

API設定ミスで起きる情報漏洩の事例

設定ミスの事例は、発生したこと、原因、自社での確認項目を対応させると再発防止に使えます。

事例1：他人の情報まで閲覧できた

何が起きたかを見てみましょう。

ログインした利用者が、URLや送信値を変えるだけで、別の利用者の写真や登録情報を閲覧できる状態でした。

なぜ起きたかを確認します。

ログイン済みかという認証だけを確認し、その情報を閲覧してよいかという認可をAPI側で確認していなかったためです。

たとえば、注文履歴のURLに含まれるIDを別の番号へ変えたとき、所有者の照合がなければ他人の履歴が返る可能性があります。

自社では何を確認するかを整理します。

一般利用者、管理者など権限の異なるテストアカウントを用意し、他人のIDへ変えても情報を取得できないことを確かめます。

閲覧だけでなく、更新や削除のリクエストも拒否されるか確認すると安心です。

事例2：エラー応答から内部情報が見えた

何が起きたかを見てみましょう。

エラー応答に、プログラムの構成や顧客情報など、利用者へ見せる必要のない情報が含まれていました。

なぜ起きたかを確認します。

画面へ返すエラーと、管理者が調査に使うログを分けていなかったためです。

開発中の詳細なエラー設定を本番環境でも有効にしたままにすると、内部情報がそのまま表示されることがあります。

自社では何を確認するかを整理します。

不正な値や存在しないIDを送信し、応答に個人情報、内部パス、SQL文、秘密情報が含まれないことを確認します。

利用者向けには安全な案内だけを返し、調査用の詳細はアクセスを制限したログで追える状態が理想です。

Shopifyのセキュリティ診断｜ECサイトで確認すべきリスクでは、顧客情報や決済を扱うECサイトの確認点も紹介しています。

セキュリティー診断さん

え、そんな簡単なことで情報が漏れちゃうの！ ？ うちのサイトも確認しないとまずいかも…！

事例に対応したAPI設定の確認項目

確認項目は、認証・認可、返却データ、エラー表示・ログの三つに分けると漏れを防ぎやすくなります。

1.認証と認可を確認する

• ログインしていない状態では、保護されたAPIを利用できない
• 一般利用者は、他人や管理者の情報を閲覧・変更できない
• URLやIDを変えても、許可されていないデータへアクセスできない
• 権限変更後は、古い権限のまま操作を続けられない

本人確認だけで終えず、「その人がそのデータを操作してよいか」をAPIごとに確かめられているでしょうか？

権限の組み合わせが多くて確認が難しい場合は、役割ごとに「閲覧・作成・更新・削除」の期待結果を一覧にすると漏れを見つけやすくなります。

どの権限から試すか迷ったときは、最も制限の少ない一般利用者から確認すると整理しやすくなります。

2.返却データを必要最小限にする

• 画面で使わない住所、電話番号、メールアドレスを返していない
• パスワード、アクセストークン、秘密鍵などを応答へ含めていない
• 一覧APIで必要以上の件数や項目を取得できない
• 管理者向け項目を一般利用者へ返していない

画面に表示されなくても、ブラウザの開発者ツールではAPIの応答を確認できます。

表示側で隠すだけではなく、APIから不要な情報を返さない設定にしましょう。

返却項目を減らすと、万が一アクセス制御に問題が起きた場合でも、漏れる情報の範囲を抑えやすくなります。

3.エラー表示とログを分ける

• 利用者向け応答に内部パス、SQL文、個人情報を表示しない
• 調査に必要な詳細は、閲覧権限を制限したログへ記録する
• ログへパスワード、トークン、決済情報をそのまま残さない
• 誰が、いつ、どのAPIを操作したか追跡できる

ログを残していても、必要な操作を検索できなければ原因調査に時間がかかります。

日時、利用者、対象API、結果を結び付けて確認できるか、実際のテスト操作で確かめておきましょう。

API診断の対象や進め方は、APIセキュリティ診断とREST APIの確認方法で詳しく確認できます。

診断方法を比較する場合は、既存のWebアプリ脆弱性診断ツール比較も参考になります。

自力で判断しにくいAPI設定は診断で確認する

APIの認証・認可は、ログイン前の画面だけを見ても安全性を判断できません。

一般利用者と管理者など複数の権限で、ログイン後のAPIが正しく制限されるかを確認する必要があります。

「自分のアカウントでは問題なく動くから大丈夫」と判断せず、権限の異なる条件を比べることが大切です。

• 対象となるAPIのURLと仕様
• 認証方法と、診断専用のテストアカウント
• 一般利用者や管理者など、確認したい権限の種類
• 実施してよい時間帯と、避けたい操作
• 修正後に同じ項目を再確認できるか

依頼方法を検討するときは、セキュリティ診断を内製・外注する際の費用と判断基準も確認しておくと選びやすくなります。

公開画面から到達できるAPIと、テストアカウントが必要なログイン後の機能では、診断に必要な準備が異なります。

APIの仕様書がない場合でも、対象画面、想定する利用者、実行してよい操作をまとめておくと相談しやすくなります。

修正後は同じアカウントと条件で再確認し、許可されていない操作が拒否されることを確かめましょう。

専門知識がなくても手軽に診断を

「専門家を雇うのは難しい。でも、自分だけでは不安…。」

そんな悩みを解決するのが、AI技術を活用したWebサイトのセキュリティ診断サービス、『セキュリティー診断さん』です。

専門家を探したり、難しい契約をしたりする必要はありません。

AIがあなたの代わりに、セキュリティの専門家のように、サイトの「健康状態」を隅々までチェックしてくれます。

『セキュリティー診断さん』の最大の特徴は、AIが「本物のサイバー犯罪者」と同じ手口で、あなたのWebサイトに侵入を試みることです。

もちろん、これは実際に攻撃するわけではなく、あくまで弱点がないかを確かめるための「安全なテスト」です。

実際に攻撃者が使うさまざまな方法でサイトをテストすることで、人間では見逃しがちな隠れた弱点も発見できる可能性があるのです。

もちろん、今回ご説明したAPIに関する設定ミスもしっかりチェックします。

API設定を定期的に確認して情報漏洩を防ごう

APIの情報漏洩は、認証・認可、返却データ、エラー表示・ログの設定ミスから起こります。

まずは事例に対応した確認項目を使い、自社のAPIで同じ問題が起きないかを確かめましょう。

自分たちでは気づけない弱点を早期に発見するには、『セキュリティー診断さん』が役立ちます。

あなたのビジネスとお客様の未来を守るために、ぜひ一度、セキュリティ診断を検討してみてください。

セキュリティー診断さん

ヨシ！ まずは診断から始めて、うちのサイトが安全か確かめてみるよ(๑•̀ㅂ•́)و✧