11. 🔐 프론트엔드 보안 위협과 방어 전략

📌 이 면접 항목의 목표

⏱️ 예상 읽기 시간: 20분 (핵심 요약: 10분)

🗺️ 이 챕터의 흐름
[개념 사전] → [질문 1: XSS & CSRF 방어] → [질문 2: 토큰 보안 & SSR 인증] → [실전 변형 질문]

🎯 이 챕터를 다 읽으면 할 수 있는 것

• 브라우저 환경에서 발생할 수 있는 주요 보안 위협의 원리와 방어 기법을 설명합니다.
• Content Security Policy(CSP)를 활용하여 보안 수준을 강화하는 법을 익힙니다.
• 왜 Access Token을 로컬 스토리지에 저장하면 안 되는지 보안적 관점에서 논합니다.

📚 핵심 개념 사전 (Concept Glossary)

1. XSS (Cross-Site Scripting)

공격자가 악성 스크립트를 삽입하여 사용자의 브라우저에서 실행되게 만드는 공격입니다. 쿠키 탈취, 세션 가로채기 등이 가능해지며 프론트엔드 보안의 최대 공공의 적입니다.

2. CSRF (Cross-Site Request Forgery)

사용자가 자신의 의지와 무관하게 공격자가 의도한 행위(비밀번호 변경, 송금 등)를 특정 웹사이트에 요청하게 만드는 공격입니다. 사용자가 이미 인증된 세션을 가지고 있다는 점을 악용합니다.

3. HttpOnly & Secure Cookie

• HttpOnly: 자바스크립트(document.cookie)로 쿠키에 접근하는 것을 막아 XSS로부터 토큰을 보호합니다.
• Secure: 오직 HTTPS 연결에서만 쿠키가 전송되도록 하여 통신 과정의 유출을 방지합니다.

🗺️ 이 문서의 배경 세계관: '영수네 커뮤니티'

• 🐣 영철 ( 신입 ): "영호 님! '영수네 게시판' 댓글에 누군가 <script>alert('해킹됨')</script>을 잔잔하게 깔아놨어요! 😱 다행히 알림만 뜨는데, 진짜 해커라면 어쩌죠?"
• 🦁 영호 ( 리드 ): "영철 님, 그건 해커가 보낸 '경고장'입니다. 지금은 alert이지만 다음엔 유저의 로그인 정보가 해커 서버로 전송되겠죠. 프론트엔드는 사용자의 정보를 담는 '금고'의 입구예요. 입구가 뚫리면 금고는 무의미합니다."

Q1. XSS와 CSRF 공격의 결정적인 차이점과, 각각의 프론트엔드 측 방어 전략을 설명해 보세요.

🎯 출제 의도

웹 보안의 2대 산맥을 정확히 구분하고 있는지 확인합니다. 공격의 '주체'와 '대상'을 이해해야 올바른 방어 로직을 짤 수 있습니다.

🐣 영철이의 Naive 구현 (Bad Case)

영철이는 게시판 데이터를 dangerouslySetInnerHTML로 아무 검증 없이 렌더링하고 있습니다.

// 🐣 영철: "서버에서 온 데이터니까 믿어도 되겠죠?"
function PostContent({ content }) {
  // ⚠️ 위험: content에 <script> 태그가 포함되어 있다면 그대로 실행됨 (XSS)
  return <div dangerouslySetInnerHTML={{ __html: content }} />;
}

🦁 영호의 팩폭 조언
"영철 님, 'dangerously'라는 이름이 붙은 이유가 있어요. 사용자의 입력을 절대 믿지 마세요. 그리고 CSRF는 우리 사이트가 아니라 '남의 사이트'에서 우리에게 총을 쏘는 거라는 걸 잊지 마세요."

🦁 영호의 아키텍처 가이드 (Good Case)

영호 리드가 제안하는 2중, 3중 보안 레이어입니다.

// 🦁 영호: "뚫릴 수 있다는 가정하에 중첩된 방패를 세우세요."
 
// 1. XSS 방어 (Sanitization)
import DOMPurify from 'dompurify'; // ✅ 허용된 태그만 골라내는 라이브러리 활용
function SafePostContent({ content }) {
  const cleanContent = DOMPurify.sanitize(content);
  return <div dangerouslySetInnerHTML={{ __html: cleanContent }} />;
}
 
// 2. CSRF 방어
// - SameSite Cookie 설정: 쿠키가 오직 '우리 사이트'에서만 전송되도록 제한
// - CSRF Token: 서버에서 발급한 일회용 토큰을 헤더에 담아 전송
// - Custom Header: API 요청 시 X-Requested-With 같은 커스텀 헤더 강제 (Cross-origin 차단)

📊 레벨별 답변 가이드 (Self-Check)

• Level 1 (Junior): "XSS는 게시판에 스크립트를 올리는 것이고, CSRF는 남의 사이트에서 내 계정으로 요청을 보내는 것입니다. 라이브러리를 써서 막아야 합니다."
• Level 2 (Senior): "XSS 방어를 위한 이스케이프(Escape) 처리와 DOMPurify 활용, CSP 설정의 중요성을 설명합니다. CSRF 방어를 위해서는 쿠키의 SameSite 속성(Strict/Lax)이 어떻게 요청을 제어하는지 원리를 제시합니다."
• Level 3 (Specialist): "현대적인 SPA 환경에서 JWT를 활용할 때의 보안 트레이드오프를 논합니다. XSS는 '스크립트 실행 저지'가 핵심이고, CSRF는 '요청의 출처 검증'이 핵심임을 아키텍처 관점에서 분석합니다. 또한 Referrer-Policy나 STS(Strict-Transport-Security) 같은 고급 보안 헤더 활용 경험을 공유합니다."

Q2. 인증 토큰(Access Token)을 저장할 때 로컬 스토리지와 쿠키 중 어느 것이 더 안전한가요? 그 이유와 실습적인 보안 전략을 설명해 보세요.

🎯 출제 의도

보안과 편의성 사이의 트레이드오프를 이해하고 있는지 확인합니다. 정답은 없지만, 각 선택지에 따른 '위협 모델링' 능력을 평가합니다.

🐣 영철이의 Naive 구현 (Bad Case)

영철이는 구현이 편하다는 이유로 Access Token을 로컬 스토리지에 저장합니다.

// 🐣 영철: "새로고침해도 로그인 안 풀리게 하려면 로컬 스토리지가 제일 편해요!"
localStorage.setItem('accessToken', token);
// ⚠️ 치명적 약점: XSS 한 방이면 해커가 모든 유저의 토큰을 다 털어갈 수 있음

🦁 영호의 팩폭 조언
"영철 님, 로컬 스토리지는 자바스크립트에게 '나를 마음껏 읽어줘'라고 광고하는 곳이에요. 해커에게 레드 카펫을 깔아주는 셈이죠. 보안은 조금 불편하더라도 '안전한 길'로 가야 합니다."

🦁 영호의 아키텍처 가이드 (Good Case)

영호 리드가 제안하는 '하이브리드 보안 전략'입니다.

// 🦁 영호: "중요한 열쇠는 자바스크립트가 만질 수 없는 곳에 두세요."
 
/* 
  1. Refresh Token: HttpOnly & Secure 쿠키에 저장
     - 자바스크립트로 접근 불가 (XSS 방어)
     - CSRF 방어를 위해 SameSite 설정 필수
     
  2. Access Token: 
     - 방법 A: 메모리(React State)에 저장 (가장 안전하지만 새로고침 시 날아감)
     - 방법 B: 짧은 유효기간을 가진 토큰으로 관리하고, 
               Silent Refresh 메커니즘을 통해 쿠키의 Refresh Token으로 재발급
*/

📊 레벨별 답변 가이드 (Self-Check)

• Level 1 (Junior): "쿠키가 더 안전합니다. HttpOnly 설정을 하면 자바스크립트가 못 읽기 때문입니다."
• Level 2 (Senior): "로컬 스토리지는 XSS에 취약하고, 쿠키는 CSRF에 취약하다는 점을 비교 설명합니다. 따라서 쿠키 사용 시 SameSite: Lax/Strict 설정과 CSRF Token 방식을 병행해야 함을 강조합니다."
• Level 3 (Specialist): "'세션 하이재킹' 방어를 위한 포괄적인 전략을 제시합니다. 토큰의 유휴 시간(Idle time) 관리, 중복 로그인 감지, 그리고 프론트엔드 BFF(Backend For Frontend) 패턴을 통해 클라이언트에 토큰을 아예 노출하지 않는 보안 아키텍처를 설명합니다."

🔗 실전 변형 질문 (Related Variations)

Q212. CSP(Content Security Policy)란 무엇이며, 왜 설정해야 하나요?

• 🎯 출제 의도: 브라우저 레벨에서 보안 정책을 강제하는 '최후의 방어선'에 대해 아는지 확인합니다.
• 💡 핵심 원리 & 답변: CSP는 HTTP 헤더를 통해 브라우저가 자원을 로드할 수 있는 안전한 출처(Origin)를 명시하는 보안 레이어입니다. 예를 들어 "스크립트는 오직 우리 서버와 Google Analytics에서만 받아와!"라고 선언하면, 공격자가 악성 스크립트를 삽입해도 브라우저가 실행을 거부합니다. 인라인 스크립트 실행 금지, Eval 사용 금지 등을 통해 XSS 위험을 획기적으로 낮출 수 있습니다.

Q225. HTTPS의 동작 원리와 왜 프론트엔드 개발자도 이를 정확히 알아야 하나요?

• 🎯 출제 의도: 데이터 암호화와 인증서 체계에 대한 기본 소양을 확인합니다.
• 💡 핵심 원리 & 답변: HTTPS는 공개키와 대칭키 암호화 방식을 혼합하여 클라이언트와 서버 사이의 통신을 보호합니다. 프론트엔드 개발자는 단순히 '주소창에 자물쇠'만 보는 것이 아니라, Secure 쿠키 설정이 HTTPS 환경에서만 작동한다는 점, 그리고 중간자 공격(MITM) 시 보안 경고가 발생하는 메커니즘을 이해하여 민감한 데이터 전송 시 안정성을 보장해야 합니다.

Q230. 라이브러리 의존성 보안(Supply Chain Attack)을 방어하는 방법은?

• 🎯 출제 의도: 내가 짠 코드뿐만 아니라 남이 만든 코드(node_modules)의 위험성을 관리하는지 확인합니다.
• 💡 핵심 원리 & 답변: npm audit을 주기적으로 실행하여 알려진 취약점을 체크하고, lock 파일을 통해 모든 팀원이 동일하고 안전한 버전의 패키지를 사용하도록 강제해야 합니다. 또한 중요 프로젝트라면 Snyk 같은 보안 도구를 CI/CD에 연동하여 취약점이 포함된 코드의 배포를 자동 차단하는 환경을 구축하는 것이 좋습니다.

🐣 영철이의 복기 일기

오늘 보안을 배우면서 그동안 얼마나 위험천만하게 코딩했는지 깨닫고 등에 식은땀이 났다. "기능만 잘 돌면 되지"라고 생각하며 localStorage에 다 때려 박았던 건 정말 해커에게 집 열쇠를 던져준 꼴이었다. 보안은 100번 잘해도 1번 뚫리면 끝이라는 영호 님의 말씀을 평생 명심해야겠다.

💡 "개발자의 편의는 곧 해커의 기회다. 불편함을 선택할 때 사용자는 안전해진다."

내일은 드디어 대미를 장식하는 마지막 챕터, '엔지니어링 리더십 & 코드 품질'을 배운다. 단순히 코딩하는 기계를 넘어, 함께 일하고 싶은 동료로 남는 법을 고민해 보자! 🤝🏅