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. 클라이언트 쪽 유효성 검사를 무시하면 서버 쪽 유효성 검사로 인해 서버 쪽 처리가 손상 될 수 있습니다. 최근에, 우리는 이미 몇 가지 악의적 인 이점을 얻기 위해 적용될 수있는 SQL 인젝션과 다른 기술에 대해 많은 이야기를 들었습니다.

두 가지 유형의 유효성 검사는 각각의 범위에서 중요한 역할을 수행하지만 가장 강력한 것은 서버 쪽입니다. 단일 시점에 10k 명의 사용자를 수신하면 웹 서버에 들어오는 요청 수를 필터링하게됩니다. 유효하지 않은 전자 메일 주소와 같은 단일 실수가 발견되면 양식을 다시 게시하고 사용자에게 수정하여 서버 리소스와 대역폭을 확실히 소비하도록 요청합니다. 따라서 자바 스크립트 유효성 검사를 적용하는 것이 좋습니다. 자바 스크립트가 비활성화되면 서버 측 유효성 검사가 구해지며 99.99 %의 웹 사이트가 자바 스크립트를 사용하고 모든 최신 브라우저에서 기본적으로 이미 활성화되어 있기 때문에 소수의 사용자 만 실수로 비활성화 할 수 있습니다.

서버 측 유효성 검사를 수행하고 각 필드에 대한 유효성 검사 결과를 사용하여 JSON 객체를 다시 보낼 수 있으므로 클라이언트 Javascript를 최소로 유지하고 (결과 만 표시) 클라이언트와 서버 모두에서 자신을 반복하지 않고도 사용자 친화적 인 환경을 유지할 수 있습니다.

클라이언트 측은 HTML5 입력 유형 및 패턴 속성을 통한 기본 유효성 검사를 사용해야하며 , 이는보다 나은 사용자 경험을 위해 점진적인 향상에만 사용되므로 (<IE9 및 사파리에서 지원되지 않더라도 이에 의존하지는 않습니다). 그러나 주요 유효성 검사는 서버 쪽에서 수행되어야합니다.

클라이언트와 서버 유효성 검사를 모두 구현하여 프로젝트를보다 안전하게 유지하는 것이 좋습니다 .... 하나를 선택해야한다면 서버 측 유효성 검사와 함께 갈 것입니다.

https://web.archive.org/web/20131210085944/http://www.webexpertlabs.com/server-side-form-validation-using-regular-expression/에서 관련 정보를 찾을 수 있습니다.

JavaScript는 런타임에 수정할 수 있습니다.

서버에서 유효성 검사 구조를 만들고이를 클라이언트와 공유하는 패턴을 제안합니다.

예를 들어 양쪽 끝에 별도의 유효성 검사 논리가 필요합니다.

"required"inputs클라이언트 측의 속성

field.length > 0 서버 측.

그러나 동일한 유효성 검사 사양을 사용하면 양쪽 끝에서 미러링 유효성 검사의 중복 (및 실수)이 제거됩니다.

클라이언트 측 데이터 유효성 검사는보다 나은 사용자 환경에 유용 할 수 있습니다. 예를 들어, 전자 메일 주소를 잘못 입력 한 사용자는 원격 서버에서 요청을 처리 할 때까지 기다린 후 오타에 대해 알지 못합니다.

그럼에도 불구하고 공격자는 클라이언트 쪽 유효성 검사를 무시하고 브라우저를 전혀 사용하지 않을 수도 있으므로 서버 쪽 유효성 검사가 필요하며 악의적 인 사용자로부터 백엔드를 보호하기위한 실제 게이트 여야합니다.

나는 총체적이며 체계적이며 무작위적인 오류를 구별하는 흥미로운 링크를 발견했습니다 .

Client-Side validation총 및 임의 오류를 방지하는 데 완벽하게 적합합니다. 일반적으로 질감과 입력의 최대 길이입니다. 서버 측 유효성 검사 규칙을 모방하지 마십시오. 총체적인 엄지 손가락 유효성 검사 규칙 (예 : 클라이언트 쪽, n강력한 비즈니스 규칙에 따라 서버 쪽에서 200 자 )을 제공합니다.

Server-side validation체계적인 오류 방지에 완벽하게 적합합니다. 비즈니스 규칙을 시행합니다.

내가 참여한 프로젝트에서 유효성 검사는 서버에서 ajax 요청을 통해 수행됩니다. 클라이언트에서 그에 따라 오류 메시지가 표시됩니다.

추가 정보 : 총체적, 체계적, 무작위 오류 :

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

간단한 유효성 검사를 수행하는 경우 클라이언트에서 수행하는 것이 가장 좋습니다. 네트워크 트래픽을 저장하여 서버 성능을 향상시킵니다. 데이터베이스 나 비밀번호와 같은 데이터에서 데이터를 가져와야하는 유효성 검사가 복잡한 경우 데이터를 안전하게 확인할 수있는 서버에서 수행하는 것이 가장 좋습니다.