URL을 공유하기 전에 확인할 것: 검색어 인코딩·접근 권한·민감한 값

공유 오류를 세 종류로 나누세요

링크가 잘못됐다는 말에는 서로 다른 문제가 섞여 있습니다. 주소는 열리지만 검색어가 잘리는 경우, 보낸 사람에게만 열리는 경우, 열리기는 하지만 공개하면 안 되는 정보가 주소에 들어 있는 경우입니다. 각각 값의 전달, 접근 권한, 공유 범위를 확인해야 합니다.

증상	먼저 볼 항목	인코딩으로 해결할 수 있는가
& 뒤 검색어가 사라짐	값 안의 기호와 쿼리 구분자	값 조립 방식이 원인이면 가능
A+B가 A B로 바뀜	폼 방식의 더하기 기호 처리	올바른 값 인코딩으로 방지 가능
받는 사람에게 로그인·권한 오류 표시	대상 계정과 공유 설정	해결되지 않음
며칠 후 링크가 열리지 않음	발급된 링크의 만료·삭제 여부	해결되지 않음
이메일·비밀번호·토큰이 주소에 보임	URL에 담긴 정보의 적절성	인코딩해도 숨겨지지 않음

문제를 구분하지 않고 주소 전체를 여러 번 인코딩하면 오히려 다른 주소가 됩니다. 원본 링크를 보관한 뒤 필요한 값 하나가 어느 단계에서 달라지는지 확인하세요.

주소의 구조와 값 하나를 구분하세요

예시 주소 https://example.com/search?q=blue&sort=recent에서 도메인과 경로는 어디에 요청하는지를, q와 sort는 전달할 항목을 나타냅니다. &는 두 항목 사이를 나눕니다. 검색어 자체에 &가 필요하다면 그것이 구분자가 아니라 값이라는 표시가 필요합니다. 이 도메인은 설명용이며 실제 검색 서비스를 제공하는 예시가 아닙니다.

Tooliv URL 도구는 encodeURIComponent로 입력 전체를 구성요소 하나처럼 변환합니다. 검색어 빨강 & 파랑을 넣으면 %EB%B9%A8%EA%B0%95%20%26%20%ED%8C%8C%EB%9E%91이 됩니다. 이를 이미 만들어 둔 q= 뒤에 넣는 것과 전체 주소를 도구에 넣는 것은 다른 작업입니다.

완성된 주소 전체를 입력하면 https://의 콜론과 슬래시, 쿼리 구분자도 변환됩니다. 이 결과는 다른 URL의 값으로 주소 자체를 전달하는 상황에는 필요할 수 있지만, 그대로 클릭할 공유 링크를 만드는 목적에는 맞지 않습니다. “무엇을 한 조각으로 전달하는가”부터 정해야 합니다.

코드로 주소를 만들 때는 원문 값을 한 번 전달하세요

브라우저 코드에서는 문자열을 직접 이어 붙이기보다 URL의 검색 매개변수를 다루는 API를 쓸 수 있습니다. 아래 코드는 새로 만든 검증 예시이며 Node의 URL API로 실행해 출력과 역변환을 확인했습니다.

const url = new URL('https://example.com/search');
url.searchParams.set('q', '빨강 & 파랑');
url.searchParams.set('tag', 'A+B');

console.log(url.searchParams.get('q'));   // 빨강 & 파랑
console.log(url.searchParams.get('tag')); // A+B

직렬화된 주소에서는 검색어의 공백이 +로, 실제 더하기 기호는 %2B로 표시됩니다. URLSearchParams 문서는 키와 값을 설정할 때 인코딩 전의 문자열을 사용한다고 설명합니다. 이 API가 인코딩을 담당하는 경우에는 Tooliv에서 미리 변환한 결과를 다시 넣지 마세요.

처리	결과	확인할 점
new URLSearchParams('tag=A+B').get('tag')	A B	쿼리 문법의 +를 공백으로 읽음
원문 A+B를 set('tag', 값)으로 설정	직렬화 시 tag=A%2BB	더하기 기호가 값으로 보존됨
A%2BB를 원문처럼 다시 설정	tag=A%252BB	이미 인코딩한 %가 다시 변환됨

공백이 %20인 주소와 +인 주소가 항상 서로 잘못된 것은 아닙니다. 값을 만드는 방식과 받는 쪽의 해석 규칙을 맞춰야 합니다. Tooliv의 디코딩은 decodeURIComponent라서 일반적인 폼 쿼리 파서처럼 +를 공백으로 바꾸지 않습니다. 이 차이를 모른 채 같은 결과를 기대하면 검수 과정에서 혼동하기 쉽습니다.

인코딩은 민감한 정보를 보호하지 않습니다

퍼센트 기호와 영문 숫자로 바뀌면 내용을 읽기 어려워 보일 수 있지만, 규칙을 알면 다시 복원할 수 있습니다. 비밀번호·인증 코드·개인정보를 인코딩했다는 이유로 공유 링크에 넣으면 안 됩니다. 주소에 넣을 값은 그 주소가 복사되고 기록되어도 되는지 먼저 판단해야 합니다.

OWASP의 쿼리 정보 노출 설명은 HTTPS만으로 URL에 담긴 민감한 값의 기록 문제를 해결할 수 없다고 안내합니다. 요청한 서버의 로그, 브라우저 방문 기록, 공유된 화면과 메시지 등 URL이 남는 위치를 고려해야 합니다.

다른 페이지로 이동할 때 쿼리가 항상 전부 전송된다고 단정할 수도 없습니다. Referrer-Policy에 따라 전달 범위가 달라집니다. 현재 기본 정책인 strict-origin-when-cross-origin은 다른 출처로 갈 때 보통 출처만 보내지만 같은 출처 요청에서는 경로와 쿼리를 포함할 수 있습니다. 이 정책이 원래 서버의 요청 기록이나 직접 복사한 URL까지 지워 주지는 않습니다.

일회용 링크나 서명된 다운로드 링크는 서비스가 의도적으로 제한된 권한을 주소에 넣어 발급할 수 있습니다. 이 경우에도 링크를 가진 사람이 무엇을 할 수 있는지, 언제 만료되는지 확인하고 해당 서비스의 공유 기능을 사용하세요. 토큰을 임의로 바꾸거나 인코딩을 풀었다 다시 조립하면 서명 검증이 실패할 수 있습니다.

값 확인 다음에는 받는 사람의 상황을 확인하세요

링크를 만든 계정에서 열린다는 사실만으로 공유가 성공한 것은 아닙니다. 공개 자료라면 로그인하지 않은 환경에서 열리는지 확인하고, 특정 사람에게만 제공하는 자료라면 의도한 계정에 권한이 부여되어 있는지 확인하세요. 검증을 위해 접근 제한을 모두 해제하는 방식은 피하고 필요한 범위에 맞춰 확인합니다.

주소에서 매개변수를 지울 때도 이유를 확인해야 합니다. 불필요한 추적 값은 서비스가 제공하는 간결한 공유 주소로 대체할 수 있지만, 어떤 값은 검색 조건·페이지 위치·접근 권한에 필요합니다. 이름만 보고 모두 지운 뒤 정상 링크라고 판단하면 안 됩니다. 원본과 정리한 링크를 각각 열어 제목·검색 결과·선택된 조건을 비교하세요.

QR에 넣을 때는 주소를 확인한 후 생성하고 다시 스캔해 목적지를 확인합니다. QR은 권한을 추가하거나 만료를 없애지 않습니다. 생성 결과의 활용은 목적에 맞는 생성 도구 선택 안내에서, 이중 인코딩이나 한글 복원 오류는 Base64·URL 인코딩 문제 구분법에서 이어 볼 수 있습니다.

공유 직전에는 원문 값이 보존됐는지, 받는 사람이 열 수 있는지, 주소 자체를 전달해도 되는지를 각각 확인하세요. 세 항목을 나눠 보면 인코딩 도구로 해결할 문제와 공유 설정에서 해결할 문제가 분명해집니다.