JWT (JSON Web Token)

JWT는 사용자 정보를 JSON 형태로 담아 서명한 토큰이다.

즉 서버가 세션 저장소를 직접 조회하지 않아도, 토큰 자체만으로 인증을 처리할 수 있다.

처음엔 여기서 꽤 신기했다.

"서버에 로그인 상태를 안 저장한다고?"

세션 기반 인증만 보다가 JWT를 보면 처음엔 꽤 낯설다.

JWT 구조

JWT는 크게 3부분으로 구성된다.

Header.Payload.Signature

실제로 보면 이런 형태다.

xxxxx.yyyyy.zzzzz

Header

토큰 타입과 알고리즘 정보가 들어간다.

{
  "alg": "HS256",
  "typ": "JWT"
}

예를 들어

HS256
RS256

같은 서명 알고리즘 정보가 들어간다.

Payload

실제 데이터가 들어가는 영역이다.

{
  "userId": 1,
  "role": "admin"
}

보통

사용자 ID
권한
만료시간(exp)

같은 정보를 담는다.

처음엔 JWT가 암호화된 줄 알았다

이 부분에서 가장 많이 착각했다.

처음엔

토큰이 엄청 길고 복잡하니까 암호화겠지?

라고 생각했다.

근데 실제론 대부분 Base64 인코딩 이다.

즉 누구나 디코딩 가능하다.

실제로 JWT 사이트에 넣어보면 바로 보인다.

그래서 절대 넣으면 안 되는 것

비밀번호
주민번호
민감 개인정보

같은 데이터다.

Signature가 진짜 핵심

JWT의 진짜 보안 포인트는 Signature다.

서버는

Header + Payload

를 비밀키로 서명한다.

그래서 클라이언트가 Payload를 수정하면
Signature 검증이 실패한다.

"내용을 숨기는 것"

보다

"위조를 막는 것"

에 가까운 구조다.

JWT의 장점

내가 생각하는 가장 큰 장점은

토큰 자체에 인증 정보 포함

이라서 서버가 상태를 직접 저장하지 않아도 된다.

즉

서버 여러 대
모바일 앱
API 서버
MSA 환경

같은 구조에서 꽤 유리하다.

그런데 JWT를 어디에 저장할지가 진짜 문제였다

처음엔 JWT만 발급하면 끝인 줄 알았다.

근데 실제론

저장 위치가 보안의 핵심이었다.

localStorage에 하면 큰일난다

localStorage.setItem('token', jwt);

굉장히 간단하다.

그리고 요청마다

Authorization: Bearer <token>

헤더에 넣으면 끝이다.

"엄청 깔끔한 구조 아닌가?"

싶지만 아니다.

localStorage의 가장 큰 문제는 XSS였다

XSS가 발생하면 JS가 실행된다.

즉 공격자는

localStorage.getItem('token')

를 바로 실행할 수 있다.

그 순간 JWT 탈취 가능. 계정탈취까지 이어질 수 있다.

그래서 HttpOnly Cookie가 등장한다.

HttpOnly Cookie는 JavaScript에서 접근할 수 없는 쿠키다.

Set-Cookie: token=abc123; HttpOnly;

이렇게 설정하면

document.cookie

로 읽을 수 없다.

즉 XSS가 발생해도
JS로 쿠키를 직접 탈취하기 어렵다.

처음엔 HttpOnly Cookie가 완벽한 해결책처럼 보였다

XSS 막아주고,
브라우저가 자동으로 쿠키도 보내준다.

처음엔:

"그럼 그냥 무조건 HttpOnly 쓰면 되는 거 아닌가?"

싶었다.

근데 여기서 또 다른 문제가 등장했다.

쿠키는 “자동으로” 전송된다

브라우저는 같은 사이트 요청이면
쿠키를 자동 포함한다.

이건 엄청 편리하다.

근데 공격자 입장에서도 편리하다.

결국 CSRF 문제가 다시 등장한다

예를 들어 사용자가 로그인 상태라고 하자.

공격 사이트가

<img src="https://bank.com/transfer?money=1000000">

같은 요청을 보내면,
브라우저는 자동으로 쿠키를 포함할 수 있다.

즉 서버 입장에서는

"로그인된 사용자의 정상 요청"

처럼 보인다.

그래서 실제론 JWT + HttpOnly Cookie만으로 끝나지 않는다

중요한 건 조합이었다.

보통 같이 사용하는 건

SameSite 쿠키
CSRF 토큰
Secure 쿠키
HTTPS

같은 것들이다.

특히 SameSite가 꽤 중요했다.

Set-Cookie: token=abc123;
HttpOnly;
Secure;
SameSite=Lax;

이렇게 설정하면
다른 사이트에서 발생한 요청엔 쿠키 전송이 제한된다.

내 생각

처음 보안을 공부할 땐 솔직히 조금 추상적으로 느껴졌다.

XSS
CSRF
SQL Injection

같은 것들이

"이론적으로 위험한 공격"

처럼 보였다.

근데 프로젝트를 실제 서버에 배포하고,
Datadog 같은 모니터링 툴로 로그를 보기 시작하면서 생각이 완전히 바뀌었다.

인터넷에 서버를 공개하는 순간 공격은 자동으로 들어온다

예를 들면

' OR 1=1 --
UNION SELECT ...
<script>alert(1)</script>
../../etc/passwd
/wp-admin
/phpmyadmin

같은 요청들이 생각보다 엄청 자주 들어온다.

대부분 자동화 봇이었다.

인터넷 전체를 스캔하면서

SQL Injection
XSS
취약한 관리자 페이지
오래된 CMS
노출된 API

같은 걸 계속 탐색한다.

예전엔

"보안은 중요한 서비스만 신경 쓰는 것"

처럼 느껴졌다.

근데 실제 로그를 보면 생각이 달라진다.

인터넷에 서버를 공개하는 순간

누군가는 계속 요청을 보내고 있다

그것도 사람이 아니라 자동화된 봇이 24시간 계속 시도한다.

이걸 직접 보고 나니까

입력 검증
ORM 사용
parameterized query
CSP
HttpOnly Cookie
SameSite
rate limiting

같은 것들이 갑자기 “이론”이 아니라 현실적인 방어처럼 느껴졌다.

그래서 지금은 보안을 “옵션”처럼 보지 않게 됐다

예전엔

"나중에 보안 강화하면 되지"

처럼 생각했던 적도 있었다.

근데 실제 트래픽과 공격 로그를 보고 나서는 생각이 꽤 달라졌다.

특히 느낀 건

보안은 공격받을 때 준비하는 게 아니라,
공개하는 순간부터 기본값이어야 한다

는 점이었다.

그래서 지금은

ORM 사용
입력 sanitizing
HttpOnly Cookie
CSRF 방어
rate limit
env 분리

같은 걸 초반부터 구조에 넣으려고 하는 편이다.

실제로 인터넷은 생각보다 훨씬 시끄러운 공간이었다.

jwt, httpOnly Cookie