서버에서 내려주는 에러 메시지를 직접 정의해야만 하는 이유

1차원적으로 개발자가 에러 메시지를 마음대로 컨트롤할 수 없음이 제일 큰 문제이다.

 

이유를 좀 더 상세하게 풀어보자.

스프링 프레임워크에서 기본으로 제공되는 형식화된 StatusCode, ErrorMessage로 응답을 내려주기 때문에, 소통하는 상대 서버나 클라이언트가 이해할 수 없다. 또, 상호 간에 정해놓은 에러 메시지에 대한 규칙이 깨질 수 있다.

 

에러 메시지를 서버에서 커스텀하게 정의해주지 않게 되면, 스프링 프레임워크에 종속적인 에러 메시지를 가져다 쓰게 되는 것이고 자연스레 개발자는 스프링 프레임워크에 의존적이게 되는 것이다.

어느 날 갑자기 스프링 프레임워크가 특정 에러에 대한 업데이트를 한다면, 갑자기 클라이언트에서 예상치 못한 장애가 발생할 수 있게 된다.

 

또 다른 이유로는 의도치 않게 너무 깊은 내용의 에러 원인 메시지가 담겨 화면에 노출될 수 있다.

Exception 스택이나 심지어는 SQL 쿼리 문장이 화면에 뿌려지는 경우도 있다.

만약 이런 일이 발생한다면, 일부 사용자들은 노출되어서는 안되는 해당 서비스의 테이블 구조나 프라이빗한 서비스 구조들을 추측할 수 있게 된다.

 

그럼 노출이 되어선 안되는 이유는 무엇일까?

만약 노출이 되어 특정 인물이 추측하게 된다면, SQL Injection과 같은 여러 보안 공격이 가능해지게 되는 것이다.

 

정리하자면, 개발자가 스프링 프레임워크에서 제공하는 에러 메시지를 그대로 응답해주게 된다면(직접 커스터마이징해주지 않으면), 2가지의 문제가 있다.

 

너무 Low한 레벨의 에러 메시지와 너무 상세한 내용과 원인이 담긴 에러 메시지.

 

너무 Low한 레벨의 에러 메시지는 상대 서버나 클라이언트가 발생한 에러에 대해 잘 알지 못하고, 장애가 발생할 수 있다.

반대로 불필요하게 너무 자세한 에러 메시지는 보안적인 위험이나 잠재적인 위험을 일으킬 수 있다.

 

결론은 정제되지 않은 에러가 밖으로 나가지 않도록 모든 가능한 경우들을 직접 커스텀하게 처리(ex. ExceptionHandler 클래스)할 수 있도록 해주면 좋다.