보안 저장소에 절대 저장하면 안 되는 것

localStorage와 sessionStorage는 사용자 프로필의 디스크에 암호화되지 않은 상태로 데이터를 저장합니다. 악성 코드, 백업 도구 또는 로그인한 다른 사용자를 비롯해 파일 시스템에 접근할 수 있는 모든 프로세스가 브라우저를 거치지 않고 저장한 모든 값을 읽을 수 있습니다.

해당 출처에서 실행되는 모든 스크립트는 동일한 Storage를 공유합니다. 성공적인 XSS 공격, 침해된 제3자 SDK 또는 악성 브라우저 확장 프로그램은 localStorage.getItem을 호출하여 저장된 모든 값을 외부로 빼낼 수 있습니다. 스크립트별 격리는 제공되지 않습니다.

세션 토큰, JWT, 갱신 토큰 또는 API 키를 localStorage에 넣지 마십시오. 공격자가 JavaScript 한 줄만 삽입해도 토큰이 즉시 유출됩니다. 토큰이 JavaScript에서 접근되지 않도록 httpOnly, Secure, SameSite 쿠키를 사용하십시오.

비밀번호를 평문, 해시 또는 암호화된 형태로 저장하는 것은 클라이언트에서 어떤 경우에도 잘못된 방식입니다. 공격자가 해시를 읽고 재사용할 수 있으므로 클라이언트 측에서 해시해도 도움이 되지 않습니다. 비밀번호 처리는 전적으로 서버에서 bcrypt와 같은 전용 비밀번호 해시를 사용해 수행해야 합니다.

PCI-DSS는 클라이언트 저장소에 카드 번호, 카드 보안 코드 또는 마그네틱 스트라이프 데이터나 만료일을 저장하는 것을 금지합니다. 대신 토큰화된 결제 제공업체(Stripe, Braintree, Adyen)를 사용하십시오. 이 제공업체는 사용자의 출처에 연결된 짧은 수명의 토큰을 반환합니다.

정부 발급 신분증 정보, 전체 생년월일, 자택 주소 및 의료 데이터는 규제 기관(GDPR, HIPAA)과 공격자의 표적이 됩니다. 현재 세션에 필요한 정보만 저장하고, 필요할 때 다시 요청하며, 서버가 원본 데이터의 기준을 유지하도록 하십시오.

document.cookie를 유출하는 XSS 버그는 심각한 문제입니다. 토큰을 localStorage에 저장하는 페이지에서 같은 버그가 발생하면 공격자는 저장된 모든 값을 한 번에 탈취할 수 있습니다. localStorage를 "스크립트 하나를 침해하면 모든 것을 침해한 것과 같은" 공격 표면으로 취급하십시오.

JavaScript에도 존재하는 키로 값을 암호화하면 실질적인 보호가 되지 않습니다. 암호문을 읽을 수 있는 공격자는 키도 읽을 수 있기 때문입니다. 실제 비밀 정보는 서버 측에 보관하고, 클라이언트 측에는 절대 영구 저장하지 말고 다시 발급해야 합니다.

사용자 인터페이스 설정(테마, 사이드바 접힘 여부, 언어), 민감하지 않은 기능 플래그, 양식 초안 내용 및 일시적인 단계형 화면 상태는 모두 저장해도 괜찮습니다. 이러한 정보는 어차피 사용자에게 표시되며, 유출되어도 계정 탈취로 이어지지 않습니다.

Set-Cookie: token=...; HttpOnly; Secure; SameSite=Strict를 통해 인증을 발급하십시오. HttpOnly 플래그를 사용하면 JavaScript에서 쿠키에 접근할 수 없으므로, 페이지에 다른 버그가 있더라도 대부분의 토큰 탈취 XSS 공격 코드를 무력화할 수 있습니다.

민감해 보이는 데이터를 반드시 캐시해야 한다면 범위를 엄격히 제한하십시오(짧은 TTL을 사용하고, 로그아웃 시 삭제하며, 탭을 닫을 때 sessionStorage를 통해 remove를 적용). 삽입된 스크립트를 차단하도록 엄격한 콘텐츠 보안 정책을 적용하고, 인증된 페이지에서 실행되는 모든 제3자 스크립트를 감사하십시오.

인증 토큰을 localStorage에 저장하는 것이 왜 보안 위험으로 간주됩니까?

웹 저장소는 평문으로 저장되고, 스크립트가 읽을 수 있으며, 출처별로 공유됩니다. 인증 토큰, 비밀번호, 결제 데이터 또는 규제를 받는 개인 정보를 절대 저장하지 마십시오. 비밀 정보는 httpOnly 쿠키에 보관하고, 사용자가 어차피 볼 수 있는 무해한 사용자 인터페이스 상태만 localStorage에 저장하십시오.