開発にはasp.netmvcを使用しています。場合によっては、modelbinderによってモデルに押し込まれるいくつかの非表示フィールドをフォームに配置する必要があります（予想どおり）。現在、ユーザーはFirebugやその他のユーティリティを使用してフォームを簡単に調整できます。非表示フィールドの目的は、主にサーバーに情報をそのまま提供することであり、変更することを意図したものではありません。
たとえば、従業員の編集フォームでは、EmployeeIDを非表示フィールドに配置できますが、ユーザーが非表示フィールドのemployeeIDを変更すると、データベースで間違った従業員が更新されます。このシナリオでは、非表示フィールドの整合性をどのように維持できますか。
変更を行う人がそうする許可を持っていることを保証するために、セキュリティを実施する必要があります。また、通常は非表示フィールドではなくURLにIDを配置し、セキュリティに依存して、ユーザーが変更できないはずの内容を変更しないようにします。IDを手動で変更するときにアイテムを変更する権限がある場合は、問題はありません。重要なことは、IDを手動で変更したり、変更してはいけないものにアクセスしたりできないようにすることです。サーバー側のアクセス許可を適用すると、この問題が解決します。これは、AuthorizeAttributeと組み合わせてRolesを使用して簡単に行うことができます。
ユーザーが非表示フィールドでemployeeIDを変更すると、データベースで間違った従業員が更新されます
これはあなたのウェブサイトの主要なセキュリティホールです。Web開発で行うすべてのことにおいて、誰かのコードがどれほど巧妙であっても、ユーザーが何かをしなければ大丈夫だと思うとしても、クライアントから受け取ったデータを暗黙的に信頼しないという1つの黄金のルールを覚えておいてください。
Webサイトの内容を変更するには、ユーザーがログインしている必要があります。（そうですか？）したがって、ユーザーがWebサイト（特にデータを変更できるフォーム）にフォームを投稿しようとする場合は、送信するユーザーを再確認してください。フォームには、指定されているデータに対して要求されているアクションを実行する権限があります。
理想的には、完全に公開されておらず、セキュリティで保護されていないすべてのアクションには、サーバー側のアクセス許可チェックが必要です。決して、クライアントがあなたに送ったものを決して信用しないでください。
考えられる代替案の1つは、その静的な使い捨て情報をサーバー上のTempDataに保存し、改ざんされる可能性のあるクライアントに渡さないことです。デフォルトでは、TempDataはSessionを使用し、独自の制限があることに注意してください。ただし、これはオプションである可能性があります。