"다시 한다면 어떻게 할까" — 인증 아키텍처 회고와 개선안

한 줄 요약

CSP는 브라우저한테 “이 페이지에선 이 출처의 스크립트만 실행해. 그 외는 무시”라고 미리 약속하는 허용 목록입니다. 공격자가 페이지에 악성 스크립트를 몰래 심어도, 출처가 허용 목록에 없으면 브라우저가 그냥 실행을 거부합니다.

XSS와의 관계

2편에서 본 시나리오의 공통 원인은 결국 XSS(공격자가 우리 사이트에 악성 JavaScript를 몰래 심는 공격)가 실제로 실행되는 것이었습니다. HttpOnly·SameSite 같은 방어책은 “XSS가 일단 뚫린 뒤” 피해를 줄여주는 것뿐이고, XSS 자체를 막아주진 않습니다. CSP는 그 한 단계 앞에서, 악성 스크립트의 실행 자체를 거부합니다. React 같은 프레임워크도 부분적으로 도와주지만 외부 라이브러리나 우회 패턴까지는 못 막아서, 브라우저가 끝에서 한 번 더 걸러주는 CSP가 따로 필요합니다.

어떻게 생겼나

HTML 페이지를 만들어서 브라우저로 내려보내는 서버(이 프로젝트라면 Next.js, 전통적인 구조라면 Express·Spring 같은 백엔드, 정적 사이트라면 nginx 같은 웹 서버)가 그 HTML 응답을 보낼 때 응답 헤더 자리에 한 줄을 같이 박아 보냅니다:

1
Content-Security-Policy: script-src 'self' https://my-cdn.com

왜 “1일차부터”인가

나중에 도입하려면 그동안 쌓인 코드 중 규칙 위반이 너무 많아 정리만 한 달이 갈 수 있습니다. 처음부터 켜두면 새 코드가 자연스럽게 규칙을 따르니까 정리할 게 없어요.

도입 3단계

운영에 영향 주지 않으면서 안전하게 켜는 표준 순서가 있습니다:

1. 신고만 받는 모드부터 시작 — 위반이 발생해도 차단은 안 하고 “이런 위반이 있었다”는 신고만 서버에 보냄. 운영 영향 0인 채로 “지금 켜면 뭐가 걸릴지” 파악
2. 신고 0건 만들기 — 신고 들어오는 부분(주로 페이지에 직접 박힌 <script>...</script> 같은 인라인 코드)을 하나씩 손봐서 허용 목록에 등록. 등록 방법은 nonce(요청마다 일회용 허가증)와 hash(스크립트 지문값) 두 가지가 있고, 콘솔의 위반 메시지가 “어떤 값을 허용해야 하는지” 정답을 그대로 알려주므로 그걸 보고 채워가면 됩니다
3. 실제 차단으로 전환 — 다음에 볼 코드처럼, 헤더 이름만 살짝 바꾸면 끝

세 단계 모두 결국 응답 헤더의 이름과 값만 바꾸는 일입니다. Next.js라면 next.config.js의 headers() 한 곳에서 정리돼요:

1
async headers() {
2
  return [{
3
    // 이 헤더 규칙을 적용할 URL 패턴 (정규식).
4
    // /(.*)는 "사이트 전체". 페이지별로 다른 정책을 두려면 source 블록을 여러 개로 분리
5
    // (예: { source: '/admin/(.*)', headers: [...엄격...] }, { source: '/(.*)', headers: [...일반...] })
6
    source: '/(.*)',
7
    headers: [
8
      // 1단계 — 보고만 받기 (운영 영향 0)
9
      { key: 'Content-Security-Policy-Report-Only',
10
        value: "script-src 'self'; report-uri /api/csp-report" },
11

12
      // 3단계 — 헤더 이름에서 -Report-Only만 떼면 실제 차단 (1단계와 둘 중 하나만)
13
      { key: 'Content-Security-Policy',
14
        value: "script-src 'self' 'nonce-XYZ'" },
15
    ]
16
  }]
17
}

여기서 source: '/(.*)'는 이 헤더를 붙일 URL 범위(정규식 — (.*)는 모든 경로, 즉 사이트 전체)이고, 실제 CSP 허용 출처 목록은 value 안의 script-src 뒤 부분('self', https://my-cdn.com 등)에 들어갑니다. 외부 CDN을 추가하고 싶으면 손대는 곳은 value이고 source는 그대로 둡니다.

자세한 코드 패턴은 Next.js 공식 CSP 가이드에 거의 그대로 나와 있습니다.

처음부터 1단계라도 켜두지 않으면 “정리하기 부담스럽다”는 이유로 도입이 무기한 미뤄지기 쉽습니다. 시작 시점에 켜는 비용이 가장 쌉니다.

4-1. Path 제한 — “이 쿠키, 어디까지 따라가게 할 거야?”

쿠키의 Path 속성은 이 쿠키가 어떤 URL 경로의 요청에 자동 첨부될지를 정합니다. Path=/로 두면 같은 도메인의 모든 경로에서 자동 전송됩니다.

1
Set-Cookie: refresh_token=eyJxxx...; Path=/api/auth; HttpOnly; Secure; SameSite=Lax; Max-Age=604800

1
// Spring Boot
2
ResponseCookie.from("refresh_token", token)
3
  .path("/api/auth")            // ← 이게 핵심
4
  .httpOnly(true).secure(true).sameSite("Lax")
5
  .maxAge(Duration.ofDays(7))
6
  .build();

1
// Express / Node
2
res.cookie('refresh_token', token, {
3
  path: '/api/auth',            // ← 이게 핵심
4
  httpOnly: true, secure: true, sameSite: 'lax',
5
  maxAge: 7 * 24 * 60 * 60 * 1000,
6
})

1
# FastAPI (Flask·Django도 set_cookie 시그니처가 거의 동일)
2
response.set_cookie(
3
    key="refresh_token",
4
    value=token,
5
    path="/api/auth",           # ← 이게 핵심
6
    httponly=True, secure=True, samesite="lax",
7
    max_age=60 * 60 * 24 * 7,
8
)

1
브라우저 쿠키 저장소:
2
  refresh_token (Path=/, HttpOnly, Secure, SameSite=Lax)
3

4
→ GET /api/users          : 쿠키 자동 첨부 ✗ 사실은 필요 없음
5
→ POST /api/orders        : 쿠키 자동 첨부 ✗ 사실은 필요 없음
6
→ GET /dashboard          : 쿠키 자동 첨부 ✗ 사실은 필요 없음
7
→ POST /api/auth/refresh  : 쿠키 자동 첨부 ✓ 진짜로 필요
8
→ POST /api/auth/logout   : 쿠키 자동 첨부 ✓ 진짜로 필요

1
브라우저 쿠키 저장소:
2
  refresh_token (Path=/api/auth, HttpOnly, Secure, SameSite=Lax)
3

4
→ GET /api/users          : 쿠키 미전송 (Path 매치 안 함)
5
→ POST /api/orders        : 쿠키 미전송
6
→ GET /dashboard          : 쿠키 미전송
7
→ POST /api/auth/refresh  : 쿠키 전송 ✓
8
→ POST /api/auth/logout   : 쿠키 전송 ✓

4-2. __Host- prefix — 이름만 바꿔도 브라우저가 안전장치를 강제한다

Set-Cookie 헤더에서 쿠키 이름이 __Host-로 시작하면, 브라우저는 그 쿠키를 받기 전에 다음 세 가지가 모두 만족되는지 검사합니다. 하나라도 어긋나면 쿠키 자체를 거부합니다.

이름만 refresh_token → __Host-refresh_token으로 바꾸는 거라 코드 변경량은 작지만, 보호 효과는 큽니다. 특히 세 번째 조건이 핵심입니다.

1
admin.example.com : 사용자가 로그인된 관리자 도구
2
blog.example.com  : 마케팅 팀이 운영하는 워드프레스 (XSS 사고 빈번)
3

4
[기존: Domain=.example.com인 쿠키]
5
blog 측 XSS 스크립트가 fetch('https://admin.example.com/api/auth/refresh') 호출
6
→ 브라우저: "같은 example.com이니까" 쿠키 자동 첨부
7
→ admin 측 토큰이 갱신되어 공격자가 새 accessToken 획득
8

9
[__Host-refresh_token으로 바꾸면]
10
Domain 속성 자체가 금지되어 쿠키는 admin.example.com에만 묶임
11
→ blog 측에서 같은 fetch를 호출해도 쿠키 미첨부
12
→ 공격 차단

4-3. 그래서 다시 한다면 무엇을 고를까

위 두 가지는 양자택일입니다 (__Host-는 Path=/를 강제하니까). 무엇을 막을지에 따라 선택이 갈립니다:

이 프로젝트는 단일 도메인이라 다시 한다면 후자(Path=/api/auth)로 갔을 겁니다. 다만 향후 admin.*, analytics.* 같은 서브도메인 확장 가능성이 보이면 그 시점에 __Host-로 전환을 검토하는 식으로요.

5-1. 최소 로깅 — 어떤 프로젝트든 기본

• 로그인 성공/실패 이벤트
• 401 응답 카운트
• 자동 refresh 시도·실패율 (프론트 측 Sentry 등)

이 정도는 프레임워크 기본 로그 + Sentry 같은 도구를 깔면 거의 따라오는 비용입니다. 이 프로젝트도 1일차부터 잡았어야 했고, “도입”이라 부르기도 애매한 수준입니다.

5-2. 상세 로깅 — 사고 났을 때 피해가 큰 서비스에서만

• 사용자별 refresh 호출 빈도 — 사용자마다 최근 짧은 시간(예: 5분·1시간) 동안 refresh를 몇 번 호출했는지 집계. 평소보다 갑자기 훨씬 자주 호출되면 토큰 탈취 의심 신호
• 같은 사용자 토큰의 위치·기기 변화 — 같은 사용자의 토큰이 갑자기 다른 IP(접속 위치, 예: 한국 → 미국)나 다른 User-Agent(브라우저·OS 정보, 예: Chrome/Windows → Safari/iOS)에서 들어오는지 추적. 토큰이 탈취돼 공격자의 다른 기기에서 쓰이는 시나리오 감지
• 로그인 실패 패턴 — 같은 계정에 짧은 시간 안에 비밀번호 시도가 수십~수백 번 들어오는지. 비밀번호를 무차별 대입해서 맞을 때까지 시도하는 브루트포스(brute force) 공격 탐지의 기반

이건 다릅니다. 로그를 어디에 쌓을지, 어떻게 모아 볼지, 어느 수치를 넘으면 알람을 띄울지까지 다 정해야 하는 작업이고, 실제로 공격당할 가능성이 있는 서비스에서만 들인 만큼의 효과가 나옵니다 — 금융·헬스케어·결제, 또는 외부에 공개된 사용자 많은 서비스. 수십 명짜리 B2B 내부 도구에는 과투자입니다.

이런 항목들은 대부분 백엔드에서 남겨야 하는 데이터라 프론트 혼자 결정할 수 있는 영역도 아닙니다. 다시 한다면 도메인이 “상세 로깅이 필요한 쪽”이라고 판단된 시점에 백엔드 팀에 이 스키마를 함께 잡자고 발의하겠습니다. 그래야 “비정상 패턴은 무엇인지”를 정의할 수 있고, 그 위에 rate limit이나 강제 로그아웃 같은 차단 정책을 얹을 수 있습니다. 데이터 없이 감으로 임계값을 잡고 차단하면 정상 사용자만 막히는 함정에 빠집니다.

지금 Middleware가 못 하는 것

현재 Next.js Middleware는 보호 라우트 진입 시 쿠키 존재 여부만 확인합니다.

1
// 지금 구조
2
export function middleware(req) {
3
  const hasRefresh = req.cookies.get('refresh_token')
4
  if (!hasRefresh) return NextResponse.redirect('/login')
5
  return NextResponse.next()
6
}

이게 못 하는 일들:

• 유효성 검증 — 쿠키가 있긴 한데 만료된 거면? 일단 통과시킨 뒤 클라이언트가 refresh를 호출해서야 알 수 있음
• 사용자 식별 — 라우트별 redirect, A/B 분기, 로깅에 userId가 필요해도 Middleware는 모름

해결하려면 Middleware에서 백엔드에 매번 검증 요청을 보내야 하는데, 그러면 모든 페이지 진입에 백엔드 round-trip이 추가됩니다. 그래서 결국 안 했고, 그 만큼 책임이 페이지/컴포넌트 단으로 흘러 들어갔습니다.

JWT를 쓰면 무엇이 가능해지는가

accessToken을 JWT로 발급하면 Middleware가 백엔드 없이 토큰을 검증할 수 있습니다:

1
// JWT 도입 시 가능해지는 구조 (개략)
2
export async function middleware(req) {
3
  const token = req.cookies.get('access_token')?.value
4
  if (!token) return redirectTo('/login')
5

6
  const payload = await verifyJWT(token, PUBLIC_KEY)  // 서명 검증 + 만료 확인
7
  if (!payload) return redirectTo('/login')
8

9
  // payload.role, payload.userId 등을 즉시 활용
10
  if (req.nextUrl.pathname.startsWith('/admin') && payload.role !== 'admin') {
11
    return redirectTo('/forbidden')
12
  }
13
  return NextResponse.next()
14
}

얻는 것:

• 페이지 진입 단계에서 권한·만료 검증이 끝남 → 컴포넌트가 깨끗해짐
• 백엔드 round-trip 0회 → edge에서 처리되어 응답이 빠름
• payload.userId를 헤더로 백엔드에 전달하면 백엔드도 토큰 디코딩을 한 번 덜 할 수 있음

이게 정말 매력적이라, 만약 라우트별 권한 분기·SSR 개인화·B2B의 멀티 테넌시 같은 요구가 1일차부터 있는 프로젝트였다면 처음부터 JWT를 진지하게 검토했을 겁니다.

그런데 1편의 결정 근거는 아직 유효한가

JWT의 가장 큰 약점, 즉시 무효화 어려움은 그대로입니다. accessToken을 짧게(예: 15분) 두고 Refresh Token Rotation(위 3번)으로 보완하는 게 정석이지만, 이건 다음 두 가지를 받아들이는 결정이기도 합니다:

그래서 다시 한다면

“JWT로 바꾼다”가 아니라 “JWT + Middleware 조합을 1주일 정도 시간 들여 진지하게 평가한다” 가 결론입니다. 평가 기준은:

• /admin, /user/profile 같은 페이지마다 인가(누가 이 페이지를 볼 수 있는지 권한 체크) 코드가 각 페이지 안에 흩어져 있는가 (그렇다면 Middleware 한 곳에서 처리하는 게 훨씬 깔끔)
• 서버에서 HTML을 미리 만들어 보낼 때 “이 사용자가 누구인지”를 그 시점에 알아야 하는 화면이 있는가 (예: “안녕하세요 ○○님” 같은 개인화, 사용자 그룹별로 다른 UI 보여주기, 누가 이 페이지에 들어왔는지 서버에서 기록)
• 사용자가 로그아웃을 눌렀거나 관리자가 계정을 정지시켰을 때, 그 즉시 차단되지 않고 최대 15분까지 그대로 살아있는 상황을 받아들일 수 있는 서비스인가 (JWT는 토큰 자체가 만료될 때까지 유효해서, accessToken을 15분짜리로 두면 그 동안은 무효화가 안 됨. 금융·헬스케어처럼 1초라도 늦으면 안 되는 도메인은 부적합)
• 비밀 키를 안전하게 보관·교체·배포할 인프라(AWS KMS 등)가 이미 있거나, 새로 도입할 의향이 있는가

체크박스가 두 개 이상 켜지면 JWT를 도입하느라 드는 비용(키 관리·15분 지연 감수 등) 대비 얻는 이득이 보입니다. 모두 꺼지면 지금 구조(세션 토큰 + HttpOnly 쿠키)가 여전히 정답입니다.