password, security token, API key를 URL에 넣으면 웹 서버 로그와 브라우저 기록 등 여러 곳에 남을 수 있습니다. OWASP REST 지침은 민감값을 URL에 넣지 말고 POST·PUT은 요청 body나 header, GET은 HTTP header로 전달하도록 권고합니다.
로그에서 query를 가리는 작업만으로 이미 노출된 token은 무효화되지 않습니다. 기존 값은 노출된 비밀로 취급해 발급 서비스의 폐기·회전 정책을 별도로 검토해야 합니다.
query는 브라우저 화면 밖에도 복제됩니다
URL은 서버 access log, 프록시·CDN 로그, 브라우저 주소 기록, 캡처된 링크에 남을 수 있습니다. 페이지가 다른 origin으로 이동하거나 자원을 불러올 때 Referer 전파도 고려해야 합니다. 어떤 곳에 얼마나 남는지는 서비스 설정에 따라 다르지만, 자격 증명을 URL에 넣으면 기록 표면이 넓어집니다. access_token이나 api_key라는 매개변수 이름만 가려도 값이 다른 이름으로 포함될 수 있으므로 URL 전체를 민감 데이터 가능성이 있는 입력으로 다뤄야 합니다.
실제 credential 없는 로그 예시를 판독합니다
| 가상 접근 기록 | 위험 해석 | 다음 조치 |
|---|---|---|
| GET /v1/items?access_token=[REDACTED] | URL query가 로그 필드에 남을 수 있음 | 호출 코드를 Authorization header 방식으로 변경 |
| GET /v1/items; Authorization: Bearer [REDACTED] | 비밀값을 query에서 분리한 예시 | header 로그도 값 마스킹·수집 제외 확인 |
| proxy 이전 로그에 예전 token 기록 | 과거 복사본은 남아 있을 수 있음 | 운영자가 token 폐기·재발급 판단 |
두 번째 행에서 header 방식으로 바꾸었다고 로그가 자동으로 안전해지는 것은 아닙니다. OWASP Logging Cheat Sheet는 access token과 password 등을 로그에 기록하지 말아야 할 민감값으로 구분합니다. 웹 서버 access log뿐 아니라 앱 디버그 기록, 오류 추적, APM, 지원 번들 등 실제 저장 위치와 마스킹 설정을 확인하세요.
요청 메서드에 따라 전달 위치를 바꿉니다
OWASP REST 문서는 POST·PUT 요청의 민감 데이터는 body나 header에, GET 요청의 민감 데이터는 HTTP header에 두도록 안내합니다. 보통 Authorization 같은 header가 인증 정보 전송에 쓰이지만, 서버와 중간 proxy가 해당 header를 로그로 남기지 않도록 확인해야 합니다. GET 경로와 검색 조건은 식별자나 비민감 필터를 담되, 비밀번호·token·API key를 포함하지 않습니다.
노출 확인과 조치는 두 단계로 나눕니다
- 운영 데이터 대신
[REDACTED]placeholder를 쓴 요청·로그 예시를 작성합니다. - 앱, gateway, reverse proxy, CDN, APM 중 URL을 기록하는 위치를 목록으로 만듭니다.
- 호출자가 URL query의 비밀값을 제거하고 승인된 header/body로 전달하는지 확인합니다.
- 로그 포맷과 오류 추적 설정이 Authorization 등 민감 header를 생략·마스킹하는지 검토합니다.
- 이미 실제 비밀값이 기록된 경우 로그 편집만으로 끝내지 말고 발급 시스템의 폐기·회전 절차를 담당자와 판단합니다.
- 보존·접근 정책에 따라 과거 기록의 삭제 또는 축소 가능 범위를 승인된 절차로 처리합니다.
- 실제 값은 채팅·티켓·테스트 출력에 복사하지 않습니다.
대괄호로 가린 예시는 실제 비밀이 아닙니다
문서와 테스트 픽스처에는 token=abc123처럼 사용할 수 있어 보이는 문자열도 쓰지 않는 편이 낫습니다. 실제 credential과 구분하기 어려우면 복사·재사용될 수 있습니다. 이 글의 [REDACTED]는 자리표시자일 뿐 유효한 값이 아닙니다. token 회전 여부와 순서는 해당 발급 시스템의 승인된 운영 절차를 따라야 합니다.
복습: URL만 지우면 사고가 끝났나요?
문제: API 호출을 header 방식으로 바꾸고 신규 로그에서 query를 제거했습니다. 이전 로그에 실제 token이 있다면 다음에 무엇을 검토해야 하나요?
정답: 이전 token을 노출된 자격 증명으로 보고 발급 서비스의 폐기·회전과 과거 로그의 보존·접근·삭제 가능성을 별도로 판단합니다. 새 호출 형식만으로 기존 값을 무효화하지 않습니다.
정답을 가리고 확인해 보세요
이 글을 위해 만든 학습 예시이며 공식 기출문제나 판매 카드의 인용이 아닙니다.
가상 로그에 GET /v2/report?api_key=[REDACTED]가 남았습니다. 새 요청의 전달 방식과 실제 이전 key가 이미 저장된 경우의 별도 대응을 하나씩 쓰세요.
정답과 해설 확인
URL에서 key를 제거해 승인된 HTTP header로 전달하고 그 header는 로그에서 제외·마스킹합니다. 실제 과거 key는 발급자의 폐기·회전 절차를 검토합니다.URL query는 서버 로그 등으로 복제될 수 있고, 저장 이후 query를 제거해도 과거 credential의 유효성이 바뀌지는 않습니다.