GET, POST 뭐가 더 안전한 요청일까?

웹 개발하다 보면 한 번쯤 들어봤을 질문이죠. GET과 POST 중 뭐가 더 안전할까요? 결론부터 말하자면 POST가 더 안전합니다. 하지만 그 이유가 많은 분들이 생각하는 것과는 조금 다를 수 있어요.

흔한 오해: "POST는 암호화되고 GET은 안 된다?"

아닙니다. HTTPS를 사용하면 GET이든 POST든 전송 과정에서 모두 암호화됩니다. 반대로 HTTP를 사용하면 둘 다 평문으로 전송되어 중간에서 누구나 볼 수 있죠.

HTTP 사용 시:
- GET도 위험
- POST도 위험
- 공유기, ISP 등 중간 경로에서 모든 내용 확인 가능

HTTPS 사용 시:
- GET도 암호화
- POST도 암호화
- 중간 경로에서는 내용 확인 불가

그렇다면 왜 POST가 더 안전하다고 하는 걸까요?

POST가 더 안전한 진짜 이유

1. 서버 로그 문제

웹 서버는 기본적으로 요청 URL을 로그 파일에 기록합니다.

GET /login?user=admin&password=1234

이렇게 GET 요청을 보내면 웹서버의 액세스 로그에 비밀번호가 그대로 남습니다. 서버 관리자나 로그에 접근할 수 있는 사람이라면 누구든 볼 수 있죠.

반면 POST는 이렇게 동작합니다.

POST /login
본문: user=admin&password=1234

URL에는 경로만 기록되고, body 내용은 일반적인 액세스 로그에 남지 않습니다.

2. URL 공유와 북마크

GET 요청의 URL을 복사하면 모든 파라미터가 함께 복사됩니다. 누군가 실수로 URL을 공유하거나, 브라우저가 자동으로 북마크를 동기화하면서 민감한 정보가 노출될 수 있어요.

https://example.com/transfer?amount=1000000&to=attacker

이런 URL을 누군가에게 보여주거나 공유하는 순간, 거래 내역이 그대로 노출됩니다.

3. 브라우저 히스토리

GET 요청은 브라우저 주소창에 표시되고 히스토리에 남습니다. 공용 컴퓨터를 사용했다면 다음 사용자가 주소창을 클릭하는 것만으로도 이전 사용자의 민감한 정보를 볼 수 있죠.

4. Referer 헤더 누수

사용자가 GET 요청으로 작업을 수행한 후 다른 사이트로 이동하면, 브라우저는 이전 페이지의 URL을 Referer 헤더에 담아 보냅니다.

GET https://bank.com/transfer?password=1234
→ 다른 사이트 이동
→ Referer: https://bank.com/transfer?password=1234

외부 사이트에 민감한 정보가 노출될 수 있습니다.

HTTPS의 역할 정확히 이해하기

HTTPS는 중간 경로에서의 도청을 막아줍니다.

HTTPS가 보호하는 것:

• URL 경로와 쿼리 파라미터
• HTTP 헤더
• 요청/응답 본문
• 쿠키

HTTPS가 보호하지 못하는 것:

• 도메인 이름 (어느 사이트에 접속하는지는 보임)
• IP 주소
• 목적지 서버에 도착한 후의 데이터

결국 HTTPS를 사용하더라도 목적지 서버에는 모든 내용이 그대로 전달됩니다. 서버 관리자는 당연히 모든 데이터를 볼 수 있죠. HTTPS는 "중간에서 훔쳐보는 것"을 막는 것이지, 서버로부터 데이터를 숨기는 게 아닙니다.

CSRF 공격과 POST

POST가 GET보다 안전하다고 해서 POST만 쓰면 모든 게 해결되는 건 아닙니다. POST 요청도 CSRF(Cross-Site Request Forgery) 공격에 취약할 수 있어요.

CSRF는 사용자가 의도하지 않은 요청을 공격자가 대신 실행하게 만드는 공격입니다. 예를 들어 사용자가 은행 사이트에 로그인한 상태에서 악성 사이트를 방문하면, 그 사이트가 몰래 송금 요청을 보낼 수 있습니다.

CSRF 방어 방법:

• CSRF 토큰 사용
• SameSite 쿠키 속성 설정
• Referer 헤더 검증
• 중요한 작업은 재인증 요구

결론: 언제 뭘 써야 할까?

GET을 사용해야 하는 경우:

• 데이터 조회, 검색
• 북마크 가능해야 하는 페이지
• 캐시가 필요한 요청
• 멱등성이 보장되는 안전한 작업

POST를 사용해야 하는 경우:

• 로그인, 회원가입
• 결제, 송금 등 금융 거래
• 개인정보 전송
• 서버 상태를 변경하는 모든 작업

민감한 데이터를 다룬다면 반드시 POST + HTTPS + CSRF 방어를 함께 사용해야 합니다. POST를 쓴다고 자동으로 안전해지는 게 아니라, 적절한 보안 메커니즘을 함께 구현해야 진짜 안전한 서비스를 만들 수 있습니다.

웹 보안은 단순히 HTTP 메서드 선택의 문제가 아니라, 여러 보안 레이어를 함께 고려해야 하는 종합적인 작업이라는 걸 기억하세요.