JavaScript : 클라이언트 측과 서버 측 유효성 검사

JavaScript : 클라이언트 측과 서버 측 유효성 검사

---

클라이언트 쪽 또는 서버 쪽 유효성 검사를 수행하는 것이 더 좋은 방법은 무엇입니까?

우리의 상황에서 우리는

• jQuery와 MVC.
• View와 Controller간에 전달할 JSON 데이터

내가하는 많은 검증은 사용자가 데이터를 입력 할 때 데이터를 검증하는 것입니다. 예를 들어 keypress이벤트를 사용하여 텍스트 상자의 문자를 방지하고 최대 문자 수를 설정하고 숫자가 범위 안에 있음을 나타냅니다.

더 좋은 질문은 클라이언트쪽에 비해 서버 쪽 유효성 검사를 수행하면 어떤 이점이 있습니까?

---

모두가 대답합니다. 우리가 가진 웹 사이트는 암호로 보호되고 소규모 사용자 기반 (<50)입니다. 자바 스크립트를 실행하지 않으면 닌자를 보내 게됩니다. 그러나 우리가 모든 사람을 위해 사이트를 디자인했다면 양쪽 모두에 대해 유효성 검사를 수행하기로 동의합니다.

---

다른 사람들이 말했듯이 두 가지를 모두 수행해야합니다. 이유는 다음과 같습니다.

고객 입장에서

일반 사용자 에게 더 나은 피드백을 제공 할 수 있으므로 먼저 클라이언트 측에서 입력의 유효성을 검사하려고합니다 . 예를 들어, 잘못된 이메일 주소를 입력하고 다음 필드로 이동하면 오류 메시지를 즉시 표시 할 수 있습니다. 이렇게하면 사용자는 양식을 제출 하기 전에 모든 필드 를 수정할 수 있습니다 .

서버에서만 유효성을 검사하는 경우 양식을 제출하고 오류 메시지가 표시되고 문제를 찾아 내야합니다.

(이러한 고통은 서버가 사용자의 원래 입력을 채운 상태로 양식을 다시 렌더링함으로써 완화 될 수 있지만 클라이언트 측 유효성 검사는 여전히 빠릅니다.)

서버 측

JavaScript를 쉽게 우회하고 위험한 입력을 서버에 제출할 수 있는 악의적 인 사용자로부터 보호 할 수 있기 때문에 서버 측에서 유효성을 검사하려고 합니다.

UI를 신뢰하는 것은 매우 위험합니다. UI를 악용 할 수있을뿐만 아니라 UI를 전혀 사용하지 않거나 브라우저를 사용하지 않을 수도 있습니다 . 사용자가 수동으로 URL을 편집하거나 자체 Javascript를 실행하거나 다른 도구를 사용하여 HTTP 요청을 조정하면 어떻게 되나요? curl예를 들어 스크립트 에서 또는 스크립트 로 사용자 지정 HTTP 요청을 보내면 어떻게 됩니까?

( 이것은 이론적이지 않습니다. 예를 들어, POST사용자가 각 회사의 검색 양식을 채운 다음 수집하고 정렬 한 것처럼 요청을 보내서 여러 파트너 항공사, 버스 회사 등으로 사용자 검색을 다시 제출 한 여행 검색 엔진에서 작업했습니다. JS의 양식 JS는 결코 실행되지 않았으며 반환 된 HTML로 오류 메시지를 제공하는 것이 매우 중요했지만 API는 좋았지 만 이것이 우리가해야 할 일이었습니다. )

이를 허용하지 않는 것은 보안 관점에서 순진 할뿐만 아니라 비표준이기도합니다. 클라이언트는 원하는 방식으로 HTTP를 보내도록 허용해야하며 올바르게 응답해야합니다. 여기에는 검증이 포함됩니다.

서버 측 유효성 검사는 호환성 에도 중요합니다. 모든 사용자가 브라우저를 사용하더라도 JavaScript를 사용할 수있는 것은 아닙니다.

부록-2016 년 12 월

서버 측 응용 프로그램 코드에서는 제대로 수행 할 수없고 클라이언트 측 코드 에서는 완전히 불가능한 일부 유효성 검사가 있습니다 . 데이터베이스의 현재 상태에 의존하기 때문입니다. 예를 들어 "다른 사용자가 해당 사용자 이름을 등록하지 않았습니다"또는 "댓글을 달고있는 블로그 게시물이 여전히 존재합니다"또는 "기존 예약이 요청한 날짜와 겹치지 않습니다"또는 "계정 잔액이 여전히 해당 구매를 충당 할만큼 충분하지 않습니다. " 데이터베이스 만이 관련 데이터에 의존하는 데이터를 안정적으로 검증 할 수 있습니다. 개발자들은 정기적으로 문제를 해결 하지만 PostgreSQL은 좋은 솔루션을 제공합니다 .

---

예, 클라이언트 측 유효성 검사는 항상 완전히 무시할 수 있습니다. 더 나은 사용자 경험을 제공하기 위해 클라이언트 측과 클라이언트 측에서 실제로 입력 한 입력이 실제로 검증되고 있는지 확인하려면 서버 측을 모두 수행해야합니다.

---

나는 그것이 매우 중요하기 때문에 그것을 반복 할 것입니다 :

항상 서버에서 확인

사용자 응답 성을위한 JavaScript를 추가합니다.

---

클라이언트 쪽 유효성 검사에 비해 서버 쪽 유효성 검사의 이점은 클라이언트 쪽 유효성 검사를 무시하거나 조작 할 수 있다는 것입니다.

• 최종 사용자가 자바 스크립트를 끌 수 있음
• 사이트를 사용하지 않는 사람이 사용자 지정 앱을 사용하여 서버로 직접 데이터를 전송할 수 있습니다.
• 페이지의 자바 스크립트 오류 (여러 가지로 인해 발생 함)로 인해 유효성 검사가 일부 또는 전부 실행될 수 있습니다.

요컨대, 항상 서버 측의 유효성을 검사 한 다음 최종 사용자 경험을 향상시키기 위해 클라이언트 측의 유효성을 추가 된 "추가"로 고려하십시오.

---

당신은 항상 있어야 서버에서 확인합니다.

또한 클라이언트에 대한 유효성 검사는 사용자에게는 좋지만 완전히 안전하지 않습니다.

---

글쎄, 나는 여전히 대답 할 여지를 찾았다.

Rob과 Nathan의 답변 외에도 클라이언트 측 유효성 검사가 중요합니다. 웹 양식에 유효성 검사를 적용 할 때는 다음 지침을 따라야합니다.

고객 입장에서

1. 웹 사이트의 실제 사용자로부터 들어오는 실제 요청을 필터링하려면 클라이언트 측 유효성 검사를 사용해야합니다.
2. 서버 측 처리 중에 발생할 수있는 오류를 줄이기 위해 클라이언트 측 유효성 검증을 사용해야합니다.
3. 클라이언트 측 유효성 검사를 사용하여 서버 측 왕복을 최소화하여 대역폭과 사용자 당 요청을 절약 할 수 있습니다.

서버 측

1. 클라이언트 측에서 성공적으로 수행 한 유효성 검사가 100 % 완벽하다고 가정해서는 안됩니다. 사용자 수가 50 명 미만인 경우에도 마찬가지입니다. 어떤 사용자 / 직원이 "악"으로 바뀌는 지 알지 못하며 적절한 검증이 이루어지지 않았다는 것을 알고 유해한 행동을합니다.
2. 이메일 주소, 전화 번호 확인 또는 유효한 입력 확인 측면에서 완벽하더라도 매우 유해한 데이터를 포함 할 수 있습니다. 정확하거나 부정확 한 경우 서버 측에서 필터링해야합니다.
3. If client-side validation is bypassed, your server-side validations comes to rescue you from any potential damage to your server-side processing. In recent times, we have already heard lot of stories of SQL Injections and other sort of techniques that might be applied in order to gain some evil benefits.

Both types of validations play important roles in their respective scope but the most strongest is the server-side. If you receive 10k users at a single point of time then you would definitely end up filtering the number of requests coming to your webserver. If you find there was a single mistake like invalid email address then they post back the form again and ask your user to correct it which will definitely eat your server resources and bandwidth. So better you apply javascript validation. If javascript is disabled then your server side validation will come to rescue and i bet only a few users might have accidentlly disable it since 99.99% of websites use javascript and its already enabled by default in all modern browsers.

---

You can do Server side validation and send back a JSON object with the validation results for each field, keeping client Javascript to a minimum (just displaying results) and still having a user friendly experience without having to repeat yourself on both client and server.

---

Client side should use a basic validation via HTML5 input types and pattern attributes and as these are only used for progressive enhancements for better user experience (Even if they are not supported on < IE9 and safari, but we don't rely on them). But the main validation should happen on the server side..

---

I will suggest to implement both client and server validation it keeps project more secure......if i have to choose one i will go with server side validation.

You can find some relevant information here https://web.archive.org/web/20131210085944/http://www.webexpertlabs.com/server-side-form-validation-using-regular-expression/

---

JavaScript can be modified at runtime.

I suggest a pattern of creating a validation structure on the server, and sharing this with the client.

You'll need separate validation logic on both ends, ex:

"required" attributes on inputs client-side

field.length > 0 server-side.

But using the same validation specification will eliminate some redundancy (and mistakes) of mirroring validation on both ends.

---

I came across an interesting link that make a distinction between gross, systematic, random errors.

Client-Side validation suits perfectly for preventing gross and random errors. Typically a max length for texture and input. Do not mimic the server-side validation rule; provide your own gross, rule of thumb validation rule (ex. 200 characters on client-side; n on server-side dictated by a strong business rule).

Server-side validation suits perfectly for preventing systematic errors; it will enforce business rules.

In a project I'm involved in, the validation is done on the server through ajax requests. On the client I display error messages accordingly.

Further reading: gross, systematic, random errors:

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

---

Client side data validation can be useful for a better user experience: for example, I a user who types wrongly his email address, should not wait til his request is processed by a remote server to learn about the typo he did.

Nevertheless, as an attacker can bypass client side validation (and may even not use the browser at all), server side validation is required, and must be the real gate to protect your backend from nefarious users.

---

If you are doing light validation, it is best to do it on the client. It will save the network traffic which will help your server perform better. If if it complicated validation that involves pulling data from a database or something, like passwords, then it best to do it on the server where the data can be securely checked.

참고URL : https://stackoverflow.com/questions/162159/javascript-client-side-vs-server-side-validation