G-4: 프론트엔드 보안 ① — 우리 화면에서 남의 코드가 돈다

안녕하세요, 홍순구 튜터입니다.

지난 시간에 코어 과정을 닫으면서 더 가고 싶은 분들을 위해 네 갈래를 말씀드렸는데, 그중 첫 번째가 이거였습니다.

남이 심은 스크립트가 우리 페이지에서 도는 문제, 남의 사이트가 우리 앱에 요청을 대신 보내는 문제, 그리고 브라우저에게 "이 출처의 스크립트만 실행해라"라고 미리 알려두는 방법이 있어요.

오늘부터 세 시간 동안 그 셋을 다 보는데, 오늘은 첫 번째인 남이 심은 스크립트가 우리 페이지에서 도는 문제부터예요.

시작하기 전에 하나 짚고 갈 게 있는데, 여러분은 45일 동안 이 앱을 만들면서 이 문제를 한 번도 안 만났어요. 오늘은 그 이유부터 확인해보는데, 우리가 잘해서였는지 아니면 운이 좋아서였는지요.

 오늘의 여정

 1. 댓글을 만든다 → 공격 문자열을 넣어본다 → 아무 일도 안 일어난다
 2. 서식을 살리고 싶어진다 → 한 줄을 바꾼다 → 탭 제목이 바뀐다
 3. 다른 문자열로 다시 재본다 → 아까 «안전» 이 조건부였다는 걸 안다
 4. 남의 스크립트가 실제로 무엇을 할 수 있는지 끝까지 가본다
 5. 걸러낸다 → 서식은 살리고 나머지는 지운다

💡 오늘 수업의 핵심 — "안전했던 게 아니라, 안전한 방법을 쓰고 있었습니다"

🎯 학습 목표

• 화면에 사용자 입력을 넣는 두 가지 방법이 어떻게 다른지 직접 재보고, 왜 한쪽 이름만 유난히 긴지 이해합니다.
• 공격 문자열 하나만으로 시험하면 왜 거짓 안심을 얻는지, 네 칸짜리 표를 채워 확인합니다.
• 남이 심은 스크립트가 무엇을 훔칠 수 있고 무엇을 훔치지 않고도 할 수 있는지 끝까지 확인한 뒤, 어디서 걸러낼지 정합니다.

Step 1: "우리는 이미 안전했습니다"

인스타그램에 댓글이 없으면 인스타그램이 아니지만, 우리 Next 앱에는 아직 댓글이 없어서 오늘 그것부터 만들고 그 위에서 이야기를 진행할게요.

연습용 서버에는 이미 댓글 API가 준비돼 있는데, 가져오는 함수부터 적습니다.

// apps/web-next/lib/api.ts
/** 게시물에 달린 댓글 한 줄 */
export type Comment = {
  id: number;
  postId: number;
  username: string;
  content: string;
  createdAt: string;
};

/**
 * 댓글은 굳히지 않는다. 방금 단 것이 안 보이면 안 단 것과 같다.
 * 그래서 'use cache' 도 이름표도 없다 — 피드와 같은 결이다.
 */
export function fetchComments(postId: number): Promise<Comment[]> {
  return get<Comment[]>(`/posts/${postId}/comments`);
}

댓글을 다는 일은 서버 액션이 맡는데, D-7·D-8에서 만든 팔로우·좋아요와 똑같이 동작합니다. 누가 썼는지는 폼이 보낸 값이 아니라 서버가 쿠키에서 직접 읽습니다.

// apps/web-next/app/actions/comment.ts
'use server';

import { currentUser } from '@/lib/session';
import { fetchAsUser } from '@/lib/backend-token';

export type CommentState = {
  message: string | null;
};

export async function addComment(
  postId: number,
  _previous: CommentState,
  formData: FormData,
): Promise<CommentState> {
  const me = await currentUser();

  if (me === null) {
    return { message: '로그인이 필요해요' };
  }

  const content = String(formData.get('content') ?? '').trim();

  if (content === '') {
    return { message: '댓글을 입력해주세요' };
  }

  const response = await fetchAsUser(me, `/posts/${postId}/comments`, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ content }),
  });

  if (response === null) {
    return { message: '백엔드에 신원을 확인받지 못했어요' };
  }

  const envelope = await response.json();

  if (!response.ok || !envelope.success) {
    return { message: envelope.message ?? '댓글을 저장하지 못했어요' };
  }

  return { message: null };
}

이제 화면 차례인데, 목록은 서버 컴포넌트가 그려요.

// apps/web-next/app/components/CommentSection.tsx
import { fetchComments } from '@/lib/api';
import { CommentForm } from './CommentForm';

// 지시어가 없다. 서버 컴포넌트라 여기서 그냥 기다렸다 받는다.
export async function CommentSection({ postId }: { postId: number }) {
  const comments = await fetchComments(postId);

  return (
    <section className="mt-2 border-t border-black/5 pt-2">
      <ul className="space-y-1">
        {comments.map((comment) => (
          <li key={comment.id} className="text-sm">
            <span className="mr-1 font-semibold">@{comment.username}</span>
            {/* 중괄호로 넣는다. 여기가 오늘의 출발점이다. */}
            <span>{comment.content}</span>
          </li>
        ))}
      </ul>
      <CommentForm postId={postId} />
    </section>
  );
}

폼은 useActionState로 묶는데, D-7에서 팔로우 버튼에 쓴 것과 같고, 안에 넣은 SubmitButton은 D-8에서 공용으로 뽑아둔 것이에요.

// apps/web-next/app/components/CommentForm.tsx
'use client';

import { useActionState } from 'react';
import { addComment, type CommentState } from '@/app/actions/comment';
import { SubmitButton } from './SubmitButton';

const initial: CommentState = { message: null };

export function CommentForm({ postId }: { postId: number }) {
  // 어느 게시물인지는 미리 묶어둔다. 나머지 두 인자는 React 가 채운다.
  const [state, formAction] = useActionState(addComment.bind(null, postId), initial);

  return (
    <form action={formAction} className="mt-2 flex gap-2">
      <label htmlFor={`comment-${postId}`} className="sr-only">
        댓글 달기
      </label>
      <input
        id={`comment-${postId}`}
        name="content"
        placeholder="댓글 달기…"
        className="flex-1 border-b border-black/15 py-1 text-sm outline-none"
      />
      <SubmitButton pendingLabel="다는 중…" className="text-sm font-semibold disabled:opacity-40">
        게시
      </SubmitButton>
      {state.message !== null && (
        <p aria-live="polite" className="text-sm text-black/60">
          {state.message}
        </p>
      )}
    </form>
  );
}

마지막으로 피드 카드에 붙입니다.

// apps/web-next/app/components/FeedList.tsx
          <LikeButton postId={post.id} likeCount={post.likeCount} liked={post.liked} />
          <CommentSection postId={post.id} />

로그인하고 댓글을 달아보세요. 잘 달립니다.

이제 이상한 걸 넣어봅시다

보안 이야기를 시작할 때 가장 먼저 하는 실험이 있는데, 입력칸에 이걸 넣는 거예요.

<script>alert(1)</script>

댓글창에 넣고 게시를 눌러보시면, 화면에 이렇게 나옵니다.

 @minji  <script>alert(1)</script>

경고창은 안 뜨고 태그가 글자 그대로 화면에 보이는데, 우리가 넣은 문자열이 그냥 문자열로 남았습니다.

정말 그런지 소스 보기로 확인해봅시다. 브라우저에서 페이지 소스 보기를 열고 alert을 찾으면 이렇게 되어 있어요.

<span>&lt;script&gt;alert(1)&lt;/script&gt;</span>

<가 <로 바뀌어 있는데, 브라우저에게 "이건 태그가 아니라 글자야"라고 알려주는 표기라서 브라우저가 태그로 안 읽고 그냥 글자로 그립니다.

누가 이렇게 바꿔줬을까요

우리가 한 게 아닙니다. {comment.content}라고 쓴 것뿐이에요.

React가 중괄호 안에 들어온 값을 화면에 넣을 때는 언제나 글자로 취급하는데, 태그처럼 생겼든 아니든 상관없이 그게 기본 동작이에요. 그 덕분에 지난 45일 동안 여러분이 만든 모든 화면이 이 문제에서 자유로웠습니다. 회원가입 폼도, 검색칸도, 프로필 이름도요. 한 번도 신경 안 썼는데 안전했어요.

이건 좋은 소식입니다. 그런데 조심할 게 하나 있어요. "React를 쓰면 안전하다"가 아니라 "중괄호로 넣으면 안전하다"입니다. 둘은 다른 말이에요.

그 차이가 다음 Step에서 드러납니다.

💡 한 줄 정리

중괄호로 넣은 값은 태그처럼 생겼어도 글자로 그려집니다. 45일 동안 우리가 안전했던 건 이 기본 동작 덕분이지, 우리가 뭘 해서가 아닙니다.

Step 2: "그런데 줄바꿈을 넣고 싶어졌습니다"

댓글을 며칠 굴렸더니 요청이 들어옵니다.

댓글에 줄바꿈이 안 돼요. 엔터를 쳐도 한 줄로 붙어 나옵니다. 그리고 강조도 좀 하고 싶어요.

말이 되는 요청이니까, 실제 서비스에서도 흔히 받는 요구예요.

가장 빨리 해결하는 방법은 댓글을 글자가 아니라 HTML로 넣는 것인데, 그래야 <br>도 <b>도 그대로 살아나거든요.

React에는 그걸 하는 방법이 있는데, 이름이 좀 깁니다.

// apps/web-next/app/components/CommentSection.tsx
          <li key={comment.id} className="text-sm">
            <span className="mr-1 font-semibold">@{comment.username}</span>
            {/* 줄바꿈과 링크를 살리려고 글자가 아니라 HTML 로 넣는다.
                이름이 길고 사나운 이유가 있다 — 이 한 줄이 오늘의 문제다. */}
            <span dangerouslySetInnerHTML={{ __html: comment.content }} />
          </li>

dangerouslySetInnerHTML. 위험하게 HTML을 넣는다는 뜻입니다.

React 팀이 일부러 이렇게 지었어요. 다른 API는 전부 짧고 담백한데 이것만 유난히 깁니다. 심지어 값도 {{ __html: ... }}처럼 한 겹 더 감싸게 해뒀어요. 그냥 문자열을 받게 만들 수도 있었는데 안 그랬습니다.

타이핑이 귀찮아야 한 번 더 생각한다는 겁니다. 오늘 그 이유를 확인하게 될 거예요.

일단 요구는 해결됐습니다. 댓글에 첫 줄<br>둘째 줄 그리고 <b>강조</b>를 넣으면 이렇게 나옵니다.

 @minji  첫 줄
         둘째 줄 그리고 강조

줄이 바뀌고 강조도 굵게 나옵니다. 요청하신 분이 만족하시겠네요.

그런데 아까 그 댓글이 아직 거기 있습니다

Step 1에서 넣었던 댓글 기억하시죠. 그때는 글자로만 보였던 그것요.

이번엔 페이로드를 조금 바꿔서 다시 넣어봅시다. 경고창은 실습 흐름을 끊으니까, 눈에 보이면서 창을 안 띄우는 걸로 할게요.

<script>document.title = "털렸습니다"</script>사진 좋네요

게시를 누르고 화면을 보세요. 댓글 목록에는 이렇게 나옵니다.

 @minji  document.title = "털렸습니다"사진 좋네요

태그는 안 보이고 그 안에 있던 코드가 글자로 보이네요. 좀 이상하죠.

이번엔 브라우저 탭을 보세요.

 탭 제목:  인스타그램 클론   →   털렸습니다

바뀌었습니다.

무슨 일이 일어난 걸까요

서버가 보낸 HTML을 열어보면 이렇게 되어 있어요.

<span><script>document.title = "털렸습니다"</script>사진 좋네요</span>

Step 1에서는 <script>로 나왔던 것이 이번엔 진짜 <script>입니다. 브라우저는 이걸 문서의 일부로 읽어서, 안에 있는 코드를 실행하죠.

댓글 목록에 이상한 글자가 보였던 것도 설명이 됩니다. <script> 태그 자체는 화면에 안 그려지지만 그 안의 글자는 남거든요. 실제 공격자라면 그것도 안 보이게 만들 겁니다.

지금 우리 앱의 상태를 정리하면 이렇습니다.

• 누구나 댓글을 달 수 있다
• 댓글은 HTML로 화면에 들어간다
• 그러니 누구나 우리 페이지에서 자기 코드를 돌릴 수 있다

댓글 하나로 탭 제목을 바꿨습니다. 제목만 바꿀 수 있는 건 아니겠죠. 그건 Step 4에서 끝까지 가봅니다.

💡 한 줄 정리

dangerouslySetInnerHTML은 받은 문자열을 문서의 일부로 만듭니다. 서식이 살아나는 것과 남의 코드가 도는 것은 같은 동작의 양면이에요.

Step 3: "공격 문자열 하나로 시험하면 속습니다"

여기서 잠깐 멈춥시다.

여러분이 회사에서 이 문제를 점검한다고 해봐요. 입력칸마다 <script>alert(1)</script>를 넣어보고, 경고창이 안 뜨면 "안전하다"라고 표시할 겁니다. 흔한 방법이에요.

그런데 그 방법에는 구멍이 있습니다. 직접 재봅시다.

클라이언트가 나중에 붙이면 어떻게 될까요

우리 댓글은 서버가 그린 HTML에 들어가서, 브라우저가 문서를 읽으면서 스크립트를 만나 실행했어요.

그런데 화면이 다 뜬 다음에 자바스크립트가 HTML을 밀어 넣는 경우도 있습니다. C 카테고리에서 만든 SPA가 그런 구조였는데, 그때는 어떻게 될까요.

개발자 도구 콘솔을 열고 이걸 붙여넣어 보세요.

const box = document.createElement('div');
document.body.append(box);
box.innerHTML = '<script>document.title = "이것도 돌까"<\/script><img src=x onerror="document.body.dataset.late = 1">';

// 이미지 로드 실패는 비동기다. 바로 읽으면 아직 안 돈다.
await new Promise((r) => setTimeout(r, 800));

console.log('script 태그가 DOM 에 있나 :', box.querySelectorAll('script').length);
console.log('script 가 돌았나         :', document.title === '이것도 돌까');
console.log('img 태그가 DOM 에 있나   :', box.querySelectorAll('img').length);
console.log('onerror 가 돌았나        :', document.body.dataset.late === '1');

결과가 이렇게 나옵니다.

 script 태그가 DOM 에 있나 : 1
 script 가 돌았나         : false
 img 태그가 DOM 에 있나   : 1
 onerror 가 돌았나        : true

읽어보면 이상하죠. <script> 태그는 DOM에 분명히 들어갔는데 안 돌았습니다. 반면 <img>의 onerror는 돌았어요.

이건 브라우저 규칙이에요. innerHTML로 밀어 넣은 <script>는 실행하지 않기로 정해져 있어서, 문서를 처음 읽을 때 만난 스크립트만 실행됩니다.

그런데 onerror 같은 이벤트 속성은 그 규칙에 안 걸립니다. 이미지 주소가 잘못돼 로드에 실패하고, 실패했으니 onerror가 불리고, 거기 적힌 코드가 돕니다.

네 칸을 채워봅시다

지금까지 잰 걸 모으면 이렇게 됩니다.

이 표에서 읽어야 할 게 두 가지입니다.

하나. 오른쪽 칸은 세 줄 중 두 줄이 실행되는데, 왼쪽 칸은 한 줄뿐이에요. 그러니 <script>로만 시험하면 실제로는 뚫려 있는데 안전하다고 판정할 수 있습니다. 클라이언트가 그리는 화면에서 특히 그래요.

둘. 같은 코드인데 서버에서 그리느냐 브라우저에서 그리느냐로 결과가 갈리는데, D-3에서 그은 그 선이 여기서 다시 나와요. 그때는 번들 크기와 데이터 유출이 갈렸는데, 오늘은 공격이 되느냐 안 되느냐가 갈립니다.

C 카테고리의 SPA를 D 카테고리에서 Next로 옮겼을 때, 우리는 속도와 검색 노출을 얻었습니다. 그런데 같은 이동으로 <script>가 도는 조건까지 함께 얻었어요. 아무도 안 알려줬죠.

재는 방법이 답을 바꿉니다

위 콘솔 코드에서 await new Promise(...) 줄을 빼고 다시 돌려보세요. onerror 가 돌았나가 false로 나옵니다.

이미지 로드가 실패하는 데 시간이 걸리기 때문이에요. 기다리지 않고 바로 읽으면 아직 안 돈 상태를 읽습니다.

이 과목에서 반복해서 만난 이야기죠. 이상한 결과가 나오면 코드보다 재는 쪽을 먼저 의심해야 하는데, 여기서는 안 기다린 것이 "안전하다"라는 정반대 결론을 만들 수 있었습니다.

💡 한 줄 정리

<script>는 문서를 처음 읽을 때만 실행되고, 이벤트 속성은 언제나 실행됩니다. 한 가지 문자열로만 시험하면 뚫린 것을 막혔다고 읽게 돼요.

Step 4: "훔칠 수 있는 것과 없는 것"

탭 제목을 바꾸는 건 장난이죠. 실제로 무엇을 할 수 있는지 끝까지 가봅시다.

로그인한 상태에서 콘솔을 열고 재보는데, 지금부터 하는 일은 전부 댓글에 심어둔 스크립트가 할 수 있는 일이에요.

먼저 훔쳐보겠습니다

console.log('세션 쿠키를 읽을 수 있나 :', document.cookie.includes('session_token'));
console.log('document.cookie 전체    :', document.cookie);

결과는 이렇습니다.

 세션 쿠키를 읽을 수 있나 : false
 document.cookie 전체    : (세션 쿠키는 여기 없다)

못 읽습니다. G-1에서 세션 쿠키에 HttpOnly를 붙였기 때문이에요. 그때 이렇게 정리했었죠.

 HttpOnly        페이지의 자바스크립트가 못 읽는다

그 약속이 지금 지켜지고 있습니다. 남이 심은 스크립트가 우리 페이지에서 돌고 있는데도 세션은 못 가져가요.

C-6에서 미뤄뒀던 이야기도 여기서 갚아집니다. 그때 SPA는 토큰을 localStorage에 뒀고, 그건 페이지의 자바스크립트가 다 읽을 수 있다고 했었죠. 지금 우리 Next 앱에는 그렇게 둔 토큰이 아예 없습니다. 백엔드 출입증은 G-3에서 서버가 들고 있게 바꿨으니까요.

그러니 훔쳐갈 게 없어서, 여기까지는 좋은 소식이에요.

그런데 훔치지 않고도 할 수 있습니다

같은 콘솔에서 이어서 해봅시다.

const 나 = await fetch('/api/auth/get-session', { credentials: 'same-origin' })
  .then((r) => r.json());
console.log('서버는 나를 누구로 아나 :', 나?.user?.username);

 서버는 나를 누구로 아나 : jaehoon

토큰은 못 읽었는데 서버는 재훈으로 알아봅니다.

당연한 일이에요. 쿠키를 못 읽는 것과 쿠키가 요청에 안 실리는 것은 다른 이야기니까요. HttpOnly는 읽기만 막는데, 브라우저는 여전히 우리 서버로 가는 모든 요청에 그 쿠키를 자동으로 실어 보내요.

즉 남이 심은 스크립트는 재훈의 신원을 손에 쥐지 않은 채로 재훈처럼 행동할 수 있습니다.

얼마나 할 수 있는지 봅시다

댓글 폼이 화면에 있으니까, 그걸 대신 제출시켜 보겠습니다.

const 입력 = document.querySelector('#comment-2');
const 폼 = 입력.closest('form');

입력.value = '제가 안 쓴 댓글입니다';
입력.dispatchEvent(new Event('input', { bubbles: true }));
폼.requestSubmit();

잠시 뒤 2번 게시물의 댓글을 확인하면 이렇습니다.

 @jaehoon  3박 4일이면 넉넉했나요?
 @jaehoon  제가 안 쓴 댓글입니다

재훈 이름으로 댓글이 달렸는데, 재훈은 아무것도 안 눌렀어요.

여기서 D-8에서 한 이야기를 떠올려보세요. 그때 우리는 서버 액션마다 currentUser()로 신원을 확인하도록 했습니다. 지금 그 확인이 정상적으로 통과했어요. 서버 입장에서는 재훈의 브라우저에서 온, 재훈의 세션이 실린, 정상적인 요청이거든요.

서버는 이걸 구분할 방법이 없습니다.

정리하면

G-3 마지막에 "뒷문이 한 칸 옮겨갔다"고 했던 것과 같은데, 막았다고 생각한 것이 실제로는 한 칸 옮겨간 것뿐이었죠.

 훔쳐가기        HttpOnly 가 막는다        →  못 가져간다
 그 신원으로 행동  HttpOnly 는 상관 없다     →  다 된다

그러니 HttpOnly를 붙였다고 XSS를 막은 게 아닙니다. 그건 털린 뒤의 피해를 줄이는 장치예요. 세션이 통째로 유출되면 공격자는 자기 컴퓨터에서 시간을 두고 재훈 행세를 할 수 있지만, 그게 막히면 재훈이 우리 페이지를 열고 있는 동안만 할 수 있습니다.

피해 범위는 줄었어요. 그런데 우리 페이지에서 남의 코드가 도는 것 자체는 그대로이니까, 그건 다른 방법으로 막아야 합니다.

💡 한 줄 정리

HttpOnly는 읽어가는 것을 막지 그 신원으로 행동하는 것을 못 막습니다. 쿠키가 안 보여도 요청에는 실려 나가니까요.

Step 5: "그리기 직전에 걸러냅니다"

이제 고칩니다.

방향은 Step 3의 질문에서 이미 정했어요. 막을 것을 나열하지 않고 허용할 것을 나열합니다. 우리가 댓글에 필요한 건 줄바꿈과 굵게, 그리고 링크 정도죠. 그것만 남기고 나머지는 전부 지웁니다.

이 일을 하는 것을 살균(sanitization)이라고 부릅니다.

브라우저에 이 기능이 들어왔습니다

반가운 소식부터 말씀드릴게요. 2026년에 브라우저가 이 일을 직접 해주기 시작했는데, 그 이름이 Element.setHTML()이에요.

콘솔에서 재볼 수 있습니다.

const d = document.createElement('div');
d.setHTML('<b>굵게</b><img src=x onerror="1"><script>1<\/script><a href="javascript:alert(1)">링크</a>');
console.log(d.innerHTML);

 <b>굵게</b><a>링크</a>

<script>도 사라지고 <img>도 사라지고, <a>는 남았는데 href만 떨어져 나갔습니다. 우리가 아무 설정도 안 줬는데요.

이 함수가 좋은 이유는 브라우저가 직접 하기 때문입니다. 브라우저는 자기가 HTML을 어떻게 읽는지 정확히 아는데, 라이브러리는 그걸 바깥에서 흉내 내야 하고, 흉내에는 늘 어긋나는 구석이 생깁니다.

그런데 우리 앱에서는 못 씁니다

우리 댓글은 서버 컴포넌트가 그립니다. 서버에서 확인해보면 이래요.

node -e "console.log('Element:', typeof globalThis.Element)"

 Element: undefined

서버에는 Element가 없는데, document도 Sanitizer도 없어요. 당연합니다. 그건 브라우저가 가진 것이지 Node가 가진 게 아니니까요.

D-3에서 그은 선이 여기서 또 나옵니다. 브라우저에 새 기능이 생겼다는 소식은 브라우저에서 그리는 코드에만 도착하는데, 우리는 서버에서 그리기로 정했으니 그 소식이 우리에게 안 닿습니다.

그러니 갈라서 기억하세요.

 화면을 브라우저가 그린다   →  브라우저 내장 setHTML 을 쓸 수 있다
                              (다만 사파리가 아직 없어서 대비가 필요하다)
 화면을 서버가 그린다       →  서버에서 도는 도구가 필요하다  ← 우리

서버에서 걸러냅니다

서버에서 도는 살균 도구를 들입니다.

npm install --workspace apps/web-next isomorphic-dompurify

다음으로 우리 댓글에 맞는 허용목록을 정합니다.

// apps/web-next/lib/sanitize.ts
import DOMPurify from 'isomorphic-dompurify';

/**
 * 댓글에 허용할 서식. 여기 없는 것은 전부 지운다.
 *
 * 목록을 넓게 잡을수록 나중에 후회한다. 지금 필요한 것만 적었다.
 * 댓글에 이미지가 빠진 것은 우리가 필요 없다고 정한 것이지 img 가 위험해서가 아니다.
 */
const ALLOWED_TAGS = ['b', 'i', 'strong', 'em', 'br', 'a'];
const ALLOWED_ATTR = ['href'];

/**
 * 저장된 댓글을 화면에 그리기 직전에 통과시킨다.
 *
 * 브라우저에도 같은 일을 하는 기능이 생겼지만(`Element.setHTML`) 그건 브라우저 API 다.
 * 댓글은 서버 컴포넌트가 그리고 서버에는 그 함수가 없다 — 그래서 여기서 한다.
 *
 * 쓸 때가 아니라 그릴 때 하는 이유는, 우리가 이 함수를 만들기 전에 저장된 것도 있고
 * 다른 경로로 들어온 것도 있기 때문이다. 화면으로 나가는 길목이 마지막 관문이다.
 */
export function sanitizeComment(raw: string): string {
  return DOMPurify.sanitize(raw, { ALLOWED_TAGS, ALLOWED_ATTR });
}

화면에서는 한 번 거쳐서 넣습니다.

// apps/web-next/app/components/CommentSection.tsx
          <li key={comment.id} className="text-sm">
            <span className="mr-1 font-semibold">@{comment.username}</span>
            {/* 여전히 HTML 로 넣는다. 달라진 것은 넣기 전에 한 번 거른다는 것뿐이다.
                이 함수를 빼면 이 줄은 그대로 오늘 오전의 그 줄이 된다. */}
            <span dangerouslySetInnerHTML={{ __html: sanitizeComment(comment.content) }} />
          </li>

새로고침해보세요.

 탭 제목:  인스타그램 클론          ← 안 바뀐다
 @minji   첫 줄
          둘째 줄 그리고 강조        ← 서식은 그대로 산다
 @minji   사진 좋네요               ← 스크립트만 사라졌다

서식은 살아남고 공격은 사라졌는데, 우리가 얻고 싶었던 것만 남았어요.

두 도구의 기본값이 다릅니다

여기서 짚고 갈 게 있어요. 아까 브라우저 내장 함수로 재본 것과 방금 라이브러리로 한 것을 같은 입력으로 나란히 놓으면 이렇습니다.

세 군데가 갈립니다. 둘 다 "살균"이라고 부르는데 결과가 달라요.

그러니 살균에는 하나의 정답이 없습니다. 도구가 정해둔 기본값이 있고, 그 기본값이 우리 서비스에 맞는지는 우리가 판단해야 해요. 브라우저 내장 함수를 아무 설정 없이 썼다면 사용자가 올린 이미지가 조용히 사라졌을 겁니다. 오류도 경고도 없이요.

우리가 위에서 허용목록을 직접 적은 이유가 이겁니다. 기본값에 맡기지 않고 우리 댓글에 필요한 것을 우리가 정했어요.

브라우저는 이 무게를 안 받습니다

마지막으로 하나 확인하고 갑시다. 방금 설치한 도구는 브라우저를 흉내 내는 코드까지 딸려와서 꽤 무거워서, 설치 폴더가 14MB 정도 늘어요.

그런데 빌드하고 브라우저가 받아가는 파일을 뒤져보면 이 도구의 흔적이 한 건도 없습니다. 서버 쪽 번들에만 있어요.

D-3에서 잰 것과 같은 이야기입니다. 경계 밖으로는 자바스크립트가 안 가요. 살균을 서버에서 하기로 한 덕분에 사용자는 이 무게를 한 바이트도 안 받습니다.

서버에서 그리기로 한 결정이 여기서 값을 합니다. 브라우저 내장 함수를 못 쓰게 만든 그 결정이요.

💡 한 줄 정리

막을 것을 나열하지 말고 허용할 것을 나열하세요. 그 목록의 기본값은 도구마다 다르니, 우리 서비스에 맞는지는 우리가 정해야 합니다.

마무리

오늘 배운 핵심 세 가지

💡 하나. 안전했던 게 아니라 안전한 방법을 쓰고 있었습니다. 45일 동안 이 문제를 안 만난 건 중괄호로 값을 넣었기 때문입니다. React를 쓴 덕이 아니라 그 방법을 쓴 덕이에요. 방법을 바꾼 순간 문제가 나타났습니다.

💡 둘. 한 가지로 시험하면 거짓 안심을 얻습니다. <script>는 서버가 그릴 때만 돌고, 이벤트 속성은 언제나 도는데, 막을 목록을 늘리는 방향으로는 못 이겨요. 허용할 목록을 좁게 잡는 쪽이 이깁니다.

💡 셋. 막았다는 말은 대개 이 경로를 막았다는 뜻입니다. HttpOnly는 훔쳐가는 것을 막았지 그 신원으로 행동하는 것은 못 막았어요. 지난 시간의 뒷문 이야기와 같은 구조입니다. 한 겹을 막았으면 그다음 겹을 물어봐야 합니다.

다음 시간 예고

오늘 우리는 구멍 하나를 막았는데, 댓글이라는 구멍이었어요.

여기서 이렇게 물어보실 수 있습니다. 우리 앱에 구멍이 그것 하나뿐이라고 어떻게 확신하죠?

못 해요. 화면은 계속 늘어나고 입력칸도 늘어나고, 나중에 들어온 사람이 dangerouslySetInnerHTML을 한 줄 더 쓸 수도 있어서, 구멍을 하나씩 막는 방식으로는 마지막 구멍을 찾았다고 말할 수가 없습니다.

그래서 다음 시간에는 방향을 뒤집습니다. 구멍을 찾아다니는 대신, 브라우저에게 미리 알려두는 방법을 봐요. "이 페이지에서는 우리가 허락한 곳의 코드만 실행해라"라고요. 그러면 우리가 못 찾은 구멍으로 뭔가 들어와도 실행되지는 않습니다.

그리고 그 뒤에 하나 더 봅니다. 오늘은 남이 우리 페이지 안에서 코드를 돌렸죠. 그다음 시간에는 남의 사이트가 자기 쪽에서 우리 앱으로 요청을 보내는 경우를 봐요. 그중 하나는 이미 막혀 있고 하나는 활짝 열려 있는데, 열려 있는 쪽은 D-7에서 우리가 직접 만든 것이에요.

과제

[구현] 저장할 때도 걸러보기

Step 5의 🙋 에서 저장할 때 거르는 것과 그릴 때 거르는 것을 이야기했습니다. 이번엔 둘 다 해봅시다.

addComment 액션에서 서버로 보내기 전에 sanitizeComment를 한 번 통과시키고, 다음 두 가지를 확인해보세요.

1. 새로 단 댓글이 연습용 서버에 어떤 모양으로 저장되는지 직접 확인합니다. 저장된 값 자체가 달라져야 해요.
2. 그 상태에서 CommentSection의 sanitizeComment를 잠깐 빼보세요. 오늘 오전에 넣어둔 공격 댓글은 어떻게 되나요? 새로 단 댓글은요?

2번의 결과가 이 과제의 핵심입니다. 왜 그릴 때 거르는 것을 뺄 수 없는지가 눈에 보일 거예요. 확인한 뒤에는 뺐던 것을 다시 넣어두세요.

[구현] 링크를 허용했더니

우리 허용목록에는 a 태그와 href 속성이 들어 있습니다. 그러니 댓글에 링크를 넣을 수 있어요.

그런데 링크의 주소에는 https://만 들어가는 게 아닙니다. 다음 댓글을 넣어보세요.

<a href="javascript:document.title='링크로도 되네'">눌러보세요</a>

화면에 링크가 보이나요? 눌러보면 어떻게 되나요? 소스 보기에서 그 링크의 href가 어떻게 되어 있는지도 확인해보세요.

결과를 봤으면 이제 도구를 시험해봅시다. 아래 넷을 차례로 넣고, 각각 href가 살아남는지 적으세요.

<a href="JaVaScRiPt:alert(1)">대소문자를 섞으면</a>
<a href="  javascript:alert(1)">앞에 공백을 넣으면</a>
<a href="data:text/html,<b>hi</b>">다른 종류의 주소면</a>
<a href="https://example.com">평범한 주소면</a>

넷 중 몇 개가 통과하나요? 통과 여부를 가르는 기준이 무엇인지도 말로 적어보세요.

마지막으로 답해보세요. 우리가 ALLOWED_ATTR에 href를 넣은 것은 위험한 결정이었나요? 그 판단의 근거는 우리가 잘 정한 것인가요, 아니면 다른 무언가가 한 겹 더 해주고 있는 것인가요?

[탐구] 두 도구를 같은 입력으로 재보기

Step 5의 표를 직접 만들어봅시다. 아래 입력들을 브라우저 콘솔의 setHTML과 서버의 DOMPurify.sanitize(설정 없이 기본값으로) 양쪽에 넣고 결과를 적으세요.

<b style="color:red">빨강</b>
<img src="https://picsum.photos/seed/a/64">
<div onclick="1">눌러보세요</div>
<iframe src="https://example.com"></iframe>
첫 줄<br>둘째 줄<p>문단</p>

서버 쪽은 이렇게 재면 됩니다.

node --input-type=module -e "
import DOMPurify from 'isomorphic-dompurify';
console.log(DOMPurify.sanitize('여기에 넣으세요'));
"

표를 채운 뒤 몇 군데가 갈리는지 세어보고, 그중에서 우리 인스타그램 클론에 실제로 문제가 될 만한 것이 있는지 판단해보세요.

[탐구] 우리 앱을 전수 점검하기

오늘은 댓글 하나를 고쳤습니다. 그런데 우리 앱에는 사용자가 값을 넣을 수 있는 통로가 더 있어요.

apps/web-next 전체에서 dangerouslySetInnerHTML을 찾아보세요. 몇 건이 나오나요?

그다음, 사용자 입력이 화면 어디에 그려지는지 직접 세어보세요. 회원가입 폼의 오류 메시지, 프로필 주소의 사용자 이름, 검색칸에 친 글자 같은 것들요. 각각이 어떤 방법으로 화면에 들어가는지 확인하고, 오늘 배운 기준으로 안전한지 판단해보세요.

이 과제의 목적은 목록을 만드는 게 아닙니다. 찾는 방법을 익히는 것이에요. 새 화면을 만들 때마다 이걸 할 수 있어야 합니다.

생각해볼 주제

1. 마크다운이면 안전할까요

댓글에 서식을 넣는 방법으로 마크다운을 쓰는 서비스가 많습니다. 사용자는 **굵게**라고 쓰고, 서버나 브라우저가 그걸 <b>굵게</b>로 바꿔서 화면에 넣죠.

이렇게 하면 사용자가 태그를 직접 못 쓰니까 오늘 문제가 안 생길 것처럼 보입니다. 정말 그럴까요?

마크다운을 HTML로 바꾸는 과정에서 무엇이 일어나는지 생각해보고, 마크다운 문법 중에 주소를 받는 것이 있는지도 떠올려보세요.

2. 우리가 만든 게 아닌 구멍

오늘 우리가 고친 곳은 우리가 직접 쓴 코드였지만, 실무에서는 우리가 안 쓴 코드가 화면에 들어오는 경우가 있어요.

E-5에서 디자인 시스템 컴포넌트를 복사해 들여왔던 것을 떠올려보세요. 그때 우리는 그 파일들을 읽어봤습니다. 만약 그중 하나가 받은 값을 HTML로 넣고 있었다면, 우리는 그걸 알았을까요?

그리고 복사가 아니라 설치해서 쓰는 라이브러리라면요. 광고 스크립트나 분석 도구처럼 남의 서버에서 받아오는 코드는요?

이 질문들에 대해 우리가 할 수 있는 일과 할 수 없는 일을 갈라보세요.

3. 왜 사용자가 서식을 원할까요

오늘 이 모든 문제의 출발점은 "댓글에 줄바꿈이 안 돼요"라는 요청 하나였습니다.

그 요청을 받았을 때 우리에게는 선택지가 여럿 있었어요. HTML로 넣기, CSS로 줄바꿈만 살리기, 마크다운 쓰기, 그냥 안 해주기.

우리는 첫 번째를 골랐고 그 대가로 오늘 하루를 썼습니다. 만약 두 번째를 골랐다면 어땠을까요?

요구사항을 그대로 받는 것과 요구사항 뒤에 있는 목적을 보는 것이 어떻게 다른지 생각해보고, 여러분이 실제로 이 요청을 받았다면 무엇을 되물어봤을지도 생각해보세요.