유효성 검사의 위치

[dbalsk]

안녕하세요! 위 책으로 기본기를 잡고 개발을 하고 있는 학생입니다.
책 내용을 바탕으로 개인 프로젝트를 진행하면서 의문점이 생겨 질문 드립니다. 많이 고민해봤는데 명쾌한 해답이 떠오르지 않네요 ㅠㅠ

(376p - 유효성 검사의 위치에 대한 파트) 도메인 지식에 대한 유효성 검사는 도메인 객체에서, 무관한 데이터의 유효성을 따질 때는 dto에서 진행한다고 나와있습니다.
이를 토대로 개인 프로젝트에서 회원가입을 구현할 때 이름, 이메일, 비밀번호의 사용자 입력에 대한 유효성 검사를 진행하려고 했습니다. @ NotBlank는 dto로 컨트롤러에서 처리하도록 하고, @ Size는 엔티티로 서비스에서 처리하도록 하려고 했는데 서비스 코드에서 의문점이 발생했습니다.
서비스로 넘겨준 DTO를 엔티티로 변경하여 유효성 검사를 해줘야 하는데 이 과정에서 비밀번호가 암호화되지 않은 상태로 넘어가게 되는 문제가 생겼습니다. 물론 checkValid로 넘어간 엔티티 객체가 더 이상 참조되지 않고 가비지컬렉터에 의해 사라지긴 하겠으나, 보안적으로 좋은 코드가 아니라는 생각이 들어 질문 드립니다. 비밀번호 필드의 @ Size를 어디에서 검증해줘야 할까요? 그리고 위와 같이 회원 정보에 대한 유효성 검사는 실무에서 어떻게 수행되는지 궁금합니다.

아래는 코드는 서비스의 회원가입 메소드입니다.

    @Transactional
    public MemberDTO registerMember(MemberDTO memberDTO) {
        //1. 도메인 객체에 대한 유효성 검증  (여기서 문제 발생)  
        validationService.checkValid(MemberDTO.toEntity(memberDTO));

        //2.이메일 중복 체크 (해당 이메일로 조회하여 존재하는지 체크)
        if (memberRepository.findByMemberEmail(memberDTO.getMemberEmail()).isPresent()) {
            throw new IllegalArgumentException("이미 가입된 이메일입니다");
        }

        //3. 비밀번호 암호화
        String encryptedPassword = passwordEncoder.encode(memberDTO.getMemberPassword());

        //4. 엔티티 객체 생성
        MemberEntity memberEntity = new MemberEntity(memberDTO.getMemberName(), memberDTO.getMemberEmail(), encryptedPassword);

        //5. DB에 저장
        MemberEntity saveEntity = memberRepository.save(memberEntity);
        return MemberDTO.toDTO(saveEntity);
    }

질문과 별개로 책 덕분에 정말 많은 도움이 됐습니다! 감사합니다

[lleellee0]

@dbalsk 님 안녕하세요~
우선 책 잘 읽어주셔서 감사합니다. (_ _)

결론부터 이야기드리면, 보안을 고려하면 DTO 내에서만 검증 후 암호화 하여 넘기는게 좋습니다.
다만, 서버 메모리 내에서 지나치게 이런 부분을 의식할 필요는 없습니다.

공격을 받아 메모리 덤프 등 평문으로 저장된 비밀번호가 노출될만한 상황을 완전히 배제할 수는 없겠지만, 메모리 덤프가 가능한 수준의 공격을 받는 상황은 이미 비밀번호 평문 노출은 더이상 심각한 문제가 아니게 될겁니다.
디컴파일에 의한 소스코드 노출, 환경변수 등에 저장된 secret(DB 비밀번호 등) 노출 처럼 더 파급력 있는 문제에 직면할 가능성이 높습니다.

이런 상황을 고려한다면 안전한 코드를 작성하려고 노력하는건 좋지만, 계속 고민하시진 않았으면 좋겠어요.
(저는 컴퓨터 보안을 전공했는데, 이런 부분이 개발자에게도 중요하다고 생각했지만 보통은 중요하지 않았습니다. 물론 보안 관련 지식이 개발자로 일하는데 도움이 되는 상황은 있었지만, 코드 레벨에서 메모리 수준에서 안전한 코드를 작성해야 하는 상황은 거의 없었습니다.)

마지막으로 '비밀번호 필드의 @ Size를 어디에서 검증해줘야 할까요? 그리고 위와 같이 회원 정보에 대한 유효성 검사는 실무에서 어떻게 수행되는지 궁금합니다' 라고 질문주신 내용에 대해선, 어디에 넣든 문제는 없습니다.
다만 로그인시 사용되는 비밀번호는 사용자가 입력한 값이 넘어오는 과정에서, 웹 브라우저에서 1차적으로 유효성이 검사됩니다.
이미 표현계층(Controller)를 넘어 클라이언트 사이드까지 비밀번호에 대한 도메인 지식이 흘러나갔다고 볼 수 있습니다.
(사실 저는 입력 값의 길이 같은건 표현 계층으로도 항상 흘러갈 수 있기 때문에 도메인 지식이라고 봐야할까? 에 대해선 의문을 가지고 있습니다.)

만약 단순히 비밀번호의 길이가 아니라, 사용자가 과거 6개월간 설정했던 비밀번호와 동일한 비밀번호는 설정할 수 없다는 제약이 있다면, 이걸 검증하는건 당연히 도메인 지식이라고 볼 수 있을거고, 표현 계층으로 세어나가지 않도록 만들어야할겁니다.

답변이 좀 길어졌는데, 질문하셨던 내용에 대해 답변이 됐을까요?
혹시 또 궁금한 내용 있으면 질문 남겨주세요. :)
감사합니다.

[dbalsk]

자세한 답변 정말 감사드립니다!!
많은 도움이 됐습니다 :)

앞으로도 열심히 고민해보면서 개발해보겠습니다! 감사합니다