비밀번호를 없애는 일이 왜 이렇게 오래 걸렸을까 로그인 폼에 아이디와 비밀번호를 입력하는 방식은 인터넷 초기부터 지금까지 거의 변하지 않았습니다. 그동안 우리 프론트엔드 개발자들은 비밀번호 강도 검사, 2단계 인증, CAPTCHA, 로그인 시도 제한 같은 방어막을 겹겹이 쌓아 왔지만, 근본 원인인 "사용자가 매번 같은 비밀 문자열을 타이핑해서 서버에 전송한
카테고리
Security
총 6편의 글
웹 보안, 인증, 토큰, 공급망 공격, LLM 보안처럼 실제 서비스 침해로 이어질 수 있는 위험을 방어 관점에서 설명합니다.
- 적용 대상
- 보안 요구사항을 제품 코드와 인프라에 반영해야 하는 개발자
- 주요 초점
- 위협 모델방어 설정검증 체크리스트
퍼블릭 클라이언트는 비밀이 없다, 그래서 흐름 자체가 방어선이어야 한다 OAuth 2.0을 처음 도입할 때 구현 담당 팀은 단일 페이지 애플리케이션에 Implicit Flow를 적용했습니다.
CORS 오설정은 조용하게, 치명적으로 침투한다 CORS(Cross-Origin Resource Sharing)는 처음 마주치는 순간 대부분 개발자에게 "브라우저가 왜 요청을 막는 거지?"라는 짜증으로 다가옵니다. 그래서 가장 빠른 해결책인 Access-Control-Allow-Origin: 를 붙이고 문제를 덮어버립니다.
CDN이 신뢰할 수 없게 된 날: 공급망 공격은 이미 우리 곁에 있다 웹 서비스는 오래전부터 외부 CDN에서 jQuery, Bootstrap, Google Analytics를 불러왔습니다. 빠르고 편리했기 때문입니다. 하지만 UI 개발 현장에서는 그 편리함 뒤에 있는 위험을 진지하게 마주한 것은 2024년 Polyfill.io 사건 이후였습니다.
JWT는 편리하지만, 그 편리함이 정확히 공격 지점이 된다 JWT(JSON Web Token)는 2010년대 중반 이후 웹 서비스 인증 표준으로 자리 잡았습니다. 서버가 상태를 저장하지 않아도 되고, 마이크로서비스 사이에서 검증이 간단하며, 다양한 언어와 플랫폼에서 라이브러리가 풍부합니다. 하지만 "편리하다"는 인식이 정확히 보안 취약점의 시작점이 됩니다.
로그인은 토큰을 저장하는 문제가 아니다 웹 애플리케이션에서 인증은 자주 단순화됩니다. access token을 어디에 저장할지, localStorage가 편한지, cookie가 안전한지 같은 질문으로 시작합니다. 하지만 실제 보안은 저장 위치 하나로 결정되지 않습니다.