Если для сохранения или совместного использования данные состояния должны передаваться через границы процессов и сетей, обеспечьте их сериализуемость.

Правильно выбирайте хранилище состояния. Хранение состояния в процессе или в памяти обеспечит наилучшую производительность, но эта техника может использоваться, только если состояние не должно сохраняться между повторными запусками процесса или системы. Если хотите, чтобы данные состояния были доступны после перезапуска процесса или системы, сохраняйте их на локальном диске или локальном SQL Server. Если состояние является критически важным аспектом приложения, или если данные состояния должны использоваться совместно несколькими компьютерами, храните состояние централизованно, например, на выделенном SQL Server.

Валидация

Проектирование эффективного механизма валидации имеет большое значение с точки зрения обеспечения удобства и простоты использования и надежности приложения, в противном случае, оно может остаться открытым для несогласованности данных и нарушений бизнесправил, а также обеспечивать неудовлетворительный уровень взаимодействия с пользователем. Кроме того, приложение может оказаться уязвимым к таким угрозам безопасности, как межсайтовые атаки внедрением сценариев, атаки типа внедрение SQL-кода, переполнение буфера и другие атаки посредством входных данных. Четкого и исчерпывающего определения действительного или злонамеренного ввода нет. Возможные риски, обуславливаемые злонамеренным вводом, зависят также от того, как приложение использует ввод. При проектировании стратегии валидации руководствуйтесь следующими рекомендациями:

По возможности реализуйте позитивную валидацию с использованием списков разрешенного ввода. Намного проще расширить список разрешенного ввода, чем пытаться определить все варианты некорректного ввода.

Для проверки безопасности не полагайтесь только на проверку на стороне клиента. Используйте проверку на стороне клиента для обеспечения обратной связи пользователю и улучшения взаимодействия с пользователем. Всегда проверяйте ввод на наличие неверных или злонамеренных данных на стороне сервера, поскольку проверка на стороне клиента может быть без труда подделана.

Если необходимо обеспечить повторное использование подхода к валидации, реализуйте его централизованно, вынося функциональность валидации в отдельные компоненты, или обратитесь к библиотекам сторонних производителей,

таким как Enterprise Library Validation Block (Блок валидации Enterprise Library)

группы patterns & practices. Это позволит создать единый механизм валидации для всех слоев и уровней приложения.

Ограничивайте, отклоняйте и очищайте пользовательский ввод. Иначе говоря, исходите из предположения о том, что весь пользовательский ввод является злонамеренным. Определите границы доверия и проверяйте длину, формат, тип и диапазон всех вводимых данных, пересекающих границы доверия.