최근 유튜브를 보다가 제로초님의 기술 면접 관련 쇼츠 영상을 보게 됐다. 댓글이 활활 타오르고 있었고, 그 반응 덕분에 관련된 쇼츠 영상이 3개나 올라왔다는 걸 알게 됐다.
영상의 핵심은 면접 질문에 대해 "정답"을 말하는 것보다, 논리적으로 타당한 설명을 하는 것이 더 중요하다는 메시지였다.
하지만 개발자라는 족속은 기술적인 질문에는 반드시 하나의 정답이 존재해야 한다고 생각해서 논쟁이 일어난 것 같다.
나도 개발자로서, 해당 질문에 대해 내가 생각하는 답을 정리해 보았다.
클라이언트 입장에서의 "안전함"
클라이언트의 관점에서 "안전하다"는 것은, 내가 HTTP 요청을 통해 전송한 데이터가 중간에 노출되지 않고 서버에 도달하는 것을 의미한다.
만약 암호화되지 않은 HTTP 요청을 사용할 경우, 데이터를 GET 쿼리 스트링이든 POST body에 담든 관계없이, 네트워크 상에서 중간에 탈취될 수 있기 때문에 안전하지 않다고 볼 수 있다.
물론 일반적으로 URL(쿼리 스트링)은 로그나 기록에 남는 경우가 많아 POST 방식이 조금 더 안전해 보일 수는 있지만, 그 차이는 미미하다고 생각한다.
결국 HTTPS 를 통해 암호화된 요청을 보내야만 URL과 body 모두가 암호화되어 진정한 의미의 안전한 통신이 이루어진다.
따라서 클라이언트 입장에서는 다음과 같이 정리할 수 있다:
- HTTPS를 사용하면:
GETPOST모두 안전하다. - HTTP를 사용하면: 어떤 방식이든 안전하지 않다.
서버 입장에서의 "안전함"
서버의 관점에서 "안전하다"는 것은, HTTP 요청이 서버의 상태(state)를 변경하지 않는 것을 의미한다.
HTTP 표준에 따르면 GET HEAD OPTIONS 메서드는 서버의 상태를 변경하지 않으며 이를 "안전한(safe) 메서드" 라고 부른다. 이들 메서드는 멱등성(idempotency) 도 함께 갖고 있다.
하지만 멱등하다고 해서 반드시 안전한 것은 아니다. 예를 들어 PUT DELETE 메서드는 멱등하지만, 서버의 상태를 변경하기 때문에 안전한 메서드라고 볼 수는 없다.
그리고 이런 안전한 메서드의 개념은 CORS 정책에서도 사용된다. 예를 들어 CSRF 같은 공격을 막을 때 중요한 역할을 한다.
예를 들어, 비밀번호를 변경하는 POST 요청은 서버의 상태를 변경하기 때문에 안전하지 않은 요청이다. 이 경우 브라우저는 먼저 preflight 요청(OPTIONS) 을 보내서 서버가 해당 요청을 허용하는지를 확인한다. 만약 출처(origin)가 다르다면 CORS 에러를 발생시키고 본 요청은 보내지 않는다.
반면 유저 정보를 조회하는 GET 요청처럼 상태를 변경하지 않는 요청은 preflight 없이 곧바로 요청을 보낸다. 이 경우에도 CORS 정책에 따라 브라우저가 origin을 확인하고 문제가 있으면 에러를 발생시킨다.
중요한 점은, 만약 비밀번호 변경 API를 GET 메서드로 잘못 구현했다면, preflight 없이 요청이 전송되므로 서버는 이미 비밀번호를 변경해 버리고, 그 이후에야 브라우저가 CORS 오류를 감지하게 된다. 이는 심각한 보안 이슈로 이어질 수 있다.
preflight를 보내지 않은 요청인
simple request는 메소드뿐만 아니라 헤더같은 조건도 확인한다!
따라서, 서버의 상태를 변경하는 요청은 반드시 적절한 HTTP 메서드를 사용하여 구현해야 하며, 서버 개발자가 안전한 메서드의 의미를 잘 이해하고 지켜야 한다.
정리하자면, 서버 입장에서는 다음과 같이 볼 수 있다:
- 상태를 변경하지 않는
GET요청이 상대적으로 안전하다. - 하지만, 안전함은 개발자의 구현에 따라 얼마든지 깨질 수 있기 때문에, 이를 제대로 지키는 것이 중요하다.
https://www.youtube.com/shorts/bUPYAPOchuI
https://www.youtube.com/shorts/UECA2lVFicw
https://www.youtube.com/shorts/k7-uBIwQ5Wk
https://developer.mozilla.org/ko/docs/Glossary/Safe/HTTP
https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS#simple_requests
