HTTP 메서드가 서버의 상태를 변경하지 않는 성질(safe method).
안전한 메서드
- GET, HEAD, OPTIONS, TRACE — → 안전
- POST, PUT, PATCH, DELETE — → 안전하지 않음
"읽기 전용" 이라고 생각하면 된다.
멱등성과의 관계
- 안전 — ⊂ 멱등
안전하면 반드시 멱등하다 (아무것도 안 바꾸니 몇 번 해도 같다) 멱등하다고 안전한 것은 아니다 (PUT·DELETE는 멱등이지만 상태를 바꾼다)
| 안전 | 멱등 | |
|---|---|---|
| GET | ○ | ○ |
| PUT | ✗ | ○ |
| DELETE | ✗ | ○ |
| POST | ✗ | ✗ |
이 포함 관계를 정확히 말할 수 있으면 좋은 답변이 된다.
부수 효과는 허용된다 — 오해하기 쉬운 부분
- GET /articles/1
- 조회수 +1, 접근 로그 기록
상태가 바뀌었는데 안전한가? 그렇다.
"클라이언트가 요청한 것은 조회일 뿐" 이라는 것이 기준이다. 클라이언트가 책임질 상태 변경이 아니면 안전성을 해치지 않는다.
다만 조회수 증가를 GET에 넣는 것은 실무적으로 주의해야 한다 — 캐시나 프리페치, 크롤러 때문에 실제와 다른 수치가 될 수 있다.
왜 중요한가 — 인프라 전체가 이 약속에 기대고 있다
- 브라우저 — : GET 결과를 캐시한다. 뒤로 가기에서 재요청 없이 보여 준다
- 프록시·CDN : GET 응답을 캐시해 원 서버에 안 보낸다
- 크롤러 — : 페이지의 모든 링크(GET)를 자동으로 따라간다
- 프리페치 — : 사용자가 클릭하기 전에 미리 GET을 보낸다
- 재시도 — : 안전한 메서드는 자동으로 재시도한다
GET이 안전하지 않으면 이 모든 것이 사고가 된다.
실제로 있었던 사고 — 대표 사례
<a href="/admin/delete?id=1">삭제</a>
관리자 페이지의 삭제 링크를 GET으로 만들었다. 구글 크롤러(또는 브라우저 프리페치)가 링크를 전부 방문하면서 모든 데이터가 삭제된다.
이 유형의 사고는 실제로 여러 차례 보고됐다.
보안과도 직결된다
<img src="https://bank.com/transfer?to=공격자&amount=100000">
GET으로 상태를 바꾸면 이미지 태그만으로 CSRF가 성립한다.
SameSite=Lax 쿠키도 GET 최상위 이동에는 붙으므로 완전히 막지 못한다.
상태 변경은 반드시 POST/PUT/PATCH/DELETE로. REST의 설계 규칙이 그대로 보안 요구사항이 되는 지점이다.
조회인데 본문이 필요하면
복잡한 검색 조건을 GET 쿼리스트링에 담기 어려울 때가 있다 (URL 길이 제한, 중첩 구조).
- POST /users/search — { 복잡한 조건 }
타협 — 안전성을 잃지만 실용적이다. 대신
- 캐시가 안 되므로 필요하면 명시적으로 처리
- 실제로 상태를 바꾸지는 않도록 구현
QUERY라는 새 메서드가 IETF에서 논의 중이지만 아직 표준이 아니다.
면접 답변 골격
"안전성은 서버 상태를 바꾸지 않는다는 성질이고, 멱등성보다 강한 조건입니다. GET을 안전하게 유지해야 캐시·크롤러·프리페치가 정상 동작하고, CSRF 위험도 줄어듭니다. 그래서 상태 변경은 반드시 POST 계열로 설계합니다."