20개 슬라이스, 6개 레이어 — FSD 점진적 도입기

Ant Design을 걷어내고 자체 디자인시스템 만들기

<h2>들어가며</h2>
금융 백오피스의 보안 점검을 진행했다. API 보안, XSS/인젝션, 빌드 설정, 권한/인가 4개 영역을 점검한 결과, 코드 레벨의 XSS 취약점은 0건이었다. Zod 화이트리스트 검증, React 자동 이스케이프, TypeScript strict 모드가 잘 갖춰져 있었다.
빈틈은 오히려 코드 바깥에 있었다. CSP 미설정, 소스맵 노출, 보안 헤더 부재처럼 “설정하지 않아서 생긴” 취약점들이었다. 이 글에서는 점검 과정에서 발견한 핵심 이슈들과, 각각이 금융 도메인에서 왜 위험한지를 정리한다.
<hr>
<h2>1. localStorage에 토큰이 평문으로 저장되고 있었다</h2>
가장 심각한 이슈였다. accessToken과 refreshToken이 localStorage에 JSON 평문으로 저장되고 있었다.
<pre><code class="language-typescript">// Zustand persist 설정
{
 name: &#x27;app-session&#x27;,
 storage: createJSONStorage(() =&gt; localStorage),
}
</code></pre>
브라우저 개발자 도구에서 <code>localStorage.getItem('app-session')</code>을 실행하면 토큰이 바로 보인다. 만약 XSS 공격이 성공하면, 공격자는 이 토큰으로 사용자인 척 API를 호출할 수 있다.
일반 서비스에서도 위험하지만, 금융 시스템에서는 토큰 하나가 곧 금전 거래 권한이다. 관리자 토큰이 탈취되면 거래 승인, 자산 변경 같은 민감한 액션이 가능해진다.
<h3>HttpOnly 쿠키로 전환하면 해결되는가?</h3>
<pre><code class="language-javascript">// 현재 흐름
로그인 → 서버가 JSON body로 토큰 반환 → 프론트가 localStorage에 저장

// 전환 후 흐름
로그인 → 서버가 Set-Cookie 헤더로 토큰 발급 (HttpOnly) → 브라우저가 자동 관리
</code></pre>
<code>HttpOnly</code> 플래그가 붙은 쿠키는 JavaScript에서 접근이 불가능하다. XSS가 성공해도 토큰을 읽을 수 없다. 다만 이 전환은 백엔드 변경이 필수이므로, 먼저 CSP로 XSS 자체를 차단하는 방어막을 추가했다.
<blockquote>
Note: 핵심: localStorage 토큰 저장 자체가 취약한 것은 아니다. XSS가 성공했을 때 토큰이 노출된다는 것이 문제다. 그래서 XSS를 원천 차단하는 CSP와 XSS가 성공해도 토큰을 보호하는 HttpOnly 쿠키, 이 두 레이어를 함께 갖추는 것이 정답이다.
</blockquote>
<hr>
<h2>2. CSP가 없으면 XSS 방어의 마지막 보루가 없다</h2>
프로젝트에 Content Security Policy가 전혀 설정되어 있지 않았다.
CSP는 브라우저에게 “허용된 출처의 리소스만 실행해라”라고 지시하는 보안 정책이다. 설정하지 않으면 어떤 출처의 스크립트든 실행된다.
<h3>CSP가 없을 때의 공격 시나리오</h3>
<pre><code class="language-javascript">1. 공격자가 어떤 경로로든 악성 스크립트를 페이지에 삽입
2. 스크립트가 localStorage에서 토큰을 읽음
3. 토큰을 공격자의 서버(https://evil.com)로 전송
4. 공격자가 탈취한 토큰으로 거래 승인 API 호출
</code></pre>
<h3>CSP를 설정하면</h3>
<pre><code class="language-html">&lt;meta
 http-equiv=&quot;Content-Security-Policy&quot;
 content=&quot;
 default-src &#x27;self&#x27;;
 script-src &#x27;self&#x27; https://cdn.example.com;
 connect-src &#x27;self&#x27; https://api.example.com;
 frame-ancestors &#x27;none&#x27;;
 object-src &#x27;none&#x27;
 &quot;
/&gt;
</code></pre>
각 디렉티브가 하는 일:
<table>
<thead>
<tr>
<th>디렉티브</th>
<th>역할</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>script-src 'self' https://cdn.example.com</code></td>
<td>자기 자신과 허용된 CDN의 스크립트만 실행 허용</td>
</tr>
<tr>
<td><code>connect-src 'self' https://api.example.com</code></td>
<td>API 호출은 자기 자신과 백엔드 도메인으로만 허용</td>
</tr>
<tr>
<td><code>frame-ancestors 'none'</code></td>
<td>다른 사이트가 iframe으로 삽입하는 것을 차단</td>
</tr>
<tr>
<td><code>object-src 'none'</code></td>
<td>Flash/Java 같은 플러그인 객체 차단</td>
</tr>
</tbody>
</table>
이제 같은 공격이 시도되면:
<pre><code class="language-javascript">1. 공격자가 악성 스크립트를 삽입
2. 스크립트가 localStorage에서 토큰을 읽음 → 여기까진 가능
3. 토큰을 https://evil.com으로 전송 시도
4. [X] 브라우저가 차단 — connect-src에 evil.com이 없음
</code></pre>
<blockquote>
Point: 핵심: 코드에 XSS 취약점이 없다는 것과, 취약점이 생겨도 방어할 수 있다는 것은 다르다. CSP는 후자를 보장하는 방어막이다. 특히 localStorage에 토큰을 저장하는 구조라면 CSP는 선택이 아니라 필수다.
</blockquote>
<hr>
<h2>3. 소스맵이 배포 환경에 포함되고 있었다</h2>
<pre><code class="language-typescript">// Before — production 외 모든 환경에서 소스맵 생성
sourcemap: mode !== &quot;production&quot;;

// After — 모든 환경에서 비활성화
sourcemap: false;
</code></pre>
기존 설정은 production에서만 소스맵을 제거했다. Stage 환경은 외부에서 접근 가능한 배포인데도 소스맵이 포함되고 있었다.
<h3>소스맵이 노출되면 무엇이 위험한가</h3>
소스맵이 있으면 브라우저 개발자 도구에서 번들링 전의 원본 TypeScript 코드를 그대로 복원할 수 있다.
<pre><code class="language-typescript">// 소스맵 없이 보이는 빌드 결과
const a=()=&gt;{const e=localStorage.getItem(&quot;app-session&quot;);...}

// 소스맵이 있으면 원본이 복원됨
const getSession = () =&gt; {
 const stored = localStorage.getItem(&#x27;app-session&#x27;)
 const parsed = JSON.parse(stored)
 return parsed.state
}
</code></pre>
API 엔드포인트, 권한 체크 로직, 비즈니스 규칙이 모두 드러난다. 금융 시스템에서 권한 체크가 어떤 조건으로 이루어지는지가 노출되면, 공격자는 우회 방법을 훨씬 쉽게 찾을 수 있다.
<hr>
<h2>4. 보안 응답 헤더가 하나도 없었다</h2>
CloudFront + S3로 배포하고 있었는데, HTTP 응답에 보안 헤더가 하나도 설정되어 있지 않았다.
<pre><code class="language-bash">$ curl -sI https://stage.example.com

HTTP/2 200
content-type: text/html
server: AmazonS3
x-cache: Miss from cloudfront
# 보안 헤더는 없음
</code></pre>
<h3>누락된 헤더와 각각이 방어하는 공격</h3>
<table>
<thead>
<tr>
<th>헤더</th>
<th>없을 때 가능한 공격</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>Strict-Transport-Security</code></td>
<td>사용자가 <code>http://</code>로 접속하면 암호화 없이 통신. 중간자가 토큰을 엿볼 수 있음</td>
</tr>
<tr>
<td><code>X-Frame-Options: DENY</code></td>
<td>공격자가 우리 사이트를 iframe으로 감싸고 투명하게 덮어씌워, 사용자의 클릭을 가로챔 (클릭재킹)</td>
</tr>
<tr>
<td><code>X-Content-Type-Options: nosniff</code></td>
<td>브라우저가 텍스트 파일을 JavaScript로 추측 실행하는 것을 방지</td>
</tr>
<tr>
<td><code>Referrer-Policy</code></td>
<td>외부 링크 클릭 시 현재 URL의 쿼리 파라미터(토큰, 필터 정보 등)가 상대 서버에 전송됨</td>
</tr>
</tbody>
</table>
CSP는 <code>index.html</code>의 meta 태그로 추가할 수 있었지만, 나머지 4개는 HTTP 응답 헤더로만 설정 가능하다. CloudFront Response Headers Policy로 설정했다.
<h3>CloudFront Response Headers Policy 설정</h3>
<pre><code class="language-json">{
 &quot;SecurityHeadersConfig&quot;: {
 &quot;StrictTransportSecurity&quot;: {
 &quot;AccessControlMaxAgeSec&quot;: 31536000,
 &quot;IncludeSubdomains&quot;: true,
 &quot;Override&quot;: true
 },
 &quot;FrameOptions&quot;: {
 &quot;FrameOption&quot;: &quot;DENY&quot;,
 &quot;Override&quot;: true
 },
 &quot;ContentTypeOptions&quot;: {
 &quot;Override&quot;: true
 },
 &quot;ReferrerPolicy&quot;: {
 &quot;ReferrerPolicy&quot;: &quot;strict-origin-when-cross-origin&quot;,
 &quot;Override&quot;: true
 }
 }
}
</code></pre>
설정 후 응답 헤더를 확인하면:
<pre><code class="language-bash">$ curl -sI https://app.example.com

HTTP/2 200
strict-transport-security: max-age=31536000; includeSubDomains
x-frame-options: DENY
x-content-type-options: nosniff
referrer-policy: strict-origin-when-cross-origin
</code></pre>
<hr>
<h2>5. 점검 결과 요약</h2>
<table>
<thead>
<tr>
<th>점검 영역</th>
<th>발견 건수</th>
<th>심각도</th>
<th>조치 상태</th>
</tr>
</thead>
<tbody>
<tr>
<td>토큰 저장 방식</td>
<td>1건</td>
<td>높음</td>
<td>백엔드 HttpOnly 쿠키 전환 협의 → 적용 완료</td>
</tr>
<tr>
<td>CSP 미설정</td>
<td>1건</td>
<td>높음</td>
<td>index.html meta 태그로 추가 완료</td>
</tr>
<tr>
<td>소스맵 노출</td>
<td>1건</td>
<td>중간</td>
<td>모든 환경 비활성화 완료</td>
</tr>
<tr>
<td>보안 응답 헤더 부재</td>
<td>4건</td>
<td>중간</td>
<td>CloudFront Response Headers Policy 설정 완료</td>
</tr>
<tr>
<td>XSS/인젝션 취약점</td>
<td>0건</td>
<td>—</td>
<td>React 자동 이스케이프 + Zod 검증 + TS strict</td>
</tr>
<tr>
<td>총계</td>
<td>7건</td>
<td></td>
<td>코드 레벨 0건, 설정/인프라 7건 → 전건 조치</td>
</tr>
</tbody>
</table>
<blockquote>
핵심 발견: 코드에서는 취약점이 0건이었지만, “설정하지 않아서 생긴” 취약점이 7건이었다. 코드 품질과 시스템 보안은 다른 레이어임을 보여주는 결과다.
</blockquote>
<hr>
<h2>6. Before vs After</h2>
<table>
<thead>
<tr>
<th>항목</th>
<th>Before (점검 전)</th>
<th>After (조치 후)</th>
</tr>
</thead>
<tbody>
<tr>
<td>CSP</td>
<td>미설정</td>
<td>script-src, connect-src, frame-ancestors 설정</td>
</tr>
<tr>
<td>소스맵</td>
<td>stage 환경 노출</td>
<td>전체 환경 sourcemap: false</td>
</tr>
<tr>
<td>HSTS</td>
<td>미설정</td>
<td>max-age=31536000; includeSubDomains</td>
</tr>
<tr>
<td>X-Frame-Options</td>
<td>미설정</td>
<td>DENY</td>
</tr>
<tr>
<td>X-Content-Type-Options</td>
<td>미설정</td>
<td>nosniff</td>
</tr>
<tr>
<td>Referrer-Policy</td>
<td>미설정</td>
<td>strict-origin-when-cross-origin</td>
</tr>
<tr>
<td>토큰 저장</td>
<td>localStorage 평문</td>
<td>HttpOnly 쿠키로 전환 완료</td>
</tr>
</tbody>
</table>
<hr>
<h2>7. 정리: 코드 보안과 인프라 보안은 레이어가 다르다</h2>
이번 점검에서 얻은 핵심 교훈은, 코드에 취약점이 없는 것과 시스템이 안전한 것은 다르다는 점이다.
<table>
<thead>
<tr>
<th>레이어</th>
<th>역할</th>
</tr>
</thead>
<tbody>
<tr>
<td>코드</td>
<td>취약점이 생기지 않게 한다</td>
</tr>
<tr>
<td>브라우저 정책 (CSP)</td>
<td>취약점이 생겨도 실행을 차단한다</td>
</tr>
<tr>
<td>전송 (HTTPS, HSTS)</td>
<td>데이터가 이동 중에 탈취되지 않게 한다</td>
</tr>
<tr>
<td>저장 (HttpOnly 쿠키)</td>
<td>토큰이 JavaScript에서 접근 불가하게 한다</td>
</tr>
</tbody>
</table>
각 레이어는 독립적으로 동작한다. 코드가 완벽해도 CSP가 없으면 의존성 하나의 공급망 공격에 무방비다. CSP가 있어도 HTTPS가 강제되지 않으면 중간자 공격에 노출된다. 방어는 겹겹이 쌓아야 한다.
<blockquote>
Point: 금융 도메인에서 프론트엔드 보안을 한 줄로 요약하면: “코드에서 막고, 브라우저에서 막고, 네트워크에서 막아라.” 한 레이어가 뚫려도 다음 레이어가 버텨야 한다.
</blockquote>

20개 슬라이스, 6개 레이어 — FSD 점진적 도입기

Ant Design을 걷어내고 자체 디자인시스템 만들기

금융 도메인에서의 프론트엔드 보안 챙기기

React 라우트 가드 3계층 설계 — ProtectedRoute, RoleBasedRoute, ScopedRouteGuard

백엔드 없이 프론트 먼저 — Mock-First 개발과 OpenAPI 타입 안전 API 레이어 구축기