Estas son buenas prácticas que están extraídas de http://www.asp.net/aspnet/overview/web-development-best-practices/what-not-to-do-in-aspnet,-and-what-to-do-instead y encontré interesante traducirlas. Quizás alguien podría decir “lo primero que debes hacer con ASP.NET es no programar con WebForms”, y puede tener razón a esta altura del partido, pero si ya tienes apps con WebForms y te es imposible migrarlas, (por esfuerzo, tiempo, etc), entonces sería bueno que hicieras un checklist de lo siguiente:
Control Adapters
Recomendación: Deja de utilizar control adapters para el render adaptativo y comienza a usar CSS media queries y código estándar HTML. Los control adapters aparecieron en NET 2.9 para hacer render para diferentes dispositivos y entornos. Ahora, este render adaptativo puede ser construido con CSS y HTML. Asi que, deja de usarlos 
Para mayor información, revisa info de Media Queries y How To: Add Mobile Pages to Your ASP.NET Web Forms / MVC Application.
Estilos en los Controles
Recomendación: Ya no más!, no debemos setear los estilos en el markup del control, por el contrario, se deben asignar los estilos en sus correspondientes CSS.
Si bien los webcontrols contienen ciertas propiedades que pueden ser usadas para setear estilos “in-line” , por ejemplo , la propiedad Forecolor, que setea el color del texto de un control, podemos lograr este mismo efecto de manera mucho más efectiva a través de las hojas de estilo, las cuales permiten centralizar los valores de los estilos y evitamos el “desorden” de asignar todo in-line.
Control Callbacks
Recomendación: Dejar de utilizar los control callbacks, y en lugar utilizar Ajax, UpdatePanel (peligro!) métodos de acción MVC , Web API o SignalR.
En versiones anteriores de ASP.NET esta característica permitía actualizar parte de la pagina web sin actualizar la pagina completa. Ahora esto lo podemos realizar con AJAX, UpdatePanels, MVC, Web API,m SignalR.
Browser Capability Detection
Recomendación: Dejar de usarlo, en su lugar utilizar la detección de características dinámicas.
En versiones anteriores de ASP.NEt, las características compatibles para cada navegador se almacenaban en un archivo XML. La detección de soporte de las funciones a través de una consulta estática no es el mejor enfoque. Ahora podemos detectar dinámicamente las funciones compatibles de un navegador utilizando librerías como Modernizr
Seguridad – Request Validation
Recomendación: Validar las entradas de usuario, y codificar la salida hacia los clientes.
El Request Validation es una característica de ASP.NET que inspecciona cada request ya que detiene este request si encuentra una amenaza. Pero no descansar toda la seguridad de los datos que van hacia el servidor con esta característica. Se debe validar todas las entradas, y en casos más riesgosos en terminos de seguridad, utilizar expresiones regulares, ocupar librerías anti-xss, etc.
Formularios sin cookies de autenticación y sesiones
Recomendación: Requerir cookies.
El paso de información de autenticación en la cadena de consulta no es para nada seguro, por lo tanto , se requieren coockes cuando la aplicación requiera autenticación. Si nuestra cokkie almacna informaci{on sensible, hay que considerar requerir SSL para la cookie.
El siguiente ejemplo muestra como especicificar en un archivo Web.config que la autenticación de formularios reuqiere una cookie a traves de SSL
<authentication mode="Forms">
<Formas loginUrl = "member_login.aspx"
sin cookies = "UseCookies"
requireSSL = "true"
path = "/ MyApplication" />
</ Authentication>
EnableViewStateMac
Recomendación: Nunca , pero re-nunca setearlo en False
Por defecto, EnableViewStateMac se establece en true. Incluso si nuestra aplicación no ocupa viewstate, nunca establezcamos este parámetro en false, ya que hará que nuestra app sea vulnerable a cross-site scripting. Si ya la has seteado en false, corre a cambiarlo
Medium Trust
Recomendación: No depender de la confianza media (o cualquier otro nivel de confianza) como límite de seguridad.
La confianza parcial no protege adecuadamente la solicitud y no debe ocuparse, debemos ocupar Full Trust, y aislar las aplicaciones no confiables en app pools distintos. También ejecutar cada app pool bajo una identidad única, para más información de esto podemos visitar ASP.NET Partial Trust does not guarantee application isolation.
<appSettings>
Recomendación: No desactivar la configuración de asegurar en elemento <appSetings>.
El elmento appSetting contiene muchos valores que son necesarios para las actualizaciones de seguridad, no hay que cambiar estos valores. Si tenemos que desactivar estos valores al implementar una actualización, debemos volver a dejarlos como estaban inmediatamente.Revisa más información acá ASP.NET appSettings Element.
UrlPathEncode
Recomendación: utilizar UrlEncode
El método UrlPathEncode se incluyó en el Net framework para resolver un prob lema muy especifico de compatibilidad con ciertos navegadores. Este método no codificia adecuadamente la URL y no protege el request de XSS, así que no lo ocupemos, en su lugar utilicemos UrlEncode.
Ejemplo:
string destinationURL = "http://www.contoso.com/default.aspx?user=test";
NextPage.NavigateUrl = "~/Finish?url=" + Server.UrlEncode(destinationURL);
PreSendRequestHeaders y PreSendRequestContext
Recomendación: No utilizar estos eventos con módulos gestionados.
Podemos utilizar los eventos PreSendRequestHeaders y PreSendRequestContext con módulos de IIS nativas, pero no los usemos con módulos gestionados que implementan IHttpModule. La configuración de estas propiedades puede causar problemas con las peticiones asíncronas.
Páginas con eventos asíncronos en WebForms
Recomendación: en los webforms, evitar escribir métodos void asíncronos para los eventos del ciclo de vida de la pagina, y en su lugar utilizar Page.RegisterAsyncTask.
El problema es que cuando no tenemos retorno para un método async no se puede determinar cuando el código asíncrono ha terminado.
Si estamos utilizando tareas asíncronas, setear el framework a 4.5 en el archivo Web.config. NET 4.5 introdujo un nuevo contexto de sincronización, este valor esta seteado por default en los nuevos proyectos, pero si estamos en un proyecto existente, obviamente no.
<system.web>
<httpRuntime TargetFramework="4.5" />
</system.web>
Response.Redirect y Response.End
Recomendación: Tener en cuenta las diferencia en como es manejado el Thread una vez llamado el Responde.redirect(string).
Este método llamada al método Response.End, en un proceso sincrónico, el llamado a Resquest.Redirect hace que el subproceso actual se aborte de inmediato. Sin embargo, en un proceso síncrono el llamada a redirect no aborta el subproceso actual, por lo que la ejecución de código continua. En un proceso asíncrono, deberá devolver la tarea desde el método para detener la ejecución del código. En un proyecto MCV, no hay que llamar a un Response.Redirect, para eso tenemos RedirectResult.
EnableViewState y ViewStateMode
Recomendación: utilizar ViewStateMode en lugar de EnableViewState, que permite un control más detallado sobre el control del ViewState.
Cuando se establece EnableViewState en false en la directiva Page, el viewState queda deshabilitado para todas los controles dentro de la pagina y no se pueden activar individualmente. Si queremos habilitar el ViewState solo para ciertos controles , podemos configurar el viewStateMode para el control en el que necesitemos esta característica.
A nivel de página:
<% @ Page ViewStateMode = «Disabled». . . %>
y en el control específico:
<asp:GridView ViewStateMode=»Enabled» runat=»server»>
con esto podemos reducir considerablemente el tamaño del viewstate.
Espero que te sirva!!
Saludos!!!
@chalalo
, excelente!! 
al parar el sitio1 
.
.
