Код на стороне клиента и на стороне сервера проверки

что лучше сделать на стороне клиента или на стороне сервера?

в нашей ситуации мы используем

  • jQuery и MVC.
  • данные JSON для передачи между нашим представлением и контроллером.

большое проверка я проверка данных как пользователь вводит его. Например, я использую keypress событие чтобы предотвратить Буквы в текстовом поле, установите максимальное количество символов и число в диапазоне.

Я думаю, лучшим вопросом было бы, есть ли какие-либо преимущества для проверки на стороне сервера на стороне клиента?

удивительный отвечает всем. Веб-сайт, который у нас есть, защищен паролем и для небольшой базы пользователей(

148
javascript security validation

12 ответов

Как говорили другие, вы должны делать и то, и другое. Вот почему:

Стороне Клиента

вы хотите сначала проверить ввод на стороне клиента, потому что вы можете дать лучшая обратная связь со средним пользователем. Например, если ввести неверный адрес электронной почты и перейти к следующему полю, можно немедленно отобразить сообщение об ошибке. Таким образом, пользователь может исправить каждое поле до они представляют форму.

Если вы проверяете только на сервере, они должны отправить форму, получить сообщение об ошибке и попытаться выследить проблему.

(эту боль можно облегчить, если сервер повторно отобразит форму с заполненным исходным вводом пользователя, но проверка на стороне клиента все еще быстрее.)

Сервер

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

очень опасно доверять вашему пользовательскому интерфейсу. они не только могут злоупотреблять вашим пользовательским интерфейсом, но они могут вообще не использовать ваш пользовательский интерфейс или даже браузер. Что делать, если пользователь вручную редактирует URL-адрес или запускает свой собственный Javascript или настраивает свои HTTP-запросы с помощью другого инструмента? Что делать, если они отправляют пользовательские HTTP-запросы от curl или из сценария, например?

(это не теоретически; например, я работал над поисковой системой путешествий, которая повторно отправила поиск пользователя многим авиакомпаниям, автобусным компаниям и т. д., отправив POST запросы, как если бы пользователь заполнил форму поиска каждой компании, а затем собрал и отсортировал все результаты. Форма JS этих компаний никогда не выполнялась, и для нас было важно, чтобы они предоставляли сообщения об ошибках в возвращаемом HTML. Конечно, API было бы неплохо, но это было то, что мы должны были сделать.)

не учитывать это не только наивно с точки зрения безопасности, но и нестандартно: клиент должен быть разрешено отправлять HTTP любыми средствами, которые они пожелают, и вы должны ответить правильно. Это включает проверку.

проверка на стороне сервера также важна для совместимость - не все пользователи, даже если они используют браузер, будут иметь JavaScript включен.

Добавление-Декабрь 2016

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

287

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

74

Я просто повторю это, потому что это очень важно:

всегда проверять на сервере

и добавьте JavaScript для реагирования пользователя.

35

преимущество проверки на стороне сервера над проверкой на стороне клиента заключается в том, что проверку на стороне клиента можно обойти/манипулировать:

  • конечный пользователь может отключить javascript
  • данные могут быть отправлены непосредственно на ваш сервер кем-то, кто даже не использует ваш сайт, с пользовательским приложением, предназначенным для этого
  • ошибка Javascript на Вашей странице (вызванная любым количеством вещей) может привести к некоторой, но не всей вашей проверке бег!--4-->

короче говоря-всегда, всегда проверяйте серверную сторону, а затем рассматривайте проверку на стороне клиента как добавленную "дополнительную" для улучшения работы конечного пользователя.

30

вы всегда проверка на сервере.

также наличие проверки на клиенте приятно для пользователей, но совершенно небезопасно.

17

вы можете выполнить проверку на стороне сервера и отправить обратно объект JSON с результатами проверки для каждого поля, сведя клиентский Javascript к минимуму (просто отображая результаты) и по-прежнему имея удобный для пользователя опыт без необходимости повторяться как на клиенте, так и на сервере.

8

Ну, я все еще нахожу место для ответа.

в дополнение к ответам от Роба и Натана я бы добавил, что имеет значение проверка на стороне клиента. При применении валидаций в webforms необходимо следовать следующим рекомендациям:

На Стороне Клиента

  1. необходимо использовать проверки на стороне клиента для фильтрации подлинных запросов, поступающих от подлинных пользователей на вашем сайте.
  2. проверка на стороне клиента должна использоваться для уменьшения ошибок это может произойти во время обработки на стороне сервера.
  3. проверка на стороне клиента должна использоваться для минимизации круговых поездок на стороне сервера, чтобы сохранить пропускную способность и запросы на пользователя.

На Стороне Сервера

  1. вы не должны предполагать, что проверка успешно выполнена на стороне клиента на 100% идеально. Неважно, даже если он обслуживает менее 50 пользователей. Вы никогда не знаете, какой из ваших пользователей / emplyee превратиться в "зло" и сделать некоторые вредные действия, зная у вас нет надлежащих подтверждений.
  2. даже если его идеальный с точки зрения проверки адреса электронной почты, номера телефонов или проверки некоторых допустимых входов он может содержать очень вредные данные. Который должен быть отфильтрован на стороне сервера, независимо от того, правильный или неправильный.
  3. если проверка на стороне клиента обходится, ваши проверки на стороне сервера приходят, чтобы спасти вас от любого потенциального ущерба для обработки на стороне сервера. В последнее время, мы уже слышали много историй SQL-инъекции и другие методы, которые могут быть применены для получения некоторых злых преимуществ.

оба типа проверок играют важную роль в их соответствующей области, но наиболее сильным является серверная сторона. Если вы получаете 10k пользователей в один момент времени, то вы определенно закончите фильтрацию количества запросов, поступающих на ваш веб-сервер. Если вы обнаружите, что была одна ошибка, как недопустимый адрес электронной почты, то они снова отправляют форму и спрашивают ваш пользователь, чтобы исправить это, что, безусловно, съест ваши ресурсы сервера и пропускную способность. Поэтому лучше применить проверку javascript. Если javascript отключен, то ваша проверка на стороне сервера придет на помощь, и я уверен, что только несколько пользователей могут случайно отключить его, так как 99.99% веб-сайтов используют javascript и его уже включен по умолчанию во всех современных браузерах.

7

клиентская сторона должна использовать базовую проверку через типы ввода HTML5 и шаблон атрибутами и поскольку они используются только для прогрессивных улучшений для лучшего пользовательского опыта (даже если они не поддерживаются на

4

JavaScript может быть изменен во время выполнения.

Я предлагаю шаблон создания структуры проверки на сервере и совместного использования этого с клиентом.

вам понадобится отдельная логика проверки на обоих концах, например:

"required" атрибуты inputs на стороне клиента

field.length > 0 на стороне сервера.

но использование одной и той же спецификации проверки устранит некоторую избыточность (и ошибки) зеркальной проверки с обеих сторон.

2

Я предложу реализовать как клиентскую, так и серверную проверку, она сохраняет проект более безопасным......если мне нужно выбрать один, я пойду с проверкой на стороне сервера.

Обновление 23 Июля 2018: следующая ссылка больше не доступна:

вы можете найти здесь актуальную информацию http://www.webexpertlabs.com/server-side-form-validation-using-regular-expression/

2

я наткнулся на интересную ссылку, которая делает различие между грубые, систематические, случайные ошибки.

Client-Side validation идеально подходит для предотвращения грубых и случайных ошибок. Типично максимальная длина для текстуры и входного сигнала. Не имитируйте правило проверки на стороне сервера; предоставьте свое собственное правило проверки gross, rule of thumb (ex. 200 символов на стороне клиента; n на стороне сервера, продиктованной сильным бизнес-правилом).

Server-side validation идеально подходит для предотвращение систематических ошибок; это обеспечит соблюдение бизнес-правил.

в проекте, в котором я участвую, проверка выполняется на сервере через ajax-запросы. На клиенте я отображаю сообщения об ошибках соответственно.

дальнейшее чтение: грубые, систематические, случайные ошибки:

https://answers.yahoo.com/question/index?qid=20080918203131AAEt6GO

1

Если вы делаете светлую проверку, то самое лучшее сделать ее на клиенте. Это сохранит сетевой трафик, который поможет вашему серверу работать лучше. Если это сложная проверка, которая включает в себя извлечение данных из базы данных или что-то вроде паролей, то лучше всего сделать это на сервере, где данные могут быть надежно проверены.

-2