URL의 # 이후가 서버 로그에 안 남는 이유
브라우저가 HTTP 요청을 보낼 때, # 뒤의 내용은 로컬에 남습니다. 일회용 링크는 복호화 키를 s.html?id={id}#{key}의 # 뒤에 붙입니다. 서버는 암호문 번호만 받고, 키는 보지 못합니다. 읽기 페이지는 수신자에게 공개되며, 먼저 가입할 필요 없습니다. 아래에서는 이 경계를 풀어 쓰고, 그 자리에서 확인하는 단계를 적습니다.
# 뒤가 하는 역할
비밀이 주소창에 보인다고 해서, 서버 로그에 반드시 사본이 있는 것은 아닙니다. 이 판단은 쿼리 매개변수에는 대체로 맞고, 프래그먼트에는 맞지 않습니다.
운영 담당자가 임시 비밀번호를 채팅에 넣고, 고객지원이 관리 화면 주소와 token을 함께 전달할 때, 가장 두려운 것은 대개 「상대가 보는 것」이 아니라 「중간 단계마다 전체 링크가 남을 수 있다는 것」입니다. 그래서 많은 사람이 기본값으로 생각합니다. 비밀이 주소창에 보이면 서버 로그에도 반드시 사본이 있다고.
완전한 주소는 세 덩어리로 나눌 수 있습니다. 프로토콜과 호스트는 브라우저가 누구에게 연결할지를 정하고, 경로와 물음표 뒤 쿼리 매개변수는 어떤 자원을 가져올지를 정합니다. 이 두 덩어리는 HTTP 요청 라인에 나타납니다. # 뒤 문자는 fragment이며, 한국어로는 흔히 프래그먼트라고 합니다. 처음에는 브라우저에게 페이지의 어떤 앵커로 스크롤하라고 알리는 용도였고, 이후 프론트엔드 스크립트도 location.hash로 이 기기에서 이 문자열을 읽습니다. 서버는 이것을 받지 않으며, 라우팅이나 인증에 써서도 안 됩니다.
키를 # 뒤에 두는 것은 새로운 암호화 알고리즘을 발명한 것이 아닙니다. 브라우저가 오래 지켜 온 전송 경계를 쓰는 것뿐입니다. 같은 링크가 「서버에 줄 번호」와 「현재 탭에만 줄 키」를 동시에 가질 수 있습니다. UsePwd 일회용 링크가 바로 이 경계를 씁니다. 만들기 페이지와 읽기 페이지 모두 가입 없이 바로 사용하며, 어느 쪽도 가입할 필요가 없습니다. 서버는 암호문만 잠시 보관하고, 평문과 키는 기본적으로 요청 본문으로 나가지 않습니다.
실제로 나가는 것은 어느 구간인가
s.html?id=abc123#the-key를 보세요. 브라우저가 보내는 GET의 요청 라인에는 보통 경로와 id만 있습니다. #the-key는 요청에 없고, 기록할 로그도 없습니다.
이것은 URL 표준이 오래도록 그래 온 것이지, 특정 사이트의 사적 약속도 아니고 「서버가 보지 않기로 했다」는 뜻도 아닙니다. 표의 「서버가 볼 수 있는가」는 TLS 종료 이후, 오리진이나 직접 통제하는 리버스 프록시가 이번 HTTP 요청에서 해당 필드를 읽을 수 있는지를 말합니다. 이 기기가 장악됐거나, 확장 프로그램이 페이지를 읽거나, 상대가 스크린샷을 따로 저장하는 경우는 다루지 않습니다.
?id=abc123&key=secret
전체가 요청 라인에 나타납니다. 흔한 접속 로그는 보통 전체 URL을 남깁니다.
#secret
브라우저는 이것을 요청의 일부로 취급하지 않습니다. 흔한 접속 로그에는 이 구간을 기록할 내용이 없습니다.
ciphertext
일회용 링크를 만들 때 실제로 올리는 부분입니다. UsePwd에서는 암호문, 유효 시간(시간 단위), 읽기 횟수만 있습니다.
흔한 오해는 「이미 HTTPS를 쓰니 로그에 안 보인다」입니다. 전송 암호화가 보호하는 것은 중간자가 선로 위의 평문을 읽지 못하게 하는 일입니다. 오리진과 직접 통제하는 리버스 프록시는 TLS 종료 이후에도 전체 요청 라인을 볼 수 있습니다. 그래서 HTTPS는 접속 로그에서 ?key=를 지워 주지 않습니다. 프래그먼트가 로그에 안 들어가는 이유는 애초에 나가지 않았기 때문이지, 선로가 암호화됐기 때문이 아닙니다.
또 하나 놓치기 쉬운 통로는 Referer입니다. 기본값으로, 어떤 이동은 「출발 페이지의 URL」을 다음 목적지에 넘깁니다. 최신 브라우저는 HTTPS 사이에서 이동할 때 기본 정책으로 보통 fragment를 제거하지만, 쿼리 매개변수는 여전히 Referer에 남을 수 있습니다. 일회용 키를 # 뒤에 두는 편이 ?key=보다 나은 이유 중 하나도 이것입니다. 모든 하위 사이트가 출발 주소를 기록하지 않겠다고 약속하게 만들 수는 없습니다.
프래그먼트가 HTTP에 안 들어간다고 해서 「링크 자체를 복사할 수 없다」는 뜻은 아닙니다. 주소창의 전체 문자열, # 뒤의 키를 포함해, 이 기기의 기록, 공유 미리보기, 직접 보낸 메시지에 그대로 나타납니다. 이 글은 서버 로그라는 층만 설명하며, 프래그먼트를 만능 금고로 쓰지 않습니다.
네트워크 패널을 열면 바로 보입니다
목표는 「세상 누구도 못 본다」를 증명하는 것이 아니라, 이번 UsePwd로 보낸 HTTP 요청에 # 뒤의 키가 없다는 것을 증명하는 일입니다.
-
01
일회용 링크 만들기 페이지를 여세요
일회용 링크로 들어가세요. 페이지는 가입 없이 바로 사용하며, 로그인할 필요 없습니다. 알아볼 수 있지만 실제 운영 키는 쓰지 않는 예시 글을 입력하세요.
-
02
네트워크 패널을 열고 기록을 지우세요
F12를 누르거나 마우스 오른쪽에서 검사를 선택한 뒤, 네트워크(Network)로 전환하세요. 필요하면 기존 요청을 지워, 페이지 첫 로드와 섞이지 않게 하세요.
-
03
링크를 하나 만드세요
제출하면 브라우저는 먼저 현재 탭에서 AES-256-GCM으로 암호화한 뒤,
/api/secrets로 요청을 보냅니다. 필드는ciphertext,ttl_hours,max_reads입니다. 생성된 공유 주소 형태는s.html?id={id}#{key}입니다. -
04
만들기 요청을 확인하세요
그 POST를 여세요. 요청 URL에
#뒤의 키가 보이면 안 되고, 요청 본문에는 암호문과 숫자 두 개가 있어야 하며, 방금 입력한 예시 글이 있으면 안 됩니다. -
05
읽기 페이지를 열어 GET도 확인하세요
같은 링크로 읽기 페이지를 여세요. 이어지는 GET이나 상태 조회의 경로에는
id만 있습니다. 주소창의#뒤 문자열과 네트워크 패널의 요청 URL을 나란히 대조하세요. 전자는 로컬에 있고, 후자에는 이 구간이 없습니다.
운영 환경에는 /tj/로 가는 방문 analytics가 있을 수 있습니다. 페이로드는 페이지와 버튼 이름, 예를 들어 「링크 만들기」이며, 평문도 키도 파일 내용도 아닙니다. 이 기기 미리보기에서는 analytics를 보내지 않습니다. 「키가 HTTP에 들어갔는가」만 보고 싶다면 먼저 /api/secrets만 걸러 보면 되며, analytics 요청을 암호문 통로로 오해할 필요는 없습니다.
이 단계는 보안 안내의 「평문이 브라우저를 떠나나」와 서로 보완합니다. 보안 안내는 로컬 계산의 범위를 답하고, 이 글은 URL을 분해해 로그에 # 구간이 없는 이유만 설명합니다. 두 페이지 모두 만들기 페이지의 조작 폼을 대체하지 않습니다.
일회용 링크가 이 경계를 쓰는 방식
번호는 쿼리 매개변수, 키는 프래그먼트입니다. 서버는 암호문이 하나 있고, 몇 번 읽을 수 있으며, 언제 만료되는지만 알고, 무엇으로 여는지는 모릅니다.
만들 때 현재 탭은 Web Crypto로 무작위 키를 만들고, AES-256-GCM으로 텍스트를 암호화한 뒤 암호문을 서버에 넘깁니다. 반환된 번호는 ?id=에 쓰고, 키는 # 뒤에만 붙입니다.
읽기 페이지는 수신자에게 공개됩니다. 상대가 s.html?id={id}#{key}를 열면, 브라우저는 먼저 id로 서버에서 암호문을 받거나 상태를 물은 뒤, 이 기기에 있는 프래그먼트 키로 복호화합니다. 만들 때 정한 횟수에 도달하면 서버가 암호문을 삭제하고, 링크는 더 이상 읽을 수 없습니다. 수신자도 가입할 필요가 없습니다. 읽기 페이지 자체는 임시 암호문 장면이며, 이 사이트의 색인 입구가 아닙니다. 제품 능력을 이해하려면 만들기 페이지나 이 글의 확인 단계로 돌아가세요.
키를 프래그먼트에 두는 것은 「서버 로그와 요청 라인」이라는 층을 다루는 일입니다. 「전체 링크를 누구에게 보냈는가」는 해결하지 않습니다. 채팅, 메일, 티켓 시스템은 붙여 넣은 전체 주소를 저장합니다. 전체 링크를 가진 사람은 번호와 키를 함께 가집니다. 일회용 링크가 제한하는 것은 서버 측 암호문 수명과 읽기 횟수이며, 수신자가 스크린샷을 찍거나 전달하는지는 아닙니다.
쿼리 매개변수 방식과 무엇이 다른가
어떤 일회 링크는 복호화 재료를 ?k=로 씁니다. 구현은 쉽지만, 열 때마다 키가 요청 라인에 쓰이며, CDN, WAF, 오리진 접속 로그가 사본을 남길 수 있습니다. 프래그먼트 방식은 # 하나를 더 쓰는 대신, 호스팅 측이 URL을 통째로 기록해도 암호문을 여는 절반이 빠집니다. 대가는 수신자에게 전체 링크를 복사하라고 알려야 한다는 점입니다. 물음표 앞만 복사하면 안 됩니다. # 뒤가 없으면 읽기 페이지는 암호문만 받고, 이 기기에서 열 수 없습니다.
그래서 이 글은 일회용 링크를 「비밀번호 관리자」나 「되찾을 수 있는 금고」로 쓰지 않습니다. UsePwd에는 계정이 없고, 비밀번호 보관함도 없으며, 사용자별로 비밀번호를 되찾을 수도 없습니다. 링크를 잃거나, 프래그먼트가 잘리거나, 횟수를 다 쓰면, 서버는 평문을 대신 복원할 수 없습니다. 정체 설명은 소개를 보세요.
프래그먼트 키를 「신뢰하는 서버만 복호화할 수 있다」로 이해하지 마세요. 사실은 정반대입니다. 서버에는 이 키가 없고, 대신 복호화할 수도 없습니다. 복호화할 수 있는 것은 전체 링크를 연 어떤 브라우저 탭이든입니다. 신뢰 경계는 「누가 전체 주소를 가졌는가」이지, 「어느 서버가 더 믿을 만한가」가 아닙니다.
프래그먼트가 막지 못하는 몇 가지
「서버 로그에 안 들어간다」를 「절대 안전하다」로 읽으면, 마찬가지로 확인할 수 있는 경계를 몇 개 빠뜨리게 됩니다. 먼저 적어 두어, 원리 글을 보증서로 오해하지 않게 합니다.
# 앞의 URL만 요청하지만, 사람에게 보낸 메시지에는 전체 키가 그대로 있습니다.
일회용 링크에 맞는 것은, 보내는 통로를 신뢰하고 보고 나면 끝내는 일회 전달입니다. 임시 비밀번호, 일회용 API Key, 짧은 인증 코드입니다. 장기 금고로 쓰지 말고, 가치가 큰 마스터 키를 대면 전달하는 일을 대신하게 하지도 마세요.
파일 백업은 다른 경로입니다. 파일당 최대 5 GB의 로컬 암·복호화는 파일 암호화로 갑니다. AES-256-GCM은 현재 탭에서 이루어지고, .lock / .enc를 출력하며, 파일은 기본적으로 업로드되지 않습니다. 그것은 「암호문 파일을 직접 남겨 두는 것」이지, 「키를 URL에 넣는 것」이 아닙니다. 두 도구를 같은 보장으로 섞어 쓰지 마세요.
전달할 때 채널을 고르는 법
짧은 비밀을 다른 사람에게 넘겨야 하고, 호스팅 측 접속 로그에 그것을 열 재료가 남기를 원하지 않을 때입니다. 어느 사이트 슬로건이 더 큰지부터 묻지 말고, 아래 순서로 판단하세요.
비밀을 제한된 횟수만 읽으면 되고, 양쪽 모두 브라우저를 열 수 있다면 일회용 링크를 쓰세요. 평문은 이 기기에서 암호화하고, 번호는 ?id=, 키는 #이며, 가입 없이 바로 사용합니다. 만든 뒤 네트워크 패널로 한 번 대조해, POST 본문이 암호문이고 GET의 URL에 프래그먼트가 없는지 확인하세요. 실제로 필요한 것이 장기 보관, 여러 기기 동기화, 복구라면 이미 이 사이트의 범위를 넘습니다. 전용 비밀번호 관리자를 쓰고, UsePwd를 계정 시스템으로 이해하지 마세요.
비밀이 어떤 제3자 페이지에도 들어가면 안 된다면, 링크를 만들지 마세요. 직접 말로 전하거나, 오프라인 매체, 또는 양쪽이 이미 가진 종단 간 통로에서만 전하세요. 프래그먼트 방식이 줄이는 것은 「서버 로그 안의 키」이지, 「화면을 볼 수 있는 세상 모든 사람」이 아닙니다. 이 두 층을 구분해야, URL 원리 글을 제품 보증으로 읽지 않습니다.
비밀번호 자체 강도는 다른 문제입니다. 6–128자 무작위 비밀번호는 비밀번호 생성기로 만들고, 이 기기에서 강도를 보며 페이지와 함께 제공되는 약한 비밀번호 공개 목록과 대조하려면 비밀번호 강도 검사를 쓰세요. 검사는 전역 유출 조회가 아니며, 검사할 비밀번호는 업로드되지 않습니다. 링크나 티켓 본문을 외부로 보내기 전에는 URL 클리너로 추적 파라미터를 제거하거나 마스킹하세요. 이 페이지들도 이 글과 같이 가입 없이 바로 사용하며, 상단 바 오른쪽에는 언어 전환만 있습니다.
읽고 나서 그 자리 확인
글은 「로그에 # 뒤 구간이 없는 이유」를 답합니다. 삭제되는 암호화 링크를 만들려면 일회용 링크를 열면 되며, 먼저 가입할 필요 없습니다.