Я бы никогда не доверил клиенту отправлять доверенные данные. Как вы заявили, существует слишком много способов представления данных. Даже не злонамеренные пользователи могут обойти систему на клиенте, если у них отключен JavaScript.
Однако по ссылке из этого элемента становится ясно, что они означают с пунктом 3:
Защитить от эксплойтов сценария можно следующими способами:
Выполнение проверки параметров для переменных формы, строки запроса
переменные и значения cookie. Эта проверка должна включать два типа
проверки: проверка того, что переменные могут быть преобразованы в
ожидаемый тип (например, преобразовать в целое число, преобразовать в
дата-время и т. д.) и проверка ожидаемых диапазонов или
форматирование. Например, переменная поста формы, которая предназначена для
целое число должно быть проверено с помощью метода Int32.TryParse для проверки
переменная действительно является целым числом. Кроме того, полученное целое число
следует проверить, чтобы убедиться, что значение находится в ожидаемом диапазоне
значений.
Применение HTML-кодировки к строковому выводу при записи значений обратно
на ответ. Это помогает гарантировать, что любой пользовательский ввод строки
будет отображаться как статический текст в браузерах вместо исполняемого
код сценария или интерпретированные элементы HTML.
Кодировка HTML преобразует элементы HTML, используя зарезервированные символы HTML,
что они отображаются, а не выполняются.
Я думаю, что это просто случай неуместного слова, потому что вы не можете выполнить этот уровень проверки на клиенте, и в примерах, содержащихся в ссылке, это явно код серверной части, представляемый без какого-либо упоминания клиент.
Edit:
У вас также по умолчанию включена проверка запросов, верно? Очевидно, что в центре внимания защиты контента лежит на сервере Microsoft.