Desde el lanzamiento de .NET y su aplicación al desarrollo de aplicaciones Web (ASP.NET), uno de los principios esenciales es el desarrollar código seguro, pues qué puede significar eso?
No solamente es evitar inyecciones al código de tipo SQL, sino tambien implementar una serie de políticas que eviten el mal uso de este código, y sobre todo hacer que nuestras aplicaciones no se "caigan" de forma catastrófica (léase la típica pantalla de error de .NET) frente al usuario.
Dentro de nuestra organización hemos tratado e imprimir una serie de reglas en el desarrollo de nuestras aplicaciones de las cuales enumero algunas:
- Nunca confíes en el input del usuario:
Una de las causas más comunes de errores no controlados, el asumir que el usuario ubicará datos congruentes en cualquiera de los mecanismos de ingreso de información. De manera que todo "absolutamente todo" es validado a todo nivel, desde las formas ASP.NET hasta la capa de datos.
- Nunca permitas que la interfaz de usuario "se caiga":
El usuario no debería perder la interacción con la aplicación. Si se llegase a generar una excepción, no debería ser el fin del mundo!, de esta manera tratamos de informarle al usuario: Qué paso? Qué tipo de excepción es?, Por qué pudo haberse generado el error? y Qué puede hacer para remediarlo?: Si es un error de input que ubique los valores adecuados o si es un error no manejable por el usuario a quién tiene que contactar para resolverlo.
- Capturar la mayor cantidad de excepciones posibles y registrarlas:
El poder analizar los métodos dentro de los componentes, datos o presentación clasificando excepciones podría resultar una tarea ardua, pero enriquecedora en cuanto a resultados, mucho más si registramos las excepciones generadas, nos ha ayudado muchísimo a resolver problemas insospechados de forma relativamente rápida y efectiva. Aquí incluyo la clasificación de excepciones: comenzamos entre las "Excepciones Catastróficas" y el "Resto", para priorizar... lógicamente esta división se amplió a categorización por módulo, importancia, frecuencia, etc.
- Verificación de nulidad de objectos:
Asumir que el objeto (sea control, instancia de clase, etc) podría ser nulo ("null") en cualquier momento. Esta estrategia te libera de muchos problemas derivados de la omisión.
- Implementar mecanismos de reporte de Bugs:
Una vez que la aplicación está en producción, al usuario detectar un bug o excepción, tiene la posibilidad de reportarlo mediante mecanismos de comunicación con nuestro departamento de soporte. Esencial en aplicaciones de alto desempeño. Seamos razonables, la aplicación libre de bugs no existe, por lo tanto lo mejor es tratar de manejarlos, reportarlos e incluirlos dentro del flujo de soporte. Muy buenos resultados, sobre todo hacia la imagen que damos al usuario.
Son algunas cosas, pocas, las que he mencionado, pero que ayudan realmente en construir código realmente seguro y sobre todo enfocado hacia el soporte al usuario asegurando un ciclo de vida lo más correcto posible de la aplicación.
Espero seguir escribiendo sobre esto en algún post más... saludos.
Actualmente calificado con 4.5 por 2 personas
- Currently 4,5/5 Stars.
- 1
- 2
- 3
- 4
- 5