[Next.js] Next.js로 HttpOnly 쿠키 + BFF(프록시) 아키텍처로 인증 보안/성능 잡기(번외편) - 쿠키 라이브러리 대신 BFF 아키텍처를 택한 이유

쿠키 라이브러리 대신 BFF 아키텍처를 택한 이유 이미지

 

 

이전에 올린 글에서 Next.js BFF(Backend For Frontend, 프록시) 아키텍처를 적용해, HttpOnly 쿠키 기반 인증으로 보안과 성능을 개선하는 과정을 소개했습니다.

그런데 프록시 구조를 도입하기 전, 이런 의문이 들었습니다.

“굳이 프록시까지 쓰지 않고, 쿠키 라이브러리 + 인터셉터 구조로 해결할 수 있지 않을까?”

 

실제로 이전의 프로젝트에서 react-cookie + Axios 인터셉터 조합으로 인증을 구현한 적이 있었고, 작은 규모의 프로젝트에서 이 방식이 꽤 단순하고 빠르게 적용할 수 있어서 나쁘지 않았습니다.

 

하지만, 쿠키 라이브러리만으로는 HttpOnly 쿠키의 보안 장점을 살릴 수 없었습니다.

이 글에서는 그 이유와 함께 각 방식을 자세히 비교해 보겠습니다.

 

 

 

---

 

대부분의 프론트엔드 쿠키 라이브러리는 사실상 HttpOnly 쿠키를 다룰 수 없다!

 

HttpOnly 쿠키는 브라우저 JS에서 접근 불가

• 이건 브라우저의 보안 정책(Web Standard)이라, 어떤 JS 라이브러리든 뚫을 수 없습니다.
• react-cookie, next-cookie, universal-cookie, js-cookie 전부 공통적으로 HttpOnly 쿠키를 읽거나 쓸 수 없습니다.

 

정리하면, 쿠키 라이브러리는 사실상 non-HttpOnly 쿠키(=JS 접근 가능한 쿠키)를 다루는 도구일 뿐입니다. 

 

 

---

 

 

! 여기서 잠시 주요 쿠키 라이브러리별 제약사항을 살펴보겠습니다. 중요한 내용은 아니니 결론만 보고 넘어가도 상관없습니다.

✔️ 주요 쿠키 라이브러리별 제약사항

1. react-cookie

import { useCookies } from 'react-cookie';

function MyComponent() {
  const [cookies, setCookie] = useCookies(['token']);
  
  // ❌ HttpOnly 쿠키는 읽을 수 없음
  console.log(cookies.token); // undefined (HttpOnly인 경우)
  
  // ❌ HttpOnly 쿠키는 설정할 수 없음 (클라이언트에서)
  setCookie('token', 'value', { httpOnly: true }); // 무시됨
}

• 클라이언트에서 document.cookie를 감싸는 래퍼
• SSR에서는 req.headers.cookie를 파싱하는 보조 유틸 정도

2. next-cookie / cookies-next

import { getCookie, setCookie } from 'cookies-next';

// ❌ HttpOnly 쿠키 읽기 불가능
const token = getCookie('httponly-token'); // undefined

// ❌ 클라이언트에서 HttpOnly 쿠키 설정 불가능
setCookie('token', 'value', { httpOnly: true }); // 브라우저에서 무시

• Next.js의 SSR/서버 컴포넌트에서 쿠키를 편하게 읽고 쓰는 용도.
• 서버 코드에서는 NextResponse.cookies.set()로 HttpOnly 가능
• 하지만 클라이언트 JS에서는 역시 불가

3. js-cookie / universal-cookie

import Cookies from 'js-cookie';

// ❌ HttpOnly 쿠키 접근 불가능
Cookies.get('httponly-token'); // undefined

// ❌ HttpOnly 옵션 자체가 지원되지 않음
Cookies.set('token', 'value'); // 항상 non-HttpOnly

• 순수 클라이언트 쿠키 라이브러리.
• 역시 HttpOnly 쿠키는 다룰 수 없음.

 

---

 

✅  결론적으로 쿠키 라이브러리는

next-cookie, react-cookie도 HttpOnly 쿠키 자체를 JS에서 제어할 수는 없습니다.

HttpOnly 쿠키는 서버(Set-Cookie 헤더)에서만 제어 가능합니다.

쿠키 라이브러리는 어디까지나 non-HttpOnly 쿠키용 편의 기능이라고 보면 됩니다.

 

 

 

---

 

 

🔐 쿠키 인증 방식 Trade-off 비교

1. 쿠키 라이브러리 + 인터셉터 방식

// Axios 인터셉터 예시
import { getCookie } from 'cookies-next';
import axios from 'axios';

axios.interceptors.request.use((config) => {
  const token = getCookie('token'); // ⚠️ non-HttpOnly만 가능
  if (token) {
    config.headers.Authorization = `Bearer ${token}`;
  }
  return config;
});

 

2. BFF(프록시) + HttpOnly 쿠키 방식

// Next.js API Route
export async function POST(request) {
  // ✅ HttpOnly 쿠키에서 토큰 읽기
  const token = request.cookies.get('auth-token')?.value;
  
  if (!token) {
    return NextResponse.json({ error: 'Unauthorized' }, { status: 401 });
  }
  
  // ✅ 백엔드에 인증된 요청 전달
  const response = await fetch('https://api.example.com/data', {
    headers: {
      'Authorization': `Bearer ${token}`,
      'Content-Type': 'application/json'
    }
  });
  
  return NextResponse.json(await response.json());
}

 

구분	쿠키 라이브러리 + 인터셉터 방식	BFF(프록시) + HttpOnly 쿠키 방식
보안	❌ HttpOnly 불가 → XSS 취약 ❌ 토큰이 JS 런타임에 노출 ⚠️ CSRF 방어 따로 필요	✅ HttpOnly 쿠키 사용 가능 ✅ 토큰 JS 접근 불가 → XSS 방어 ✅ CSRF 토큰 검증을 서버에서 통합 관리
편의성 (개발 난이도)	✅ 구현 간단 ✅ 빠른 개발/프로토타입 적합 ✅ 라이브러리(document.cookie) 기반	❌ 프록시 서버 필요 ❌ 코드 구조 복잡 ❌ 초기 개발 비용 ↑
확장성 (장기적 운영)	❌ 보안 문제로 대규모 서비스에 부적합 ❌ API Gateway 역할 불가능	✅ 보안 확장성 높음 ✅ 로깅/레이트리밋/A/B 테스트 등 제어 가능 ✅ 실서비스 표준 패턴

 

---

 

 

✅ 정리

쿠키 라이브러리 => 간단하지만 HttpOnly 쿠키를 못 쓰므로 XSS 취약합니다.
프록시 방식 => 코드가 좀 복잡해지지만, 보안 업계 표준이며 장기적으로는 확장성도 좋습니다.

 

 

 

---

 

 

 

이번 글에서는 “혹시 쿠키 라이브러리로 보안 문제를 간단히 해결할 수 있지 않을까?”라는 의문에서 시작해, 직접 시도해 본 결과를 정리했습니다.

결론은 단순합니다.
쿠키 라이브러리는 결국 non-HttpOnly 쿠키만 다룰 수 있고, 보안 취약점을 피할 수 없습니다.
저 역시 이전 프로젝트에서는 react-cookie + 인터셉터 구조를 활용했지만, 곧 보안상의 한계를 체감하게 되었고, 이번에는 보다 안전한 구조인 BFF(프록시) + HttpOnly 쿠키 아키텍처로 발전시켜 개발하게 되었습니다.

앞으로는 이 경험을 토대로 더욱 안정적이고 확장성 있는 인증/보안 아키텍처를 설계할 수 있을 것 같습니다.