ASP.NET Web Forms event validation disabled¶
What does this mean?¶
ASP.NET Framework Web Forms event validation checks whether a postback or callback event is consistent with events and arguments registered by the rendered control. For example, a submitted list choice that the control never offered can be rejected. Microsoft documents this behavior in Page.EnableEventValidation.
This is different from ASP.NET request validation, which historically checks certain request values for potentially dangerous content. It is also different from output encoding, CSRF protection and application authorization. Changing enableEventValidation does not turn all of those controls on or off.
Recommendation¶
Keep event validation enabled. If a dynamic control causes validation failures, investigate how and when its controls and permitted events are created or registered. Do not disable the feature across the application just to suppress an exception. Where client-side code deliberately changes available events, use the framework's documented event-registration mechanism for the intended values.
Sample configuration¶
These are alternative system.web sections inside a Web Forms application's Web.config. Merge the intended attribute into the existing configuration rather than adding a second section.
Unsafe configuration choice: disable the framework check.
<system.web>
<pages enableEventValidation="false" />
</system.web>
Safer: retain event validation.
<system.web>
<pages enableEventValidation="true" />
</system.web>
Review page-level directives and dynamic-control code as well as the global setting. Correct registration should describe permitted events; it should not blindly register every submitted value and therefore approve whatever the caller supplied.
Check the fix¶
In a disposable Web Forms page, render a list with two fictional values. Confirm each valid selection succeeds. Submit a third unregistered value and verify the application rejects it through controlled error handling. Then test legitimate dynamic controls and callbacks so the fix does not break intended behavior.
The server must still authorize the resulting operation. A previously rendered choice can become invalid when ownership, tenant membership or workflow state changes.
ASP.NET Core distinction¶
ASP.NET Core MVC and Razor Pages do not use this Web Forms setting. Apply model validation, server-side authorization, output encoding and the appropriate antiforgery protection for those applications.
See ViewState integrity, CSRF and HTML injection. The configuration is a review signal, not proof of a particular exploit.