Server ) Api Http status code에 대하여, header와 통일시켜야할까 body에만 담아야 할까?

목차

---

Api 서버를 만들면서 생긴 의문점

api 서버를 만들며, response 규격을 만들고, 이것 저것 기능구현을 마쳤다. 회원 db table에서 특정 조건으로 검색도 하고, 등록도 하고 서비스 구현에 필요한 기능은 모두 마쳤다. 그러다 병렬로 진행중인 프로젝트 담당 개발자와 api 서버 response를 비교해보았다. 다른 개발자분은 모든 응답 상태, 즉 status code를 200으로 통일시켰다. (시리즈A 스타트업의 슬픔...) 나는 이전 프로젝트에서 AR Glass와 통신할때, 헤더에 status code를 담을때 약속된 코드를 넘겨 에러 핸들링이 가능하게 했다. 헤더에 status code로 넘기면, 에러가 발생할시 AR Glass 측에서 header의 기본정보만으로 try-catch가 걸리게 된다. 반면 모든 요청을 200으로 처리하면, try-catch가 걸리지 않는다.

 

이 두 방식을 보고, 어떤 방식이 맞는 것인지 헷갈리기 시작했다. 나는 Restful api의 원래 의도를 변형하면 안된다 생각했고, header의 status code와 body에서 넘겨주는 status code는 동일해야 한다고 당연히 생각했다. 하지만, 이에 대해 여러가지 서치를 하면서 무조건 200으로 넘기고 사내에 규정한 에러코드로 넘기는 경우도 있다는 것을 알게되었다. 두 방법중 어떤 방법이 맞는것인지, 또한 어떤 상황에 어떤 status code를 넘겨야하는지 정리할 필요를 느꼈다. 

 

정리하자면 두 가지 관점이 있다.

• Restful API의 기본, REST 규칙을 무시해선 안된다.
• Status Code의 Error 명시를 통해 공격에 노출될 수 있다. *보안 측면

 

* 테스트 코드 잘못 작성해서 success가 true로 되어있음. 원래는 에러 상황에 맞게 true/false 변경됨

요청에 성공했을 경우

에러 발생 / 헤더 자체 status code를 변경할 경우

에러 발생 / 헤더는 200으로 하고 body에 명시하는 경우

 

http header

먼저 http의 header를 정리해보자. http는 서버와 클라이언트의 대화 규칙, 즉 프로토콜이다. 요청(클라이언트→서버)과 응답(서버→클라이언트)로 구분한다. http는 요청(request)과 응답(response)를 할 때, 정해진 틀대로 메세지를 보낸다. 우리가 ajax로 GET '/test/user'을 하면 클라이언트는 서버로 http 프로토콜 규칙에 맞게 보내지고, 서버에서 요청에 맞는 응답을 보낼때에도 http 규칙에 맞게 돌아오는 것이다. 때문에 반드시 status code, method, url 등이 넘어간다. 그게 룰이다. (이게 왜 넘어가냐고 질문받은 경험이 있어서...)

*정확히 말하자면 status code는 헤더에 포함되는게 아니라 http start line에 있는 정보이다.

- start line : 헤더 요약 정보
   ex) GET /search HTTP/1.1 또는 HTTP/1.1 404 Not Found
- header : 추가 정보가 담김
- body : 응답 또는 요청의 실제 내용

도움이 되는 글을 몇가지 모아보았다. http는 무엇인지, 헤더에 대한 설명, http 구조 정리 블로그 이다.

• 모질라 http, http 헤더
• http 구조 및 핵심 요소 -- 블로그 정리
• 그런 REST API로 괜찮은가 (영상)

 

status code

그럼 우리가 그렇게 골머리를 앓고있는 status code는 무엇일까? status code는 말 그대로 응답 상태이다. 서버에서 요청을 처리하고 대답, 즉 응답을 보낼때, 결과 상태가 무엇인지 정해진 code값을 보내주는 것이다. http의 규칙으로 응답 상태 코드를 넣기로 약속했기때문에 꼭 명시해야 한다. 관련하여 잘 정리된 글이 있어 링크로 남겨둔다.

https://sanghaklee.tistory.com/61

 

status code를 넘기는 전략

기본적인 http 프로토콜의 구조와 status code에 대해 알아보았다. 앞서 말했듯이 status code를 넘기는 코드는 두 가지 관점으로 나뉜다.

• Restful API의 기본, http 프로토콜 규칙을 무시해선 안된다.
• Status Code의 Error 명시를 통해 DB 설계가 노출될 수 있다. *보안 측면

Restful API의 기본, REST 아키텍처 규칙을 무시해선 안된다.

위 입장은 RESTful한 api를 구현하는 것에 중심을 둔 것이다. http status code와 body에 넣어줄 응답 상태 표시 값을 통일해야 REST api 아키텍처에 맞기때문에 RESTful API를 의도하고 서버를 만든것이라면, 해당 아키텍처에 맞추는 것이다. 기본적으로 api를 만든다고 하면 REST 아키텍처이기 때문에 status와 body의 응답 상태 코드를 통일 시키는게 일반적이다.

 

Status Code의 Error 명시를 통해 공격에 노출될 수 있다.

status code에 대해 서치해보니, 매번 200으로 보내주는 이슈가 국내 개발 환경과 관련된 것을 알게되었다. 한국인터넷진흥원(KISA) 주체로 제작된 보안 가이드, '시큐어 코딩 가이드'가 있는데, 정부전자 프레임워크를 사용하거나, 정부 주관 프로젝트를 할때 해당 가이드 라인을 따라야하는듯 하다. header status code에 200이 아닌 4xx, 5xx 코드를 넣을시 에러를 잡을 수 있게되고, 이는 공격자에게 '에러 발생 조건'을 판단할 수 있는 가능성을 준다는 것이다. 발생 조건을 판단할 수 있으면, 공격자가 오류를 발생시켜 서버를 죽일 수 도 있고, 서버에 있는 데이터 구조가 노출될 수 있는 보안 이슈가 있다는 것!

 

응답 상태 코드를 200으로 통일시키는데, 보안이슈가 있다는 것을 이번 기회에 알게 되었다. 두 방식중 어떤 방식이 옳다 그릇되다 말할 수 없고, 개발자끼리 정책을 정리해나갈 사항인것 같다. 자세한 얘기는 멘토님께 한번 여쭤보고 다시 정리해야갰다.

 

서버 개발과 '보안'은 뗄 수 없는 관계인 것 같다. 아직은 기능 구현과 최적화에 집중하고 있는 초초초초 주니어 개발자이지만, 기본적인 보안 이슈를 의식하면서 공부해야겠다. 

 

관련하여 참고한 글 링크를 남겨둔다.

[okky] 백엔드 개발자가 HTTP STATUS 코드를 항상 200 코드를 뿌려주는데 뭐라해야할지모르겠습니다

[Tstory] RESTful API 설계 가이드  

[Tistroy] 한국인터넷진흥원(KISA) 시큐어 코딩 관련 링크 모음