서버의 예외처리는 어디까지 하는게 맞을까요?

안녕하세요! 좋은 고민인것 같습니다 ㅎㅎ 요구사항마다 다르겠지만 현업에서는 보통 클라이언트와 무관하게 서버에서 검증 로직을 돌리는 편인 것 같아요. 여러가지 이유가 있겠지만 간단히 생각해보면 서버 입장에서는 요청을 한 주체에서 값들이 검증되었는지 안되었는지 알수 없습니다. 극단적으로는 악의적인 의도로 요청이 네트워크를 타고 이동하는 도중에 가로채져서 요청에 들어있는 값들이 변형 되었을수도 있구요. 그래서 클라이언트 쪽에 검증 로직이 있다고해도 보통 해당 값을 처리해야하는 서버에도 검증 로직이 있는 편입니다. 참고해보세요 :) - https://jojoldu.tistory.com/157 - https://hhhhicode.tistory.com/2

클라이언트에서 넘어오는 데이터는 충분히 조작될 수 있기에 서버단에서 한번 더 검증하는게 맞다고 생각합니다.

서버측에서는 클라이언트가 어떠한 나쁜짓을 하더라도 서버가 멈추면 안돼! 라고 선제를 두시면 작업하시면서 자연스럽게 validation 체크 로직을 만들고 있는 나 자신을 봅니다. 그러다보면 Xss 필터를 접하기 시작하면서 SQL 인젝션, 파일변형 등등 security를 만지게 되죠. 그렇게 서버쪽 지식이 늘어나면서 감금이 됩니다... 주륵

사용자에게 이 FE에서 배포한 app으로 쓰세요, 권장해요. 이래도 말 안듣는 사용자가 꼭 있죠! 간편하다고 따로 뭘 만들어서 쓰는 이런 사람들이 있어서 오늘도 모두가 고생합니다.

클라이언트의 값 검증이 서버의 관심사인가? 라는 의문을 가져봅시다. 자연스럽게 서버도 요청 값 검증을 해야한다는 결론이 도출됩니다.

클라이언트에서 넘어오는 값은 100% 신뢰 할 수 없기에 이중으로 체크합니다:) 더 나아가 유효성 검증 + 요청 전문 암복호화 작업까지 추천드립니다

저는 처음에 혼자 개발공부하고 혼자 프로젝트 진행했을때에는 예시로 드신것처럼 게시글을 삭제하는 버튼은 작성자에게만 노출되므로 이 게시글이 정말 이 유저의 게시글이 맞는가, 를 체크안하고 api들을 만들었습니다 프론트에서 넘어오는 값들을 의심하지 않았죠 지금은 취업하고 새로운 팀에서 많이 배우면서 요즘 제일 고민하는 부분입니다 저도 백엔드 api는 방어코드로 작성하는게 좋다고 생각합니다 예로 드신 게시글을 삭제하는 로직을 저도 요청한 유저가 존재하는가, 해당 게시들이 존재하는가(이미 삭제되었는가), 삭제 후 삭제결과가 성공적이었는가 등을 체크합니다 다른분들이 말씀하시는거 처럼 프론트에서 넘어오는 값은 여러 이유로 신뢰할수 없다고 생각하고 있습니다 ㅎ api 작성후 postman으로 다양한 상황으로 쏘아보면서 테스트하는것이 좋다고 배웠는데 사실 그러면 개발 시간이 넘 오래 걸리니 최대한 머리에서 시뮬레이션 하고 넘어가네요 ㅎㅎ