Base64은 비밀을 제공하지 않습니다. 인코딩된 값을 받는 사람은 누구나 비밀번호나 키 없이 해당 바이트를 복구할 수 있습니다. 긴 문자열에 자격 증명을 숨기면 누가 읽을 수 있는지가 아닌 모양이 변경됩니다. 원본과 마찬가지로 인코딩된 비밀에도 동일한 처리 규칙을 적용합니다.
인코딩, 암호화 및 서명은 다양한 질문에 답합니다.
인코딩은 바이트가 텍스트 지향 시스템을 통해 어떻게 이동할 수 있는지 묻습니다. 암호화는 암호화 키로 기밀성을 보호합니다. 인증 태그 또는 디지털 서명은 검증 프로세스와 키가 올바른 경우 데이터가 승인된 당사자에 의해 생성되었으며 변경되지 않았음을 입증할 수 있습니다. 일반 체크섬은 주로 우발적인 손상을 감지하는 데 도움이 됩니다. 이러한 보장 중 어느 것도 Base64만으로는 나오지 않습니다.
디코딩된 JWT은 유용한 예입니다. 헤더와 페이로드는 읽을 수 있는 구조이지만 이를 읽어도 서명, 발급자, 대상 또는 만료 정책이 확인되지는 않습니다. 확인되지 않은 주장을 신뢰할 수 없는 입력으로 처리합니다. 뷰어의 형식화된 JSON이 승인 결정이 되도록 하지 마십시오.
디코딩된 콘텐츠를 비활성 상태로 유지
페이로드는 HTML, JavaScript, 활성 콘텐츠가 포함된 SVG 또는 잘못된 형식의 문서로 디코딩될 수 있습니다. 텍스트 표시 textContent, 아니 innerHTML. 디코딩된 코드를 실행하거나 페이지에 임의의 SVG을 삽입하지 마세요. 선언된 데이터 URI MIME 유형은 보낸 사람이 제공하며 false일 수 있습니다. 파일 서명은 가능한 형식을 식별하는 데 도움이 되지만 일치하는 헤더가 파일이 완전하거나 안전하다는 것을 입증하지는 않습니다.
// decodedText comes from an untrusted payload.
const output = document.createElement('pre');
output.textContent = decodedText;
document.body.append(output); // displays markup as text메모리를 할당하기 전에 제한을 설정하세요.
인코딩된 텍스트는 데이터를 확장하고 브라우저는 입력 문자열, 디코딩된 바이트 및 미리보기를 동시에 보유할 수 있습니다. 디코딩하기 전에 제한을 적용하고 허용되는 문서 유형을 제한하며 사용자가 긴 작업을 취소할 수 있도록 합니다. 잘못된 입력은 성공한 데이터인 것처럼 복사할 수 있는 출력 대신 별도의 오류 상태를 생성해야 합니다.
민감한 작업의 경우 도구의 네트워크 동작과 보존 정책을 검사하세요. 브라우저 처리와 서버 API 처리의 경계는 다릅니다. 브라우저 기록, 스크린샷 또는 액세스 로그를 입력할 수 있는 페이지 URL에 토큰을 넣지 마세요. 테스트할 때 동일한 구조의 합성 데이터를 사용하세요. RFC 4648 인코딩 모호성에 대해 논의합니다. 더 큰 프로토콜의 보안은 여전히 완전한 설계에 달려 있습니다.