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

📌 이 면접 항목의 목표

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

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

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

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

📚 핵심 개념 사전 (Concept Glossary)

1. XSS (Cross-Site Scripting)

공격자가 악성 스크립트나 위험한 HTML을 삽입하여 사용자의 브라우저에서 실행되게 만드는 공격입니다. 쿠키 탈취, 세션 가로채기, 사용자 대신 요청 보내기 등이 가능해지므로 입력과 출력 경계를 모두 관리해야 합니다.

2. CSRF (Cross-Site Request Forgery)

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

3. HttpOnly & Secure Cookie

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

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

• 🐣 영철 (후반): "영호 님! '영수네 게시판' 댓글에 누군가 위험한 HTML을 넣었습니다. 지금은 단순 알림처럼 보였지만, 로그인 정보나 사용자 행동에도 영향을 줄 수 있겠죠?"
• 🦁 영호 (리드): "맞아요. 보안은 기능이 끝난 뒤 붙이는 장식이 아니라 입력, 저장, 출력, 인증 흐름 전체의 조건입니다. XSS와 CSRF는 공격 경로가 다르니 방어도 다르게 설계해야 해요."

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

🎯 출제 의도

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

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

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

// 🐣 영철: "서버에서 온 데이터니까 믿어도 되겠죠?"
function PostContent({ content }) {
  // ⚠️ 위험: onerror, javascript: URL 같은 HTML 속성이 실행될 수 있음
  // 예: '<img src=x onerror="fetch(`/steal?c=${document.cookie}`)">'
  return <div dangerouslySetInnerHTML={{ __html: content }} />;
}

🦁 영호의 리뷰 포인트
"영철 님, dangerouslySetInnerHTML은 HTML을 React의 기본 이스케이프 보호 밖에서 넣겠다는 선언입니다. 사용자의 입력은 신뢰하지 말고, 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 설정: cross-site 요청에 쿠키가 자동 포함되는 범위를 제한
// - CSRF Token: 서버에서 발급한 일회용 토큰을 헤더에 담아 전송
// - Custom Header: 단순 요청을 피하고 서버의 Origin/토큰 검증과 함께 사용

React는 일반 텍스트 렌더링에서 값을 이스케이프하지만, rich text 요구 때문에 HTML을 직접 넣는 순간 방어 책임이 개발자에게 옵니다. sanitizer, CSP, 허용 태그 정책을 함께 정해야 "보이는 기능"과 "안전한 출력"을 동시에 만족할 수 있습니다.

📊 레벨별 답변 가이드 (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) 같은 고급 보안 헤더 활용 경험을 공유합니다."

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

🎯 출제 의도

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

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

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

// 🐣 영철: "새로고침해도 로그인 안 풀리게 하려면 로컬 스토리지가 제일 편해요!"
localStorage.setItem('accessToken', token);
// ⚠️ 약점: XSS가 발생하면 실행된 스크립트가 토큰을 읽어 외부로 보낼 수 있음

🦁 영호의 리뷰 포인트
"영철 님, 로컬 스토리지는 같은 origin에서 실행되는 자바스크립트가 읽을 수 있습니다. 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)

면접 질문 212. CSP(Content Security Policy)란 무엇이며, 왜 설정해야 하나요?

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

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

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

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

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

📝 마무리 퀴즈

Q1. XSS와 CSRF의 차이를 면접에서 설명할 때 가장 중요한 구분은 무엇인가요?

✅ 정답: XSS는 공격 스크립트가 사용자 브라우저에서 실행되는 문제이고, CSRF는 인증된 사용자의 권한으로 원치 않는 요청이 보내지는 문제라는 점

💡 상세 해설:

• 원리 설명: XSS는 입력 검증, 출력 인코딩, sanitizer, CSP로 막고, CSRF는 SameSite 쿠키, CSRF token, custom header 같은 요청 검증으로 막습니다. 공격의 경로가 다르니 방어도 달라야 합니다.
• 오답 피드백: 둘 다 "해킹"이라고만 말하면 왜 HttpOnly가 XSS에 도움 되고, 왜 SameSite가 CSRF에 중요한지 설명할 수 없습니다.
• 📌 핵심 기억법: 스크립트가 실행되는 공격인지, 요청이 위조되는 공격인지 먼저 나눕니다.

Q2. Access Token을 localStorage에 오래 보관하는 방식이 위험한 이유는 무엇인가요?

✅ 정답: XSS가 발생하면 자바스크립트로 토큰을 읽어 외부로 유출할 수 있기 때문

💡 상세 해설:

• 원리 설명: 보안 설계는 편의성과 위험의 균형입니다. Refresh Token은 HttpOnly/Secure/SameSite 쿠키로 보호하고, Access Token은 짧은 수명과 메모리 저장/BFF 패턴 등을 고려해야 합니다.
• 오답 피드백: 쿠키가 항상 안전하다는 뜻도 아닙니다. 쿠키는 CSRF 방어 설정이 함께 필요합니다.
• 📌 핵심 기억법: 토큰 저장소를 고를 때는 어떤 공격자가 무엇을 읽을 수 있는지부터 봅니다.

Q3. 영철이의 테스트 타임: dangerouslySetInnerHTML을 써야만 하는 요구사항이 있을 때 최소한 확인해야 할 것은 무엇인가요?

✅ 정답: 신뢰할 수 없는 HTML을 sanitizer로 정제하고, CSP와 허용 태그 정책을 함께 검토한다

💡 상세 해설:

• 원리 설명: rich text를 렌더링해야 하는 요구는 현실적으로 존재합니다. 중요한 건 "서버에서 왔으니 믿는다"가 아니라, 입력/저장/출력 어느 단계에서 어떤 HTML을 허용할지 명확히 하는 것입니다.
• 오답 피드백: dangerouslySetInnerHTML을 금지한다고만 답하면 실무 요구를 해결하지 못합니다. 안전한 사용 조건을 말해야 합니다.
• 📌 핵심 기억법: 위험한 API는 금지가 아니라 통제 조건이 핵심입니다.

🐣 영철이의 퇴근 일기

오늘은 보안을 "나중에 붙이는 옵션"처럼 생각했던 태도를 버렸다. 영수네 게시판 댓글 하나가 토큰 탈취로 이어질 수 있다는 걸 보고, 프론트엔드가 사용자 데이터를 지키는 첫 번째 방어선이라는 말이 실감났다.

💡 "보안은 기능을 막는 장벽이 아니라, 기능이 사용자 편에서 오래 버티게 하는 조건이다."

다음 리뷰에서는 저장소와 쿠키 설정만 보는 게 아니라, 공격자가 어떤 경로로 들어올 수 있는지 먼저 그려봐야겠다. 영철이 이제 편한 구현과 안전한 구현 사이의 비용을 면접에서 설명할 수 있을 것 같다.