認可

Authorization Cheat Sheet

原典: Authorization Cheat Sheet（OWASP Cheat Sheet Series）
原文: GitHub 上の Markdown
底本: bac04fb5（2026-07-29 時点）
ライセンス: CC BY-SA 4.0（原典と同一。訳文も同ライセンスで再配布できます）

はじめに

認可は「要求された動作やサービスが、特定の実体に対して承認されているかを確かめる処理」と定義できる（NIST）。認可は、実体の身元を確かめる処理である認証とは別のものである。ソフトウェアを設計し開発するときは、この区別を意識しておくことが重要である。（ユーザー名とパスワードなどによって）認証された利用者が、システム上で技術的に可能なすべてのリソースへアクセスし、すべての動作を行う権限を持っているとは限らない。たとえばある Web アプリケーションに一般の利用者と管理者がいて、認証されていても一般の利用者には許されない操作を管理者だけが行える、という場合がある。加えて、リソースへのアクセスに認証が常に必要とも限らない。認証されていない利用者が、画像やログインページのような公開のリソース、あるいは Web アプリケーション全体へアクセスすることを認可されている場合もある。

このチートシートの目的は、堅牢で、アプリケーションの業務上の文脈に適し、保守しやすく、拡張しやすい認可のロジックを実装する開発者を助けることである。ここで示す指針は開発の全段階に適用できるものであり、多様な開発環境の必要に応えられる柔軟さを備える。

認可のロジックに関する欠陥は、Web アプリケーションにとって注目すべき懸念である。アクセス制御の不備は OWASP の 2021 年の Top 10 で最も懸念される Web の脆弱性に位置づけられ、MITRE の CWE プログラムは悪用の可能性を「高」と評している。さらに Veracode の State of Software Vol. 10 によれば、アクセス制御は調査対象のうち存在の割合は最も低いほうであったにもかかわらず、OWASP Top 10 のリスクのうち悪用やセキュリティ事故に関わることが比較的多いものであった。

認可の欠陥の悪用によって生じうる影響は、形態も深刻度も大きく変わる。攻撃者は、保護されるべきリソースを読み、作り、変更し、削除できるかもしれない（したがってその機密性、完全性、可用性が危険にさらされる）。ただし、そうした行為の実際の影響は、侵害されたリソースの重要性と機微さに必然的に結びつく。したがって、認可の欠陥の悪用が成功したときの事業上の損失は、非常に小さいものから極めて大きいものまで幅がある。

認可の弱点は、まったく認証されていない外部の者も、認証された（ただし必ずしも認可されていない）利用者も利用できる。悪意のない実体の率直な誤りや不注意が認可の回避を招くこともあるが、アクセス制御の脅威が完全に現実化するには通常は悪意が必要である。水平的な権限昇格（他の利用者のリソースへアクセスできること）は、認証された利用者が利用しうるとくによくある弱点である。アクセス制御に関する欠陥は、悪意ある内部の者にも外部の者にも、あらゆる形態の機微なリソース（データベースのレコード、静的ファイル、個人を特定できる情報など）を閲覧、変更、削除させたり、新しいアカウントの作成や高額な注文の実行のような、権限のない動作を行わせたりする。さらに、アクセス制御に関するログが適切に整備されていなければ、そうした認可の違反は検出されないまま、あるいは少なくとも特定の個人や集団に帰せられないままになる。

推奨

最小権限を強制する

安全の概念としての最小権限は、利用者に対して業務の遂行に必要な最小限の権限のみを割り当てる原則を指す。これはシステム管理において最もよく適用されるが、ソフトウェア開発者にも関係する。最小権限は水平方向にも垂直方向にも適用しなければならない。たとえば経理担当者と営業担当者が組織の階層上で同じ水準にあっても、業務の遂行に必要なリソースは異なる。経理担当者に顧客のデータベースへのアクセスを与えるべきではないだろうし、営業担当者が給与のデータにアクセスできるべきではない。同様に、営業部門の責任者は部下より多くの権限を必要とする可能性が高い。

アプリケーションで最小権限を強制しないと、機微なリソースの機密性が危険にさらされる。緩和策は主にアーキテクチャと設計の段階で適用される（CWE-272 を参照）が、この原則は SDLC の全体を通じて扱わなければならない。

次の点と最良の慣行を検討する。

設計の段階で、信頼の境界が定義されている状態にする。システムにアクセスする利用者の種類、公開されるリソース、それらのリソースに対して行われうる操作（読み取り、書き込み、更新など）を列挙する。利用者の種類とリソースのすべての組み合わせについて、その利用者が（役割や他の属性に基づいて）そのリソースに対して行えなければならない操作が何であるか、あるいはないのかを決める。ABAC のシステムでは、属性のすべての分類が考慮されている状態にする。たとえば営業担当者は、勤務時間中に内部のネットワークから顧客のデータベースへアクセスする必要はあるが、深夜に自宅からアクセスする必要はないかもしれない。
設計の段階で洗い出した権限が正しく強制されていることを検証するテストを作る。
アプリケーションを配備したあとは、システムの権限を定期的に見直して「権限の忍び寄り」を確認する。すなわち、現在の環境における利用者の権限が、設計の段階で定義したもの（に正式に承認された変更を加減したもの）を超えていない状態にする。
利用者に権限を追加するほうが、以前から享受していた権限を取り上げるより容易であることを忘れない。SDLC の早い段階で最小権限を注意深く計画し実装しておけば、あとで広すぎると判断される権限を取り消す必要が生じるリスクを減らせる。

既定で拒否する

アクセス制御の規則に明示的に一致するものがない場合でも、実体が特定のリソースへのアクセスを要求している状況でアプリケーションが中立のままでいることはできない。アプリケーションは暗黙にでも明示的にでも、要求されたアクセスを拒否するか許可するかの判断を常に下さなければならない。アクセス制御に関するロジックの誤りやその他の間違いは起こりうるものであり、アクセスの要件が複雑な場合はとくにそうである。したがって、ありうるすべての要求に一致させることを、明示的に定義した規則だけに完全に頼るべきではない。安全のために、アプリケーションは既定でアクセスを拒否するよう設定するべきである。

次の点と最良の慣行を検討する。

最初の開発時にも、アプリケーションが新しい機能やリソースを公開するときにも、「既定で拒否」の姿勢を採る。アクセスを既定の立場と想定するのではなく、特定の権限を特定の利用者や集団に与えた理由を明示的に説明できる状態にする。
一部のフレームワークやライブラリ自体が既定で拒否する方針を採っていることもあるが、フレームワークやライブラリの既定値に頼るのではなく、明示的な設定を優先するべきである。サードパーティのコードのロジックと既定値は時とともに変わりうるが、その変更が特定のプロジェクトにどう影響するかを開発者が完全に把握しているとは限らない。

すべてのリクエストで権限を検証する

リクエストが AJAX のスクリプトから開始されたのか、サーバー側から開始されたのか、その他の源から来たのかに関わらず、すべてのリクエストで権限を正しく検証するべきである。そうした確認を行う技術は、すべてのメソッドやクラスに個別に適用する必要があるものではなく、アプリケーション全体に及ぶ大域的な設定を許すものであるべきである。攻撃者は入り口を一つ見つければよいことを忘れない。アクセス制御の確認が一つでも「漏れて」いれば、リソースの機密性や完全性が危険にさらされうる。リクエストの大半で権限を正しく検証しているだけでは不十分である。一貫した権限の確認を行うのに役立つ具体的な技術には次のものがある。

Java／Jakarta EE のフィルタ。Spring Security の実装を含む
Django のミドルウェア
.NET Core のフィルタ
Laravel のミドルウェア

採用する道具と技術の認可ロジックを徹底的に精査し、必要なら独自のロジックを実装する

今日の開発者は、堅牢で複雑なロジックを最小限の労力でアプリケーションに組み込める膨大なライブラリ、プラットフォーム、フレームワークを使える。しかしこれらを、あらゆる開発上の問題に対する手軽な万能薬とみなしてはならない。開発者には、そうした枠組みを責任をもって賢く使う義務がある。適切なアクセス制御に関わるフレームワークやライブラリの選択について、一般的な懸念は二つある。開発者側の設定の誤りや設定の欠如と、構成要素そのものに含まれる脆弱性である（これらの話題の一般的な指針は A6 と A9 を参照）。

他の点では安全に開発されたアプリケーションであっても、サードパーティの構成要素の脆弱性によって、攻撃者が通常の認可の対策を回避できることがある。こうした懸念は、実績のない、あるいは保守の行き届かないプロジェクトに限られるものではなく、最も堅牢で人気のあるライブラリやフレームワークにも及ぶ。複雑で安全なソフトウェアを書くことは難しい。最も有能な開発者が高品質なライブラリやフレームワークに取り組んでいても、誤りは生じる。アプリケーションに組み込むサードパーティの構成要素はいずれも、認可の脆弱性を抱えている、あるいは抱えるようになる可能性があると想定する。重要な考慮点を挙げる。

脆弱な構成要素を検出して対応する手続きを作り、維持し、それに従う。
Dependency Check のような道具を SDLC に組み込み、ベンダー、NVD、その他の関連する情報源からのデータフィードの購読を検討する。
多層防御を実装する。適切なアクセス制御を強制する唯一のものとして、単一のフレームワーク、ライブラリ、技術、対策に依存しない。

設定の誤り（あるいは設定の完全な欠如）は、開発の土台にする構成要素が認可の不備につながるもう一つの大きな領域である。これらの構成要素は通常、広い利用者層に向けた比較的汎用の道具として意図されている。最も単純な用途を除けば、特定のアプリケーションや環境の固有の要件を満たすために、これらのフレームワークやライブラリを調整するか、追加のロジックで補わなければならない。これは認可を含む安全性の要件が関わる場合にとくに重要になる。認可に関する注目すべき設定上の考慮点を挙げる。

認可のロジックの土台にする技術を徹底的に理解する時間をとる。その構成要素が提供する認可のロジックは、アプリケーションの固有の安全性の要件に対して不十分かもしれないという認識のもとで、その技術の能力を分析する。作り込まれたロジックに頼るのは便利だが、それが十分であることを意味しない。アプリケーションの安全性の要件を満たすには、独自の認可のロジックが必要になることも十分にあると理解する。
ライブラリ、プラットフォーム、フレームワークの能力に認可の要件を導かせない。認可の要件を先に決め、そのうえでその要件に照らしてサードパーティの構成要素を分析する。
既定の設定に依存しない。
設定を試験する。サードパーティの構成要素に施した設定が、自分の環境で意図どおりに働くと単に想定しない。文書は誤解されうるし、曖昧、古い、あるいは端的に不正確なこともある。

RBAC より、属性や関係に基づくアクセス制御を優先する

ソフトウェア工学では、二つの基本的なアクセス制御の形が広く使われている。役割に基づくアクセス制御（RBAC）と属性に基づくアクセス制御（ABAC）である。第三の、より新しいモデルとして関係に基づくアクセス制御（ReBAC）も人気を得ている。どのモデルを選ぶかは SDLC 全体に大きく影響するので、できるだけ早く決めるべきである。

RBAC は、利用者に割り当てられた役割に基づいてアクセスを許可または拒否するモデルである。権限は実体に直接割り当てられるのではなく、役割に結びつけられ、実体は自身に割り当てられた役割の権限を継承する。一般に、役割と利用者の関係は多対多になりうるし、役割は階層を持ちうる。
ABAC は「主体が対象に対して操作を行う要求が、主体に割り当てられた属性、対象に割り当てられた属性、環境の条件、およびそれらの属性と条件によって規定された一連の方針に基づいて許可または拒否される」アクセス制御のモデルと定義できる（NIST SP 800-162 7 ページ）。NIST SP 800-162 の定義では、属性は名前と値の組として表現でき、主体、対象、環境に割り当てられる特性にすぎない。職務上の役割、時刻、プロジェクト名、MAC アドレス、作成日は、ABAC の実装の柔軟性を示すごく一部の例である。
ReBAC は、リソース間の関係に基づいてアクセスを許可するモデルである。たとえば、投稿を作成した利用者だけがそれを編集できるようにする。これは Twitter や Facebook のようなソーシャルネットワークのアプリケーションでとくに必要になる。利用者は自分のデータ（ツイートや投稿）へのアクセスを、自分が選んだ人（友人、家族、フォロワー）に限りたいからである。

RBAC には長い歴史があり今日も開発者のあいだで人気があるが、アプリケーションの開発では通常 ABAC と ReBAC を優先すべきである。 RBAC に対する利点を挙げる。

細かい粒度の複雑な論理式に対応する。RBAC では役割の有無によってアクセスの判断が下される。すなわち、要求する実体について考慮される主な特性は、それに割り当てられた役割である。この単純なロジックは、オブジェクト単位のアクセス制御、水平方向のアクセス制御、複数の要素を要する判断をうまく支えられない。
- ABAC は、考慮できる特性の数も種類も大きく広げる。ABAC では「役割」や職務も主体に割り当てられる属性の一つになりうるが、それを単独で考慮する必要はない（要求されたアクセスにその特性が関係しないなら、まったく考慮しなくてもよい）。さらに ABAC は、時刻、使われた端末の種類、地理的な位置のような環境上のその他の動的な属性を組み込める。通常の業務時間外や、利用者が必須の研修を最近修了していない場合に機微なリソースへのアクセスを拒否することは、RBAC では満たすのに苦労するアクセス制御の要件を ABAC が満たせる例である。したがって ABAC は最小権限の原則に応えるうえで RBAC より有効である。
- ReBAC は、役割だけでなく直接の対象と直接の利用者のあいだに関係を割り当てられるので、細かい粒度の権限を可能にする。AND や NOT のような代数的な演算子に対応する仕組みもあり、「この利用者が対象に対して関係 X を持ち関係 Y を持たないならアクセスを許可する」といった方針を表現できる。
堅牢さ。大規模なプロジェクトや役割が多数ある場合、役割の確認を漏らしたり誤って行ったりしやすい（OWASP C7: Enforce Access Controls）。これはアクセスが多すぎることも少なすぎることも招く。役割の階層がなく、意図した結果を得るために複数の役割の確認を連ねなければならない RBAC の実装ではとくにそうである（if(user.hasAnyRole("SUPERUSER", "ADMIN", "ACCT_MANAGER")) のような形になる）。
速度。RBAC では、システムが定義する役割が多すぎると「役割の爆発」が起こりうる。利用者が資格情報と役割を、サイズ上限のある HTTP ヘッダのような手段で送る場合、その利用者のすべての役割を含める余地がなくなるかもしれない。この問題の実行可能な回避策は、利用者 ID のみを送り、アプリケーションが役割を取得することであるが、これはすべてのリクエストの遅延を増やす。
マルチテナントと組織をまたぐ要求に対応する。RBAC は、異なる組織や顧客が同じ保護されたリソース群にアクセスする必要がある用途には向かない。そうした要件を RBAC で満たすには、マルチテナントの環境で顧客ごとに規則の集合を設定する、あるいは組織をまたぐ要求のためにアイデンティティを事前に用意しておくといった、非常に扱いにくい方法が必要になる（OWASP C7、NIST SP 800-162）。対して ABAC の実装は、属性が一貫して定義されているかぎり、アクセス制御の判断を「適切な安全性の水準を保ちながら、同一の、あるいは別個の基盤で実行し管理する」ことを可能にする（NIST SP 800-162 6 ページ）。
管理の容易さ。RBAC の初期の設定は ABAC より簡単なことが多いが、この短期的な利点は、システムの規模と複雑さが増すにつれて速やかに失われる。当初は User と Admin のような単純な役割がいくつかあれば足りるアプリケーションもあるが、本番のアプリケーションでそれが長く保たれることはまずない。役割の数が増えるにつれ、コードとロジックへの信頼を築くための重要な工程であるテストと監査の両方が難しくなる（OWASP C7）。対して ABAC と ReBAC は表現力がはるかに高く、現実の関心事をよく反映する属性と論理式を組み込め、アクセス制御の必要が変わったときの更新が容易であり、方針の管理を、強制とアイデンティティの供給から分離することを促す（NIST SP 800-162。これらの利点を示す標準として XACML-V3.0 も参照）。

参照用の ID は、推測されても改変されてもアクセスできない状態にする

アプリケーションはしばしば、オブジェクトの位置づけと参照に使う内部のオブジェクト識別子（口座番号やデータベースの主キーなど）を露出させる。この ID は、クエリパラメータ、パス変数、「隠し」フォーム項目、その他の場所に露出しうる。たとえば次のようなものである。

https://mybank.com/accountTransactions?acct_id=901

この URL からは、アプリケーションが取引の一覧を返し、返される取引が特定の口座（acct_id パラメータで示された口座）に限られると想定するのが妥当である。しかし利用者が acct_id パラメータの値を 523 のような別の値に変えたらどうなるか。その利用者は、自分のものでない別の口座に紐づく取引を閲覧できるのか。できないとして、その失敗は単に口座 "523" が存在しない、あるいは見つからないという結果なのか、それともアクセス制御の確認が失敗した結果なのか。この例は単純化しすぎているかもしれないが、アプリケーション開発における非常によくある安全上の欠陥、CWE 639: Authorization Bypass Through User-Controlled Key を示している。この弱点が悪用されると、認可の回避、水平方向の権限昇格、そして頻度は低いが垂直方向の権限昇格を招きうる（CWE-639 を参照）。この種の脆弱性は、安全でない直接オブジェクト参照（IDOR）の一形態でもある。以下では、この弱点とありうる緩和策を述べる。

上の例では、参照用の ID が利用者に露出して容易に改変できただけでなく、かなり予測しやすい、おそらく連番の値であるように見える。これらの ID を隠したりランダム化したりして推測しにくくする手法はいくつもあるが、そうした方法は一般にそれ単体では不十分である。クエリパラメータやその他の場所でオブジェクトの識別子を推測して操作できるという理由だけで、利用者が権限を持たないリソースへアクセスできてはならない。何らかの形の隠すことによる安全性に頼るのではなく、背後のオブジェクトそのものや識別子そのものへのアクセスを制御することに焦点を置く。この弱点に対して推奨される緩和策を挙げる。

可能な場合は、識別子を利用者に露出させることを避ける。たとえば口座の詳細のようなオブジェクトは、現在認証されている利用者の身元と属性のみに基づいて取得できるはずである（安全に実装された JSON Web Token（JWT）やサーバー側のセッションに含まれる情報などを通じて）。
OWASP ESAPI のような道具を使い、利用者やセッションに固有の間接参照を実装する（OWASP 2013 Top 10 - A4 Insecure Direct Object References を参照）。
アクセスされる特定のオブジェクトや機能について、すべてのリクエストでアクセス制御の確認を行う。ある種類のオブジェクトへのアクセス権を利用者が持つことは、その種類のすべてのオブジェクトへのアクセス権を持つべきことを意味しない。

静的リソースにも認可の確認を強制する

静的リソースを保護することの重要性は見過ごされがちであり、少なくとも他の安全上の懸念の陰に隠れがちである。データベースや類似のデータストアの保護は、安全性を意識するチームから当然ながら大きな注意を集めるが、静的リソースも適切に保護しなければならない。保護されていない静的リソースはあらゆる形態のサイトや Web アプリケーションにとって問題であるが、近年はクラウドストレージ（Amazon S3 のバケットなど）における保護の不十分なリソースが目立つようになった。静的リソースを保護するときは次を検討する。

静的リソースがアクセス制御の方針に組み込まれている状態にする。静的リソースに必要な保護の種類は、必然的に文脈に強く依存する。一部の静的リソースは公開アクセス可能で問題ないこともあり、他のものは利用者と環境の属性が非常に限定的な条件を満たすときのみアクセスできるべき場合もある。したがって、対象となる個々のリソースに含まれるデータの種類を理解することが決定的に重要である。正式なデータ分類の体系を定め、アプリケーションのアクセス制御のロジックに組み込むべきかを検討する（データ分類の概観はこちらを参照）。
静的リソースの保存に使うクラウドのサービスは、ベンダーが提供する設定の選択肢と道具を用いて保護されている状態にする。クラウド事業者の文書を確認する（実装の詳細は AWS、Google Cloud、Azure の指針を参照）。
可能な場合は、アプリケーションの他のリソースや機能を保護するのと同じアクセス制御のロジックと機構で静的リソースを保護する。

認可の確認が正しい場所で行われていることを確かめる

開発者はクライアント側のアクセス制御の確認に依存しては決してならない。そうした確認は利用者体験の改善のためには許容されうるが、リソースへのアクセスを許可または拒否する決定的な要因には決してしてはならない。クライアント側のロジックはしばしば容易に回避できる。アクセス制御の確認は、サーバー側、ゲートウェイ、あるいはサーバーレス関数で行わなければならない（OWASP ASVS 4.0.3, V1.4.1 および V4.1.1 を参照）。

認可の確認が失敗したときは安全に抜ける

アクセス制御の確認の失敗は、保護されたアプリケーションでは通常起こる出来事である。したがって開発者はそうした失敗を想定し、安全に扱わなければならない。失敗の扱いが不適切だと、アプリケーションが予測できない状態に置かれうる（CWE-280: Improper Handling of Insufficient Permissions or Privileges）。具体的な推奨を挙げる。

どれほど起こりにくく見えても、すべての例外とアクセス制御の確認の失敗が扱われている状態にする（OWASP Top Ten Proactive Controls C10: Handle all errors and exceptions）。これは、失敗した確認をアプリケーションが常に「修正」しようとすべきという意味ではない。単純なメッセージや HTTP のステータスコードだけで足りることが多い。
アクセス制御の確認の失敗を扱うロジックを一箇所に集める。
例外と認可の失敗の扱いを検証する。どれほど起こりにくくても、そうした失敗によってソフトウェアが認可の回避を招きうる不安定な状態に置かれない状態にする。
システムのログやデバッグの出力のような機微な情報が、エラーメッセージに露出しない状態にする。設定を誤ったエラーメッセージは、アプリケーションの攻撃対象領域を広げうる（CWE-209: Generation of Error Message Containing Sensitive Information）。

適切なログを実装する

ログはアプリケーションセキュリティにおいて最も重要な検知の対策の一つである。ログと監視の不足は OWASP の 2021 年の Top 10 において最も重大な安全上のリスクの一つとして認識されている。適切なログは悪意ある活動を検知できるだけでなく、事故後の調査における貴重な資料になり、アクセス制御やその他の安全に関する問題の切り分けに使え、セキュリティ監査にも役立つ。初期の設計と要件の段階では見過ごされやすいが、ログは全体的なアプリケーションセキュリティの重要な構成要素であり、SDLC の全段階に組み込まなければならない。ログについての推奨を挙げる。

分析のために容易に解析できる、一貫したよく定義された形式で記録する。OWASP Top Ten Proactive Controls C9 によれば、Apache Logging Services は多数の言語とプラットフォームに対応する例の一つである。
記録する情報の量を注意深く決める。これは具体的なアプリケーションの環境と要件に応じて決める。ログが多すぎることも少なすぎることも安全上の弱点とみなされうる（CWE-778 と CWE-779 を参照）。少なすぎると悪意ある活動が検知されないままになり、事故後の分析の有効性が大きく下がる。多すぎると資源を圧迫して過剰な誤検知を招くだけでなく、機微なデータを不必要に記録する結果にもなりうる。
時計とタイムゾーンがシステム間で同期している状態にする。事故対応の最中と事後に攻撃の順序を組み立てるうえで、正確さは決定的に重要である。
アプリケーションのログを中央のログサーバーや SIEM に集約することを検討する。

認可のロジックに単体テストと結合テストを用意する

単体テストと結合テストは、アプリケーションが期待どおりに、かつ変更をまたいで一貫して動くことを検証するために不可欠である。アクセス制御のロジックの欠陥は、とくに要件が複雑な場合にわかりにくいものになりうる。しかしアクセス制御における小さなロジックや設定の誤りでも、深刻な結果を招きうる。専用のセキュリティテストやペネトレーションテストの代わりにはならないが（アクセス制御に関するこの話題の優れた手引きは OWASP WSTG 4.5 を参照）、アクセス制御のロジックの自動化された単体テストと結合テストは、本番に到達する安全上の欠陥の数を減らす助けになる。これらのテストは安全上の問題のうち「手の届きやすいもの」を捕まえるのに向いており、より巧妙な攻撃経路には向かない（OWASP SAMM: Security Testing）。

単体テストと結合テストは、この文書で扱った考え方の多くを取り込むことを目指すべきである。たとえば、アクセスは既定で拒否されているか。アクセス制御の確認が失敗したとき、異常な条件下であってもアプリケーションは安全に終了するか。 ABAC の方針は適切に強制されているか。単純な単体テストと結合テストが、熟練した攻撃者による手作業のテストに取って代わることは決してないが、安全上の問題を手作業のテストよりはるかに少ない資源で速やかに検出し修正するための重要な道具である。

認可