데이터 입력 유효성 검사는 항상 내부적 인 어려움이었습니다.

레거시 응용 프로그램 재 작성 프로젝트에 실제 보안 프레임 워크 및 코드를 추가 할 때까지 (지금까지는 카드 기반의 강력한 레거시 보안 코드 및 데이터 유효성 검사를 거의 유지합니다), 얼마나 많은 유효성을 검사해야하는지 궁금합니다. 등

전문 Java 개발자로서 5 년 동안 데이터 입력 검증 및 보안 조치에 대한 개인 규칙을 작성하고 개선했습니다. 내 방법을 개선하고 싶을 때 여러분의 의견을 듣고 싶습니다. 일반적인 규칙과 절차는 훌륭하고 Java 고유의 ​​규칙과 절차도 좋습니다.

요약하면 다음은 간단한 설명과 함께 내 지침 (3 계층 웹 응용 프로그램 스타일에 노출됨)입니다.

• 1 계층 클라이언트 측 (브라우저) : 최소한의 유효성 검사, 변하지 않는 규칙 (필수 전자 메일 필드, 하나의 항목 등을 선택해야 함); “6 ~ 20 자 사이”와 같은 추가 유효성 검사를 덜 자주 사용하면 변경에 대한 유지 관리 작업이 증가하므로 비즈니스 코드가 안정되면 추가 될 수 있습니다.

• 1 계층 서버 측 (웹 통신 처리, “컨트롤러”) : 이것에 대한 규칙은 없지만 여기서는 데이터 조작 및 어셈블리 / 파싱 오류 만 처리해야한다고 생각합니다 (생일 필드는 유효한 날짜가 아닙니다). 여기에 추가 검증을 추가하면 쉽게 지루한 프로세스가됩니다.

• 2 단계 (비즈니스 계층) : 확고한 검증. 입력 데이터 형식, 범위, 값, 메소드를 언제라도 호출 할 수없는 경우의 내부 상태 확인, 사용자 역할 / 권한 등; 가능한 적은 사용자 입력 데이터를 사용하고 필요한 경우 데이터베이스에서 다시 검색하십시오. 검색된 데이터베이스 데이터도 입력으로 간주하는 경우 일부 특정 데이터가 DB에서 신뢰할 수 없거나 손상된 것으로 알려진 경우에만 유효성을 검사합니다. 강력한 타이핑이 여기서 대부분의 작업을 수행합니다 (IMHO).

• 3 계층 (데이터 계층 / DAL / DAO) : 비즈니스 계층 만 데이터에 액세스해야하므로 여기에서 많은 검증이 필요하다고 믿지 않았습니다. 그러나 “여기”를 의미 할 때 “데이터베이스에 액세스하는 코드”또는 “SQL 실행 방법”을 의미 할 때 데이터베이스 자체는 완전히 반대입니다.

• 데이터베이스 (데이터 모델) : 좋은 기본 키, 외래 키, 제약 조건, 데이터 유형 / 길이 / 크기를 사용하여 가능한 한 DB에서 부정확하고 손상된 데이터를 피할 수 있도록 신중하고 강력하며 자체 시행해야합니다. / precision 등-나는 그들 자신의 개인적인 토론을 가지고 있기 때문에 이것에서 트리거를 남기고 있습니다.

초기 데이터 유효성 검사는 훌륭하고 성능 측면에서는 좋지만 반복적 인 데이터 유효성 검사는 지루한 프로세스이며 데이터 유효성 검사 자체가 상당히 성가신 일임을 인정합니다. 그래서 많은 코더들이 그것을 건너 뛰거나 반쯤하는 이유입니다. 또한 모든 중복 유효성 검사는 항상 동기화되지 않은 경우 가능한 버그입니다. 요즘 내가 시간, 대역폭 및 CPU를 희생하여 대부분의 유효성 검사를 사례별로 처리하는 것을 선호하는 주된 이유입니다.

그래서 이것에 대해 어떻게 생각하십니까? 반대 의견? 다른 절차가 있습니까? 그런 주제에 대한 언급? 모든 기부가 유효합니다.

참고 : Java 방식의 작업을 생각하고 있다면 우리의 응용 프로그램은 Spring MVC 및 MyBatis (ORM 솔루션을 배제 한 성능 및 나쁜 데이터베이스 모델)를 기반으로하는 Spring 기반입니다. 스프링 보안을 보안 제공 업체로 추가하고 JSR 303 (Hibernate Validator?)을 추가 할 계획입니다.

감사!

편집 : 3 층에 대한 추가 설명.

답변