REST API 설계, GET 방식과 보안이슈

@ 스프링부트 기반

@ JDK 21

---

왜? GET은 JSON 처리가 된 않을까?

처음 REST API를 접했을 때, 모든 입출력값은 `JSON`으로 처리할 줄 알았습니다.

그러나, GET 방식에서는 JSON Body를 사용하지 않는게 표준입니다.

GET 요청은 원칙적으로 웹 요청에 본문(body)를 사용하지 않습니다.

• GET 요청은 QueryString를 통해 데이터를 전달합니다.( ?value=1 )
  본문(body)은 거의 사용하지 않으며, 개부분 클라이언트나 프록시가 GET body를 무시하거나 막습니다.
• 따라서 JSON 데이터를 통째로 전달하려면 POST/PUT/PATCH 같은 메서드를 사용하게 일반적입니다.

---

보안? 표현력의 트레이드오프

 

조회인데 POST를 써야 하나?  
처음 REST 설계를 할때 자주 부딪히는 보안 문제로 접하게 됩니다.

 

우선, 기존 REST 원칙은 보면 아래와 같습니다.

메서드	목적	예시
GET	리스스 조회	/users/{id}
POST	리소스 생성 or 복잡한 조회	/users or /users/search
PUT	리소스 전체 수정	/users/{id}
PATCH	리소스 부분 수정	/users/{id}

 

그런데 조회인데 URL에 파라미터 ID를 노출하고 싶지 않다면 어떤 HTTP 메서드를 사용하게 맞을까? 라는 의문이 자연스레 생각납니다.

그런데 현실은 민감한 정보는 노출하고 싶지 않은 경우가 많음으로 POST로 처리하는 경우가 대부분입니다.

 

🔐 GET 방식의 민감한 파라미터를 가진 URL이 노출되는 문제점은?

1. URL은 브라우저 히스토리, 로그, 서버 접근 기록 등 여러 곳에 기록됩니다.
2. 프록시 서버나 로드밸런서에 저장될 수 있습니다.
3. 브라우저 캐시에 남을 수 있습니다.

➡️ 여러 곳에 보안 취약점으로 노출될 상황이 많이 생깁니다.

➡️ REST 원칙에서 벗어나지만 보안상의 이유로 POST 사용은 합리적인 트레이드오프 입니다.

---

해결방법 및 대안

1. POST로 전달(위와 같은 방법)
2. GraphQL 도입
   • POST 기반
   • URL 노출 없음
   • 단점: 도입 난이도 ⬆️, 단순한 경우는 과함
3. 암호화/토큰화된 파라미터 사용
   • 민감한 데이터를 URL상에서 숨김 가능
   • 단점: 복잡하고 관리 어려움

---

결론

✅ 프로젝트의 관습에 따라 사용

✅ 실무에서 가장 많이 사용하는 방법: POST 로 전달