작성한 질문수 6

0

안녕하세요. yoona405님, 공식 서포터즈 y2gcoder입니다.

제가 yoona405님이 만들고 계신 프로젝트의 요구사항을 정확하게 이해하지 못한 상태에서 답변을 드리는 점, 양해 부탁드리겠습니다!

서버에 요청을 보낸 클라이언트가 저희 서비스임을 검증하고, 외부에서 패킷을 볼 수 없도록 HTTPS를 사용함에도

저는 이 부분과

유저1이 유저가 속한 카톡방1에서 유저가 생성한 채팅을 삭제하는 요청을 보냈을 때(/DELETE room/1/chatting/1), 현재 서버에서는 유저가 카톡방에 속하는지, 해당 채팅이 해당 채팅 방에 속하는지, 채팅의 작성자가 유저인지 db에서 검증하는 과정을 거칩니다.

이 부분은 전자로 말씀해주신 부분은 보안 검증이고, 후자로 말씀해주신 부분은 우리 서비스의 기능적 요구사항에 관한 검증이라는 점에서 서로 다른 목적을 가진 검증 로직이라고 생각합니다. 예를 들어 당장 정상적으로 가입한 유저 B가 정상적으로 가입한 유저 A의 채팅을 삭제하는 요청을 보낸다면, 보안 쪽 검증만으로 이를 방지할 수 있을지 모르겠습니다.

또한 프론트와 서버가 통신을 나눴기 때문에 비즈니스적인 로직 검증은 더욱 더 중요해집니다. 예를 들어 위에서 말씀드린 반례에서 프론트를 검증하기 위한 헤더는 탈취하고, 나머지 토큰을 비롯한 요청 값들은 정상적으로 보낸다고 하면, 더더욱 비즈니스적인 로직 검증이 필요해질 것입니다.

서버가 API 로 프론트와 통신하는 이상 프론트의 유효성 검증 및 기능 제한만으로는 비즈니스적인 요구사항 및 제약을 다 막을 수 없습니다. 비즈니스적인 요구사항에 대한 검증은 서버에서도 반드시 작업해주셔야 하는 필수 구현 항목입니다.

이와는 별개로 위의 예시에서 검증이 너무 불필요하게 많이 있다고 생각이 들어 질문을 주셨다면, 과연 채팅 삭제 API 를 /chatting/{id} 등으로 처리하고, 해당 채팅의 소유주가 현재 인증 토큰의 유저와 같은지만 체크할 수는 없을까요? 왜냐하면 채팅 삭제가 주요 기능이고 채팅 식별자가 중복 가능성이 없는 유일한 값이라면 채팅에 대한 소유주 확인만 하면 될 것이라 생각했기 때문입니다. 다만 이는 제가 yoona405님 프로젝트의 요구사항 및 제약을 다 파악하지 못한 상태에서 드리는 질문입니다!

감사합니다.