この文書は2016年以降更新されていません

アクセス制御に関するチートシート

OWASP 作成
ジャンプ先: 移動、 検索
[編集]

ドラフト版チートシート - 編集中

この資料は、アプリケーションにアクセス制御セキュリティを備えるための、簡単でわかりやすい実用的なガイダンスを提供することに重点を置いています。Web アプリケーションにおけるアクセス制御を設計、作成、および保守管理する開発者、レビュー担当者、設計者、アーキテクトにガイダンスを提供することを目的としています。

アクセス制御と認可について

認可とは、特定のリソースに対するアクセスリクエストを許可または拒否するプロセスのことです。認可と認証、この 2 つの用語とその定義は頻繁に混同されますが、同じものではないことに注意する必要があります。認証とは、識別情報の提示と検証のことです。ユーザー名とパスワードによる単純な認証方式を使用するシステムの場合の認証処理は、ユーザー名を受け取り、パスワードを使用して識別情報を検証します。認可とは、アクセス制御のプロパティを実施することです。すなわち、認証が正常に完了した際にアクセス権を適切に割り当てます。

アクセス制御とは、システムのリソースや機能へのアクセスリクエストを認可するための方法またはメカニズムのことです。

リソースへのアクセスを要求するエンティティがサブジェクト (主体) であり、リソースがオブジェクト (客体) であることを理解している必要があります。 通常、Web アプリケーションでは、さまざまなユーザー (ユーザー毎に権限は異なる) にアプリケーションを使用させたり、管理者にアプリケーション管理作業を許可したりするためにアクセス制御が必要になります。アクセス制御には、さまざまな方法があります。リスク評価により脅威と脆弱性を特定し、リスク値を許容できるレベルにまで下げられる最適な方法を選択する必要があります。

アクセス制御ポリシー

Web 開発には、なぜアクセス制御ポリシーが必要なのでしょうか。

アクセス制御ポリシーを用意する目的は、アーキテクト、設計者、開発者、およびサポートチームに、セキュリティ要件を明確に説明し、組織内の複数の Web アプリケーションプロジェクトにおけるアクセス制御の設計、実装に整合性を持たせることです。

アクセス制御ポリシーのメンテナンスに関するガイドライン

1. 組織にとって重要なアクティビティを一覧にし、それらに配慮したポリシーにします。

例えば、 次のようなポリシーが考えられます。 

     a. アクセス制御機能の設計に先立って、リスク評価の実施を要件とする 
     b. リスク評価の結論に基づいてアクセス制御モデルを決定する 
     c. クライアント側で行うアクセス制御において追加の制御機能が必要かどうか

2. 第 1 項を適切に維持するために、少なくとも 1 年に 1 回は、アクセス制御ポリシーをレビューします。

機能のリスク評価を行い、アクセス制御の実装に適したモデルに到達する

アクセス制御の方法を決定する前にアプリケーションのリスク評価を行います。その結果、例えば、最高機密データを扱うアプリケーションには強制アクセス制御が必要、社内で使用する財務アプリケーションにはロールベースのアクセス制御が適切であり、あわせて頻繁なアクセスのレビューも必要、といったような検討結果が得られます。

リスク評価の例を次に示します。

1. リスク評価の対象となるデータ要素を特定します。

2. これらのデータ要素について、機密性、完全性、可用性の値を特定します。

3. データ要素の機密性、完全性、可用性が侵害された場合の組織への影響度を特定します。

4. 侵害の発生確率を特定します。

影響度と発生確率に基づいて、次を行います。

1. 適切なアクセス制御モデルを特定します。

2. アクセス制御を必要とするセグメントを特定します。

3. 以下は、考慮に入れる必要のあるセグメントの例です。 

         a. API
         b. Web アプリケーション
         c. サーバー
         d. ネットワーク
         e. データベース
         f. 物理的境界

ロールベースアクセス制御 (RBAC)

ロールベースアクセス制御 (RBAC) では、組織内またはユーザーベース内での個人のロールと職責に基づいて、アクセス権を決定します。

ロールを定義するプロセスは通常、組織の基本的な目的と構造に関する分析に基づいて行われ、セキュリティポリシーに関連付けられます。例えば医療組織の場合、医師、看護師、付添い人、患者など、さまざまなユーザーロールがあります。当然のことながら、これらのメンバーには、それぞれの職務を遂行するために異なるレベルのアクセス権が必要になります。さらに、Web トランザクションの種類と、それらを許容するコンテキストは、セキュリティポリシーと関連法規 (HIPAA やグラム・リーチ・ブライリー法など) によっても大きく異なります。

ロールベースアクセス制御フレームワークでは、どのようなアクションを、誰が、いつ、どこから、どの順序で実行できるようにするか、また、場合によってはどのような条件下で実行できるようにするかを Web アプリケーションのセキュリティ管理者が決定できるようにする必要があります。

この方式を使用する利点は、次のとおりです。

  • ロールは、組織のセキュリティポリシーを重視しながら組織の構造に基づいて割り当てられます。
  • 簡単に使用できます。
  • 簡単に管理できます。
  • ほとんどすべてのフレームワークに組み込めます。
  • 権限分離や最小特権などのようなセキュリティの原則に従う形で使用できます。

この方式を使用したときに発生する可能性のある問題点は次のとおりです。

  • ロールとアクセスについての文書を厳格に維持する必要があります。
  • マルチテナント環境では、マルチテナント機能の要件 (Active Directory における OU など) にロールを関連付ける方法がないと効果的に実装できません。
  • スコープクリープ、すなわち、意図した以上のアクセス権や特権を付与してしまう傾向があります。また、アクセス権割り当て状況のレビューと不要な権限の取り消しを適切に実行しないと、ユーザーが 2 つのロールに含まれることがあります。
  • データに基づいたアクセス制御はサポートされません。

ロールベースアクセス制御を行う際には、次のような点に注意します。

  • ロールの移転や委譲は、厳格な承認と手続きを使用してのみ行われる必要があります。
  • ユーザーがロールを変更する場合、管理者は、以前のアクセス権の取り消しを確実に実行し、いかなる時点においても必要なロールのみがユーザーに割り当てられているようにする必要があります。
  • 厳格なアクセス制御のレビューによって、ロールベースアクセス制御が適切に行われていることを保証する必要があります。

OWASP には、ロールベースアクセス制御の実装プロジェクト OWASP RBAC プロジェクトがあります。

任意アクセス制御 (DAC)

任意アクセス制御 (DAC) とは、ユーザーの識別情報や特定のグループに所属しているかどうかといった情報に基づいて、アクセス権限を制御する方法のことです。アクセス権は通常、ユーザー認証時に提示された識別情報 (ユーザー名、パスワード、ハードウェア/ソフトウェアトークンなど) に基づいて与えられる認可により決定されます。最も一般的な DAC モデルでは、情報またはリソースの所有者が権限を変更できます (任意アクセス制御という名前はここからきています)。

任意アクセス制御 では、Web アプリケーションのセキュリティ管理者が、きめ細かいアクセス制御を実装できます。このモデルを基準にして、データに基づくアクセス制御を実装できます。

このモデルの使用による利点は、次のとおりです。

  • 簡単に使用できます。
  • 簡単に管理できます。
  • 最小特権という原則に従う形で使用できます。
  • オブジェクトの所有者が、アクセス権の付与について完全な制御を持ちます。

この方式を使用したときに発生する可能性のある問題点は次のとおりです。

  • ロールとアクセスについての文書を厳格に維持する必要があります。
  • トロイの木馬による攻撃には脆弱です。
  • マルチテナントは、マルチテナント機能の要件 (Active Directory における OU など) にロールを関連付ける方法がない場合には効果的に実装できません。
  • スコープクリーク、すなわち、意図した以上のアクセス権や特権を付与してしまう傾向があります。

任意アクセス制御を行う際には 、次のような点に注意します。

  • 信頼の付与
  • 厳格なアクセス制御のレビューによって、任意アクセス制御が適切に行われていることを保証する必要があります。

強制アクセス制御 (MAC)

強制アクセス制御 (MAC) により、Web アプリケーションのユーザーによる自発的なコンプライアンスに頼らずに、企業のセキュリティポリシーの適用を強制できるようになります。強制アクセス制御では、情報に機密性ラベルを割り当てて、このラベルと、ユーザー操作の機密性レベルとを比較することで、情報を保護します。通常、強制アクセス制御は、多重保護の軍用アプリケーションやミッションクリティカルなデータアプリケーションなど、極めてセキュアなシステムに適しています。

この方式を使用する利点は、次のとおりです。

  • オブジェクトに対するアクセス制御は、オブジェクトの機密性に基づいて行います。
  • アクセス許可を最小限におさえることができ、スコープクリープの可能性は最小限になります。
  • 管理者のみがアクセス権を付与できます。

この方式を使用したときに発生する可能性のある問題点は次のとおりです。

  • 実装が困難であり実装コストが (他の方式と比較して) 高くなる
  • 迅速な対応が難しい

強制アクセス制御を行う際には、次のような点に注意します。

  • 適切で実用的なレベルでの分類と機密性の割り当て

適切なレベルでオブジェクトを分類することで、強制アクセス制御が適切に行われていることを保証する必要があります。

属性ベースアクセス制御 (ABAC)

NIST Special Publication (SP) 800-162 (Final)

  • 権限昇格
  • 機密データの開示 - 管理者レベルのアカウントへのセキュリティ侵害は、多くの場合、ユーザーの機密データへのアクセスにつながります。
  • データ改ざん - 特権レベルでは、データの閲覧のみが可能なユーザーと、データの変更を許可されたユーザーが区別されません。

アクセス制御に対する攻撃としては、次のようなものがあります。

垂直的なアクセス制御攻撃:

  • 低い権限のサブジェクトが、より高い権限を持つサブジェクト向けのオブジェクトにアクセスします。

以下に、垂直的なアクセス制御攻撃の例を示します。

1. Web アプリケーション向けのサービスがローカルユーザー権限で実行されている場合、攻撃者は脆弱性を攻略して(たとえば、バッファオーバーフロー)、サービスの実行権限をローカル管理者に昇格します。

2. ユーザー入力の不適切な検証により、攻撃者はクロスサイトスクリプティングを使用して、Web アプリケーションの管理者権限を取得できます。

3. ジェイルブレイクされたデバイスにより、ユーザーはモバイルデバイスに対する高いアクセス権を獲得できます。悪意のあるプログラムは、特権昇格してデバイス内のコンタクト情報を収集できます。

4. コアダンプファイルを制御することで、攻撃者は特権を取得して任意のプログラムを実行できます。

5. Web アプリケーションが常に管理者 ID を使ってデータベースにアクセスしている場合、攻撃者は Web アプリケーション経由でデータベースの管理者アクセス権を取得します。

水平的なアクセス制御攻撃:

  • サブジェクトが、同じ権限を持つオブジェクトや別のサブジェクト向けのオブジェクトにアクセスします。

次に、水平的なアクセス制御攻撃の例を示します。

1. 銀行取引アプリケーションのユーザーが、セッション ID を予測してログインし、送金処理を実行します。

2. ユーザーは、パスワードを推測してショッピングアプリケーションにログインし、実際のユーザーが知らないうちに購入物を自分の住所に送付させます。

3. 従業員がワークステーションにログインしたままロックしていない間に、そのワークステーションを使って別の従業員がイントラネットポータルにログインし、給与明細にアクセスします。

ビジネスロジックのアクセス制御攻撃 – 複数のアクティビティが連携して動作するアプリケーションに対し、1 つ以上のアクティビティを不正使用する


  • 多くのアプリケーションが「オールオアナッシング」方式を使用している – どのユーザーも認証されたらすべて同じ特権を持つ
  • 認可ロジックが、以下を前提にした隠蔽によるセキュリティ (STO、Security Through Obscurity) に依存している。
    • ユーザーは、リンクされていない (または表示されていない) パスや機能を見つけることはない
    • ユーザーは、「隠蔽された」クライアント側のパラメーター (Cookie や入力フォームの hidden フィールドなど) を見つけて悪用することはない
  • 複数の特権レベルやロールを扱うアプリケーションでは、アクセス許可の不整合が起きて想定外の特権付与をもたらす可能性があります。
  • 多くの管理インターフェイスでは、認証の際にパスワードしか求められません。
  • 共有アカウントで監査およびロギングが適切に行われていない場合、悪意のある管理者と誠実な管理者の区別が極端に難しくなります。
  • 管理インターフェイスは、多くの場合、管理者は信頼できるユーザーであると仮定して設計されており、一般ユーザー向けのインターフェイスほど「セキュア」な設計はなされていません。
  • 認可やアクセス制御が、クライアント側の情報 (非表示フィールドなど) に依存している。
  • Web サーバーやアプリケーションサーバーのプロセスが 、root、Administrator、LOCALSYSTEM などのような特権アカウントで実行されている。
  • Web アプリケーションが sa のようなシステム管理用アカウント (または必要以上の権限を持ったアカウント) でデータベースにアクセスしている。
  • 各ページにファイルや Web コントロールの読み込み、またはコードスニペットを直接埋め込むことで認可の制御を実装している。 
    <input type="text" name="fname" value="Derek">
    <input type="text" name="lname" value="Jeter">
    <input type="hidden" name="usertype" value="admin">
  • 特権レベルを考慮してロールを設計していない。例えば、アプリケーションの「読み取り専用」ロールが、読み書き両方の権限を持った状態でデータベースにアクセスする、など。この問題の対策としては、(ユーザーやロールとその権限をまとめた) アクセス制御マトリックスの設計が役立つ。
  • 入力データのサニタイズや検証を行っていない。
  • 信頼されていないデータを認可に使用している。

  • アプリケーションコードにハードコードされたロールをチェックしている
  • 一元化されたアクセス制御ロジックの欠如
  • 信頼されていないデータに基づいてアクセス制御
  • 「デフォルトでオープン」のアクセス制御
  • 水平的なアクセス制御対策の欠如 (標準化された方法があったとしても行っていない)
  • コード内のエンドポイントごとに手動で追加する必要のあるアクセス制御ロジック
  • 非匿名のエントリポイントでアクセス制御を行っていない
  • 機密性の高いアクティビティを実装するコードの開始点または開始点付近で認可処理を行っていない
  • 多要素認証の追加により権限昇格の問題に対応できる

ハードコードされたロール

 if (user.isManager() ||
     user.isAdministrator() ||
     user.isEditor() ||
     user.isUser()) {
     //アクションの実行
 }

ハードコードされたロールにより、次のような問題が発生する可能性があります。

  • アプリケーションのポリシーが監査や Q/A の目的に「役立て」にくくなる
  • アクセス制御ポリシーへの変更が必要になるたびに、新しいコードをプッシュすることになる
  • 脆弱であり、間違いが起きやすい

オーダー固有の操作

次に示すパラメーターがあるとします。 

 http://example.com/buy?action=chooseDataPackage
 http://example.com/buy?action=customizePackage
 http://example.com/buy?action=makePayment
 http://example.com/buy?action=downloadData

攻撃者は順序を制御できるでしょうか。

攻撃者は同時実行によって、これを悪用できるでしょうか。

信頼されていないデータに依存しないこと

  • アクセス制御の判断を行う際にユーザーデータを信頼してはいけません。
  • JavaScript でアクセス制御の決定を行ってはいけません。
  • クライアントから送信される値の順序に依存してはいけません。
  • 次に示す事項のみで認可の判断を行ってはいけません。
    • hidden フィールド
    • Cookie の値
    • 入力フォームのパラメーター
    • URL のパラメーター
    • その他リクエストから得られるあらゆる情報


  • 匿名ユーザーまたは通常ユーザーとして、管理コンポーネントや管理機能へのアクセスを試行します。
    • 「関心をひく」非表示フォームフィールドについて、HTML ソースを調査します。
    • admin、administrator、manager のような名前について Web アクセス可能なディレクトリ構造をテストします (つまり、「制限された」領域の直接的な参照を試します)。
  • 管理者がどのように認証されたかを調べます。適切な認証が使用され強制されていることを確認します。
  • ユーザーロールごとに、そのロールにとって適切なページまたはコンポーネントにのみアクセス可能なことを確認します。
  • 低い権限のユーザーとしてログインし、より高い権限のユーザーのアクセスをたどってページにアクセスし、元の認可情報が前のセッションに渡されないか確認する。
  • 管理者レベルのアカウントを侵害できる場合は、その他すべての一般的な Web アプリケーションの脆弱性についてテストします (不十分な入力検証や特権でのデータベースアクセスなど)。

  • 垂直的なアクセス制御要件として、アプリケーションユーザーに権限を割り当てる場合は、ロールベースアクセス制御を実装します。
  • 水平的なアクセス制御要件、特定のデータ項目に関するコンテキストでアプリケーションユーザーに権限を割り当てる場合は、データコンテキストに応じたアクセス制御を実装します。
  • ユーザー単位で権限を割り当てることを避けます。
  • アプリケーションが提供するすべてのページで、一貫性のある認可処理を実行します。
  • 該当する場合は、特権の拒否を最後に適用し、状況に応じて特権の許可を発行します。
  • 可能な場合は、ローカルエリアネットワークに配置されたマシンへの管理者アクセスを制限します (つまり、公衆ネットワークのアクセスポイントからの管理者アクセスを避けることが最良策です)。
  • すべての失敗したアクセス認可リクエストは、管理者によるレビューのために保護された場所に記録します。
  • 失敗したログインの試行については、定期的にレビューを実行します。
  • 選択した SSO ソリューションに備わった長所と機能を活用します。
  • ユーザーインターフェイスとデータアクセスインターフェイスのアクセス制御マトリックスを作成し、アクセス制御のレビューを実行します。
  • 職務分離が実現されている (リクエスト側が自分では認可を実行できない) ことをアクセス制御マトリックスで確認します。


Java 


if ( authenticated ) {

	request.getSession(true).setValue(“AUTHLEVEL”) = X_USER;

}

.NET (C#) 


if ( authenticated ) {

	Session[“AUTHLEVEL”] = X_USER;

}


PHP 


if ( authenticated ) {

	$_SESSION[‘authlevel’] = X_USER; 	// X_USER は、認可されていることを表すものとして、別の場所で定義されている

}

ベストプラクティス: Code to the Activity

  if (AC.hasAccess(ARTICLE_EDIT)) {
      //アクティビティの実行 
  }
  • コードを 1 回記述したら、再変更の必要をなくします。
  • 何らかの方法でポリシーが永続化および一元化されていることを暗示します。
  • ユーザー単位で権限を割り当てることを避けます。
  • 適切なものにするには、さらに設計と作業が必要になります。

ベストプラクティス: 一元化された ACL コントローラー

  • 一元化されたアクセスコントローラーを定義します。 
     ACLService.isAuthorized(ACTION_CONSTANT)
     ACLService.assertAuthorized(ACTION_CONSTANT)
  • このような簡単な API を通じてアクセス制御を決定します。
  • ポリシーの動作と永続性を推進するロジックの一元化
  • データに応じたアクセス制御ポリシー情報を含めることができます。
  • ポリシー言語は、アクセス許可と禁止の両方を表現する能力をサポートしている必要があります。

ベストプラクティス: 一元化されたアクセスコントローラーの使用

  • プレゼンテーション層では、次のようにします。 
      if (isAuthorized(VIEW_LOG_PANEL))
      {
         ここにログを示します
         <%=getLogs();%/>
      }
  • コントローラーでは、次のようにします。 
      try (assertAuthorized(DELETE_USER))
      {
         deleteUser();
      }

ベストプラクティス: サーバー側のポリシーの検証

  • セッションでは、常にユーザー識別情報を検証します。
  • 信頼されたソースからサーバー側にエンタイトルメントをロードします。
  • すべてのリクエストに対して認可の処理を強制します。
    • JS ファイル、イメージ、AJAX および FLASH のリクエストも同様にします。
    • 可能であれば、フィルターを使用してこのチェックを強制します。

ベストプラクティス: 最小権限

アクティビティの実行に必要なレベルの特権のみを割り当てます。

次に例を示します。

1. 銀行取引アプリケーションで、ユーザーが口座明細を読み込むためのアクセスを行う場合は、「読み取り専用」権限を持つアプリケーション ID を設計します。このユーザー ID に資金移動や口座明細変更を行う権限を割り当ててはいけません。

2. 「読み取り専用」のアプリケーション ID を「読み取り専用」のデータベース ID にマップします。「管理」用のデータベース ID に対応させてはいけません。

3. ユーザーが 1 つの口座へのアクセスだけを必要としている場合は、それ以上の権限を与える可能性のあるアクセスをサブネストしてはいけません。

ベストプラクティス: 職務の分離

アクセス制御の設計時には、アクセスリクエストを行う者とリクエストに対して認可処理を行う者を分離してください。 つまり、ユーザーが特定のリソースへのアクセスを要求した場合、ユーザー自身がこのリクエストを認可できないようにします。

ベストプラクティス: アクセス制御のレビュー

ユーザーに割り当てた権限を定期的にレビューします。次の項目に関連するアクセスをレビューします。

1. Web アプリケーションで、現在リストされているユーザー / ユーザー ID / アプリケーション ID / データベース ID / その他の ID をアクティブにしておく必要があるかどうか。

2. リストされたアクティブなユーザー / ユーザー ID / アプリケーション ID / データベース ID / その他の ID が適切な程度の権限を持っているかどうか。

3. Web アプリケーションを構成するすべてのコンポーネントがアクセスについてレビューされているかどうか。たとえば、Web アプリケーションに割り当てられた DBA が組織外に移動したら、その DBA のデータベースへのアクセス権は取り消されていますか。 注目すべき典型的なコンポーネントは、データベース、キーストア、Web サービス、アプリケーションサーバー、ファイアウォール、その他、ユーザーを "内部" 資産に誘導する可能性のあるアプリケーションです。

4. すべての非アクティブなユーザー / ユーザー ID / アプリケーション ID / データベース ID / その他の ID が取り消されているかどうか。

ベストプラクティス: アクセスの監視

Web アプリケーションでは、次に示すアクティビティについてのログと監視が必要です。

次のような項目についてログを取るとよいでしょう。

1. ユーザーの作成

2. ユーザーの削除

3. ユーザーへの管理者権限の付与

4. 権限の変更

5. 管理者アカウントや特権アカウントによる、作成、変更、削除および実行イベント

6. 無効な論理アクセスの試行

7. セキュリティログへのユーザーアクセス

8. システムレベルアカウントの作成、変更および削除

ログには、次のような項目を含めるべきです。

1. ユーザーや管理者/特権ユーザーを一意に識別する情報

2. イベントの種類 (ログイン、読み取り、作成、変更、削除、実行など)

3. 日付とタイムスタンプ

4. アクションの成功または失敗

5. 拒否の理由 (もしあれば)

ベストプラクティス: アクセス管理

管理対象とするオブジェクト (アプリケーション、開発環境、データベース、API、サーバー、ネットワークコンポーネントなど) について、次の手順でプロセスを維持します。

1. ユーザーアクセスのリクエスト

2. ユーザーアクセスの認可

3. ユーザーアクセスの実装

4. ユーザーアクセス資格情報の配布

5. ユーザーアクセスのレビュー

6. ユーザーアクセスの取り消し

7. 解雇した従業員 / 請負業者 / サードパーティ納入業者のユーザーアクセスの取り消し

機能の例 

   http://mail.example.com/viewMessage?msgid=2356342

この SQL には、改ざんに対する脆弱性があります。 

 select * from messages where messageid = 2356342

クエリでは、必ず所有者も参照するようにします。 

 select * from messages where messageid = 2356342 AND messages.message_owner =

  • ロールではなく、アクティビティに対するコードを記述する
  • アクセス制御ロジックを一元化する
  • アクセス制御をフィルターとして設計する
  • デフォルトは拒否とする、エラー時の動作はセキュアな方向に倒す
  • 一元化したアクセス制御メカニズムを構築する
  • プレゼンテーション層のアクセス制御およびサーバー側のアクセス制御は同一のコアロジックによる処理を行う
  • アクセス制御はサーバー側にある信頼できるデータにもとづいて行う

データコンテキスト / 水平的なアクセス制御 API の例 

   ACLService.isAuthorized(EDIT_ORG, 142)
   ACLService.assertAuthorized(VIEW_ORG, 900)

長い形式 

   isAuthorized(user, EDIT_ORG, Organization.class, 14)
  • 基本的には、特定のオブジェクトを扱う状況でユーザーが適切なロールを持つかどうかをチェックする
  • アクセス制御ロジックを一元化する
  • 最も低いレベルでデータを保護する

Shruti Kulkarni - shruti.kulkarni [at] owasp.org
Mennouchi Islam Azeddine - azeddine.mennouchi [at] owasp.org
Jim Manico - jim [at] owasp.org

Other Cheatsheets

OWASP Cheat Sheets Project Homepage

Developer Cheat Sheets (Builder)

Assessment Cheat Sheets (Breaker)

Mobile Cheat Sheets

OpSec Cheat Sheets (Defender)

Draft Cheat Sheets

Retrieved from "https://www.owasp.org/index.php?title=Access_Control_Cheat_Sheet&oldid=204799"