私はlaravel webappを持っています。ログイン中だけでなく、特定のアクションを実行したり、あらゆるステップで特定の情報にアクセスできるかどうかを確認します。たとえば、自分の資産を表示したいときにUACをチェックし、そのボタンをクリックした後、編集、削除ボタンが表示されていなくても、コードにチェックが残っています。そして、このパターンはwebapp全体にわたって続きます。これは過剰なのでしょうか？私のウェブアプリケーションは、あちこちの小切手でうっとりしてしまいますか？特定のプロセスのすべてのステップでユーザーアクセスレベルを確認することをお勧めしますか？
はい、そうです。 特権アクションを実行する前にアクセスをチェックするたびに、侵入者が以前のチェックをバイパスし、実際にアクセスしなくても何らかの形でそのアクションを引き起こす可能性があります。いくつかの余分な小切手は、堅牢性と安心のために支払う小額の価格です。特に
は、あなたは常にyou should never trust user input以来、クライアントによって行われたそれぞれの新しい要求のため、サーバー上の権限チェックの再、およびすべてクライアントがサーバに送信するので、ユーザの管理下に潜在的にあるべきです。たとえば、クライアントインターフェースの「編集」ボタンや「削除」ボタンを無効にしても、悪意のあるユーザー（または好奇心を惹くユーザー）がユーザーを再び有効にするのを止めることは何ですか。ブラウザのデベロッパーツールを使用して、またはボタンがトリガーする実際の編集/削除要求を単に偽装することによって、
あなたが運が良ければ、サーバー側の権限チェックが行なわれていなくても、一部のユーザーには許可されます。see a bunch of deleted garbage.運がよければ、あなたのサイトに完全な管理アクセス権が与えられるかもしれません。
これ以上自分自身では答えられませんでした！非常に良い答え！リモートで追加できるのは、これをミドルウェアとして設定することだけです。 – Option
これは実際には良い練習であり、ミドルウェアはこの目標をより簡単に達成するのに役立ちます。
最後に、これは解決できない「依存する」質問の1つです。ただし、通常、リレーショナルデータベースを使用してユーザーIDを検索することで、_implicit_アクセスチェックが行われることに注意してください。 「SELECT .... WHERE USER = 123」タイプのクエリでは、ユーザは自分に属していないものを決して見ることができません。一方で、例えば、 「削除」ボタンがないにもかかわらず、悪意のあるユーザーが（たとえランダムなリソースIDであっても）削除コマンドを送信してしまうことはありません。 – Damon