짧은 링크에 개인정보를 넣으면 안 되는 이유｜안전한 URL 점검법
짧은 링크를 만들기 전에 원본 URL에서 이름, 이메일, 전화번호, 주문번호, 인증 토큰 같은 민감한 값을 제거해야 합니다. HTTPS는 전송 중 내용을 보호하지만 URL은 브라우저 기록, 서버 로그, 분석 화면, 캡처와 공유 과정에 남을 수 있습니다. 필요한 경우 실제 정보를 넣지 말고 서버에서만 해석할 수 있는 짧고 일회성인 임의 식별자를 사용하세요.
HTTPS인데도 URL 정보가 왜 노출될까?
HTTPS는 브라우저와 서버 사이의 통신을 암호화하지만 사용자가 보는 주소 자체를 애플리케이션 내부에서 사라지게 하지는 않습니다. 주소는 브라우저 방문 기록, 웹 서버 접근 로그, 프록시와 오류 추적, 분석 도구의 페이지 위치, 사용자가 복사한 메시지와 화면 캡처에 남을 수 있습니다. 짧은 링크 서비스도 목적지 주소를 저장하므로 민감한 원본을 감춰 주는 금고로 보면 안 됩니다.
OWASP의 쿼리 문자열 정보 노출 안내는 HTTPS를 사용해도 URL의 값이 Referer, 웹 로그, 공유 시스템, 브라우저 기록과 캐시에 노출될 수 있다고 설명합니다. 즉 주소 길이를 줄여도 원본 데이터의 민감도는 변하지 않습니다.
어떤 값은 URL에 넣지 말아야 하나요?
| 값의 종류 | 위험 | 대안 |
| 이름·이메일·전화번호 | 링크 공유만으로 개인정보 노출 | 로그인 뒤 서버에서 조회 |
| 주민번호·생년월일 전체 | 식별·사칭 위험 | 수집 자체를 최소화 |
| 비밀번호·API 키·세션 토큰 | 계정·시스템 접근 탈취 | 보안 헤더 또는 서버 세션 |
| 주문번호·예약번호 | 상태 추측과 정보 조회 | 권한 확인이 있는 임의 ID |
| 건강·상담·금융 내용 | 민감정보가 로그와 기록에 잔존 | 인증된 화면에서 조회 |
마케팅용 UTM도 개인정보를 담는 칸이 아닙니다. source에는 발신 채널, medium에는 채널 유형, campaign에는 캠페인 이름을 넣고 개인 이메일이나 고객 번호를 넣지 않습니다. 소재 구분용 content도 사람을 식별하지 않는 일반 이름으로 제한합니다.
짧게 바꾸면 원본 주소가 숨겨지나요?
사용자 화면에서는 짧은 주소만 보일 수 있지만 클릭하면 서비스가 저장한 원본 목적지로 이동합니다. 서비스 운영자, 접근 권한이 있는 관리자, 로그 시스템은 목적지를 처리할 수 있고 공개 미리보기나 URL 확장 도구에서 원본이 드러날 수도 있습니다. 따라서 원본 URL에 넣어도 되는 정보만 단축해야 합니다.
특히 만료되지 않는 짧은 주소에 일회성 로그인 토큰을 연결하면 링크가 전달되거나 기록에서 발견됐을 때 계정 접근 위험이 생깁니다. 토큰이 꼭 필요하다면 짧은 유효기간, 한 번 사용 뒤 폐기, 대상 사용자 확인, 사용 후 재인증 같은 방어를 함께 적용합니다.
URL에는 무엇까지 넣어도 될까?
공개적으로 보여도 문제가 없고 링크 목적을 분류하는 데 필요한 값만 넣습니다. 제품 카테고리, 공개 캠페인 이름, 언어 설정, 페이지 번호처럼 노출되어도 민감하지 않은 값은 쿼리로 사용할 수 있습니다. 그러나 값 자체가 공개 정보여도 여러 항목을 결합하면 개인을 좁힐 수 있는지 검토해야 합니다.
HTTP Semantics 표준인 RFC 9110도 URI에 사용자 제공 데이터를 구성할 때 민감한 값을 제외하거나 변환하는 방안을 설명합니다. 공개 URL은 다른 문서와 로그로 복사되기 쉬우므로 서버 안의 비공개 레코드를 가리키는 임의 키와 접근 권한 검사를 조합하는 편이 낫습니다.
안전한 대체 식별자는 어떻게 만들까?
- 실제 개인정보와 직접 닮지 않은 충분히 예측하기 어려운 임의 값을 만듭니다.
- 서버 데이터베이스에서 그 값과 대상 레코드를 연결합니다.
- 링크를 열 때 로그인 또는 추가 권한을 확인합니다.
- 유효기간과 최대 사용 횟수를 정합니다.
- 사용 완료·취소·만료 시 연결을 폐기합니다.
- 로그에는 원본 개인정보 대신 최소한의 상태만 남깁니다.
임의 식별자도 그 자체가 접근 권한이 되면 결국 비밀 토큰입니다. 주소를 아는 사람 누구나 열 수 있는 구조보다 로그인과 권한 검사를 거쳐야 내용을 보여 주는 구조가 안전합니다. 공개 공유가 목적이면 표시할 정보 범위를 별도로 줄입니다.
실제 상황에서는 어떻게 고칠까?
사례 1: 상담 예약 링크
예약 확인 주소에 고객 이름과 전화번호가 그대로 들어가 문자로 전송되고 있었습니다. 담당자는 URL을 예측 불가능한 예약 키로 바꾸고, 링크를 열면 휴대전화 일부 확인을 거치도록 수정했습니다. 메시지를 다른 사람이 보더라도 주소만으로 고객 정보가 드러나는 문제를 줄였습니다.
사례 2: 이메일 캠페인 링크
성과를 개인별로 보려는 목적으로 utm_content에 이메일 주소가 들어가 있었습니다. 운영자는 개인 주소를 제거하고 소재 위치만 구분하는 hero_button, footer_link 같은 값으로 바꿨습니다. 개별 사용자 분석은 동의와 접근 통제가 있는 내부 식별 체계로 분리했습니다.
공유 전에 무엇을 점검해야 할까?
- 물음표 뒤 쿼리와 해시 조각을 끝까지 읽습니다.
- 이름·연락처·계정·주문·인증 값을 찾습니다.
- URL 디코딩 후에도 민감한 값이 나타나지 않는지 봅니다.
- 짧은 주소의 원본 목적지를 관리자 화면에서 다시 확인합니다.
- 링크를 받은 다른 사용자가 권한 없이 내용을 볼 수 있는지 시험합니다.
- 만료·폐기·목적지 변경 절차가 실제로 작동하는지 확인합니다.
이미 민감한 링크를 공개했다면 짧은 주소만 삭제해서 끝내지 않습니다. 원본 토큰과 세션을 폐기하고, 서버 로그와 분석 도구에 수집됐는지 확인하며, 필요한 경우 영향을 받은 사용자에게 안내합니다. 새 링크는 새로운 임의 값으로 발급하고 이전 값은 다시 사용하지 않습니다.
확인한 출처
관련 도구
FAQ
URL에 이메일 주소를 암호화해서 넣으면 괜찮나요?
복호화 가능하거나 반복되는 값은 추적과 재식별 위험이 남으므로 URL에는 실제 개인정보 대신 권한 검사가 있는 임의 식별자를 쓰는 편이 낫습니다.
UTM에 고객 번호를 넣어도 되나요?
권장하지 않습니다. UTM은 보고서와 주소에 노출되므로 채널·캠페인·소재처럼 개인을 식별하지 않는 값만 사용하세요.
짧은 링크를 삭제하면 노출도 끝나나요?
원본 주소와 토큰이 기록이나 메시지에 남을 수 있어 토큰 폐기, 세션 종료, 로그 영향 확인까지 함께 해야 합니다.
주문 조회 링크는 어떻게 보호하나요?
예측하기 어려운 임의 키를 쓰고 로그인이나 추가 확인, 짧은 유효기간, 사용 후 폐기를 결합해 주소만으로 조회되지 않게 합니다.
← 허브로 돌아가기