\n\n\n```\n\n**동작 원리:**\n1. 브라우저가 외부 리소스를 다운로드\n2. 다운로드된 파일의 해시를 계산\n3. `integrity` 속성의 해시와 비교\n4. 불일치 시 리소스 실행/적용을 차단\n\n**해시"}},{"@type":"Question","name":"프론트엔드 의존성 보안 관리 전략을 설명해주세요.","acceptedAnswer":{"@type":"Answer","text":"npm 생태계는 공급망 공격에 취약하므로 의존성 보안 관리가 필수입니다.\n\n**자동화된 보안 검사:**\n```bash\n# npm 내장 감사\nnpm audit\nnpm audit fix\n\n# Snyk (더 정밀한 분석)\nnpx snyk test\n\n# GitHub Dependabot - 자동 PR 생성\n# .github/dependabot.yml 설정\n```\n\n**보안 전략:**\n1. **lock 파일 커밋**: `package-lock.json`으로 정확한 버전 고정\n2. **정기적 npm audit**: CI/CD 파이프라인에 통합\n3. **의존성 최소화**: 작은 유틸은 직접 구현 고려\n4. **Dependabot/Renovate**: 자동 업데이트 PR\n5. **License 검사**: `license-checker`로 라이센스 호환성 확인\n\n**공급망 공격 방어:**\n- SRI(Subresource Integrity)로 CDN 스크립트 무결성 검증\n- `package.json`에"}},{"@type":"Question","name":"서버리스 함수로 API 키와 같은 민감한 정보를 어떻게 관리할까요?","acceptedAnswer":{"@type":"Answer","text":"## 대전제 — 클라이언트에 보낸 순간 비밀이 아닙니다\n\n번들 난독화, 환경변수 주입, localStorage 저장 모두 **비밀 유지 수단이 아닙니다.** 브라우저 개발자도구 Network 탭과 소스맵으로 전부 드러납니다. 유일한 해법은 **비밀을 클라이언트에 보내지 않는 것**입니다.\n\n## 프록시 패턴 — 기본 구조\n\n```\n브라우저 → (키 없음) → 서버리스 함수 → (키 첨부) → 외부 API\n```\n\n```ts\n// app/api/weather/route.ts (서버에서만 실행)\nexport async function GET(req: Request) {\n const city = new URL(req.url).searchParams.get('city');\n if (!city) return Response.json({ error: 'city 필요' }, { status: 400 });\n\n const res = await fetch(`https://api.weather"}},{"@type":"Question","name":"프런트엔드 영역에서 발생할 수 있는 웹 사이트의 보안 위협은 어떤 것이 있을까요?","acceptedAnswer":{"@type":"Answer","text":"## 1. XSS (Cross-Site Scripting) — 프론트엔드 최대 위협\n\n공격자의 스크립트가 피해자 브라우저에서 **우리 오리진의 권한으로** 실행됩니다. 쿠키·토큰 탈취, 화면 위조, 요청 위조가 모두 가능합니다.\n\n- **Stored** — DB에 저장된 스크립트가 다른 사용자에게 전달 (게시글, 댓글, 프로필)\n- **Reflected** — URL 파라미터가 그대로 화면에 출력\n- **DOM-based** — 서버를 거치지 않고 클라이언트 JS가 위험한 싱크에 값을 넣음\n\n**방어**\n- 출력 시 컨텍스트에 맞는 이스케이프 (React/Vue의 기본 보간이 HTML 컨텍스트를 처리)\n- `dangerouslySetInnerHTML`·`v-html`·`innerHTML` 사용 시 **DOMPurify** 통과\n- **CSP** 헤더로 인라인 스크립트 차단 (nonce 기반)\n- 쿠키에 **HttpOnly** → JS가 토큰을 읽지 못하게\n\n## 2. CSRF (Cr"}},{"@type":"Question","name":"서드 파티 스크립트를 추가할 때 발생할 수 있는 성능과 보안 위험은 무엇일까요?","acceptedAnswer":{"@type":"Answer","text":"분석 도구(GA, Amplitude), 광고, 챗봇, A/B 테스트, 태그 매니저 — 대부분의 서비스가 붙이지만 **우리 오리진의 전권을 남에게 주는 행위**입니다.\n\n## 보안 위험\n\n**1. 우리 오리진의 모든 권한을 갖습니다**\n서드파티 스크립트는 우리 페이지에서 실행되므로:\n- DOM 전체 읽기·조작 (입력 폼 값, 결제 정보)\n- **HttpOnly가 아닌 쿠키**와 `localStorage` 접근\n- 우리 오리진 이름으로 API 호출 (세션 쿠키 자동 첨부)\n- 사용자 몰래 다른 스크립트 추가 로드\n\n**2. 공급망 공격 (Magecart)**\n공격자가 서드파티 CDN이나 벤더 계정을 침해해 스크립트를 변조하면, **우리는 코드를 한 줄도 안 바꿨는데** 결제 정보가 유출됩니다. 실제로 브리티시 에어웨이·티켓마스터 등의 대형 유출 사고가 이 방식이었습니다(공개된 사건 사례 기준).\n\n**3. 태그 매니저의 위험**\nGTM은 **개발자 배포 없이 마케터가 임의 JS를 프로덕"}}]}