HTTP에서 “GET”이 더 안전하다?

728x90

들어가며

웹 관련 개발자가 된다면 반드시 접하게 되고, 사용하며 땔 수 없는 것이 HTTP이다.

cs를 공부해본 사람이라면 이런 이야기를 들어본 경험이 있다.

POST는 값을 바디에 넣어 보내기 때문에 더 안전하다.

URL - param에 값을 실어 보내는 GET에 비해 더 안전하다는 것은 어찌보면

당연한 이야기이다.

이번 글에서는 이런 관점을 바꿔 rfc문서에서 나오는 GET이 더 Safe 하다는 이야기를

분석해본다.

GET 이 더 안전하다는건 어디나라 말이냐?

필자의 짧은 실력이지만, 기술은 관점에 따라 해석될 여지가 모두 다르며

이에따라 최신 스택 , 좋은 기술이라도 의미를 두고 사용하는 것이 중요하다고 생각한다.

이 이야기 뭐냐면 당연히 POST가 데이터를 송, 수신 하는데 있어 안전한 것은 사실이다.

그런데 rfc문서에서는 왜 GET이 더 안전하다고 표현했는가?

✔️ Safety (안전성)

"A request method is considered safe if it does not alter the server state."

참고: RFC 7231, Section 4.2.1
즉, 서버에 영향을 주지 않는 요청이면 안전한 요청입니다.
GET, HEAD, OPTIONS, TRACE는 안전한 메서드로 간주됨.

즉, 서버에 영향을 주지 않는다. 데이터의 변경 사항을 발생 시키지 않는다는 점에서

안전하다고 볼 수 있다는 것이다.

이것을 말하는 것이

✔️ Idempotency (멱등성)

"A request method is idempotent if an identical request can be made once or several times in succession with the same effect."

참고: RFC 7231, Section 4.2.2
즉, 여러 번 호출해도 결과가 같아야 멱등적입니다.
GET, PUT, DELETE, HEAD, OPTIONS는 멱등적인 메서드.

이라고 표현할 수 있다. 즉, 몇번을 호출해도 결과가 같다는 의미이다.

이것을 이해하면

PUT 과 PATCH의 차이점을 이해하는데도 도움이 되는데,

PATCH는 일부데이터를 수정하고, PUT은 전체 데이터를 수정할때 용의하게 사용된다.

실제로 동작을 목적에 맞춰서 설계한다면,

사용자의 정보를 수정하는 기능을 만드는 기능이 필요하다면 PATCH를

어떤 특정 정보의 PK값이나 유니크 값을 수정할때는 PUT 데이터로 아예 한번에 넣도록

유도하게 만드는 것을 권장한다고 한다.

그래서 다시 돌아가서

GET VS POST 안전?

항목 GET POST

RFC상 안전성(Safe)	✅ Yes (읽기 전용)	❌ No (상태 변화 발생)
RFC상 멱등성(Idempotent)	✅ Yes	❌ No (보통 멱등하지 않음)
브라우저 캐시	캐시 가능 (기본적으로 캐시됨)	일반적으로 캐시되지 않음
데이터 노출	URL에 노출됨 (보안상 위험)	Body에 포함 (상대적으로 안전)
데이터 전송량 한계	URL 길이 제한 (2~8KB)	거의 무제한 (서버 설정에 따라 다름)
CSRF 위험성	높음 (자동 전송 가능)	낮음 (보통 form을 통해 수동 전송)
사용 목적	리소스 조회(Read)	리소스 생성 또는 처리(Create/Update)

정리해보면 이렇다.

결국 우리가 알고 있는 사실은 다르지않다. 다만, 다른 시각으로 봤을때 좋은 포인트롤 볼 수 있다

약간의 사설이지만,

보통 개발을 들어가게 되면 데이터를 받고, 주고, 수정하고, 가공하는 것이 키포인다.

그런데 이런 과정중에 지속적으로 발전 시켜나가다 보면 데이터를 주고 받는 “과정”에

집중하게 되며, 내가 생각하는

AI시대의 개발자와 비개발자의 차이라고 생각한다.

단순히 값을 주고 받는 것은 ai를 활용하면 누구나 할 수 있는 일이다.

하지만, 값을 주고 받는 ‘과정’을 이해하고 이를 더 효율적으로, 적시에 맞게 근거있는

선택을 하는 것은 결국 개발자의 몫이라고 생각하며

이런 관점을 키워나가는 과정중에 하나를 발견한 내용을 공유한다.