G-6: 프론트엔드 보안 ③ — 바깥과의 경계

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

이런 장면을 하나 그려볼게요.

여러분이 우리 인스타 클론에 로그인해 둔 채로, 다른 탭에서 처음 보는 사이트를 엽니다. 광고 링크를 눌렀거나, 누가 보내준 주소를 열었거나요. 그 사이트에는 버튼이 하나 있고 "무료 이벤트 응모"라고 적혀 있어요. 눌러봅니다.

아무 일도 안 일어난 것처럼 보입니다. 그런데 그 순간 그 사이트는 여러분 브라우저를 시켜 우리 앱으로 요청을 하나 보냈습니다. 여러분의 로그인 쿠키를 달고서요.

지난 시간에 우리는 브라우저에게 규칙을 미리 알려뒀습니다. 우리 페이지에서 남의 코드가 도는 걸 막는 규칙이었죠. 방금 장면에서는 코드가 우리 페이지에서 안 돌고, 요청이 바깥에서 날아왔어요. 우리가 붙인 헤더는 여기에 손을 못 댑니다.

오늘은 그 바깥과의 경계를 봅니다. 먼저 지난 시간에 세운 규칙이 실제로 무엇을 막았는지 눈으로 확인하고, 그다음 그 규칙이 원리적으로 못 막는 것으로 넘어갑니다.

 오늘의 여정

 1. 지난 시간의 규칙이 무엇을 막았나 → 막긴 막는데 구멍은 그대로다
 2. 남의 사이트가 대신 보낸다 → 하나는 이미 막혀 있고 하나는 열려 있다
 3. 열려 있는 쪽은 우리가 만든 문이다 → 쿠키도 없이 통과한다
 4. 그 문에 문지기를 세운다 → 쿠키로는 못 세운다
 5. 그 문지기가 쥔 비밀은 어디에 두나

💡 오늘 수업의 핵심 — "막는 방법은 무엇을 확인하느냐로 갈립니다. 사람을 확인하는 문과 서버를 확인하는 문은 다릅니다"

🎯 학습 목표

• 지난 시간에 세운 규칙이 실제로 무엇을 막고 무엇을 못 막는지 직접 재보고, 막는 것과 지우는 것의 차이를 구분합니다.
• 남의 사이트가 우리 앱으로 요청을 대신 보내는 상황을 재현하고, 서버 액션과 우리가 만든 주소가 왜 다르게 동작하는지 확인합니다.
• 우리가 연 주소에 문지기를 세우고, 그 문지기가 쥐는 값을 어디에 둬야 하는지 정합니다.

Step 1: "그 규칙이 무엇을 막았을까요"

지난 시간의 약속부터 갚습니다

지난 시간 마지막에 이렇게 말씀드렸어요. 규칙을 세우긴 했는데 그게 실제로 무엇을 막고 있는지는 아직 확인 안 했다고요.

확인해봅시다. 두 시간 전에 댓글로 밀어 넣었던 그 공격 문자열 기억하시죠.

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

이걸 다시 댓글로 넣고 홈 화면을 열어보세요. 연습용 서버가 메모리에 저장하니까, 서버를 새로 켰다면 다시 넣어야 합니다.

화면을 보면 탭 제목이 그대로예요. 인스타그램 클론입니다.

여기서 결론을 내리면 안 되는데, 지금 막고 있는 게 누구인지 아직 모르거든요.

지금은 두 겹입니다

두 시간 전에 우리는 걸러내는 코드를 넣었습니다. 그리기 직전에 위험한 태그를 지우는 코드였죠. 서버가 보낸 HTML을 직접 확인해보면 이렇습니다.

curl -s -b cookie.txt http://localhost:3000/ | grep -c "털렸습니다"

0

아예 없습니다. 태그가 통째로 지워져서 나갔어요. 이 상태에서는 지난 시간에 세운 규칙이 할 일이 없습니다. 막을 대상이 도착조차 안 하니까요.

지금 화면이 멀쩡한 건 두 겹 중 첫 번째 겹 덕분이라, 두 번째 겹이 일하는 모습을 보려면 첫 번째 겹에 구멍을 내야 해요.

걸러내는 코드를 잠깐 빼봅니다

댓글을 그리는 곳에서 걸러내는 함수를 잠시 빼보세요. 실습이 끝나면 반드시 되돌려야 합니다.

// apps/web-next/app/components/CommentSection.tsx
// 잠깐 확인하려고 걸러내기를 뺀 상태입니다. 확인 후 반드시 되돌리세요.
<span dangerouslySetInnerHTML={{ __html: comment.content }} />

이제 서버가 보내는 HTML을 다시 봅니다.

curl -s -b cookie.txt http://localhost:3000/ | grep -c "털렸습니다"

1

태그가 그대로 실려 나갑니다. 두 시간 전의 그 위험한 상태로 돌아온 거예요.

그럼 이제 탭 제목이 바뀔까요? 브라우저에서 홈 화면을 새로고침해보세요.

안 바뀝니다. 제목은 여전히 인스타그램 클론입니다.

무엇이 남아 있는지 봅니다

여기가 오늘의 첫 번째 요점입니다. 개발자 도구 콘솔에서 확인해보세요.

document.title
// '인스타그램 클론'

[...document.querySelectorAll('script')]
  .filter(s => s.textContent.includes('털렸습니다'))
  .length
// 1

제목은 안 바뀌었는데 그 태그는 문서 안에 그대로 있습니다.

지난 시간에 세운 규칙은 위험한 것을 지우지 않아요. 브라우저에게 "이건 실행하지 마라"라고 말할 뿐이라, 결과가 이렇게 갈립니다.

 걸러내기        위험한 태그를 아예 없앤다        → 문서에 안 남는다
 미리 알려두기    있는 건 그대로 두고 실행만 막는다  → 문서에 남아 있다

같은 공격을 막는데 막는 방식이 다른데, 이게 왜 중요하냐면 두 번째 방식만 있는 상태에서는 위험한 문자열이 계속 우리 데이터베이스와 화면 안에 쌓인다는 뜻이기 때문이에요. 브라우저가 실행을 안 해줄 뿐이지 없어진 게 아닙니다.

브라우저 규칙 설정이 하나 바뀌거나, 그 규칙이 안 걸리는 경로가 하나 생기면 그때 전부 되살아납니다.

그럼 우리는 이걸 어떻게 알아채나요

화면은 멀쩡하고 오류도 안 떠서 아무도 안 알려주는 것처럼 보이는데, 실제로는 브라우저가 기록을 남깁니다.

개발자 도구 콘솔을 열어두고 새로고침해보세요. 이런 줄이 뜹니다.

 위반한 규칙       script-src-elem
 차단된 대상       inline

이름을 눈여겨보세요. 우리가 헤더에 적은 이름은 script-src였는데 보고에 찍히는 이름은 script-src-elem입니다. 스크립트를 허용하는 규칙이 안쪽에서 더 잘게 나뉘어 있고, 태그로 들어온 스크립트는 그중 -elem 쪽이 담당해요. 우리가 script-src만 적으면 나뉜 것들이 그 값을 물려받습니다.

차단된 대상이 주소가 아니라 inline이라고 찍히는 것도 같이 보세요. 파일에서 불러온 게 아니라 문서 안에 직접 적혀 있던 코드라는 뜻입니다.

⚠️ 재는 방법에 함정이 하나 있습니다

콘솔에서 그 댓글이 실제로 화면에 어떻게 보이는지 확인하려고 이렇게 읽는 분이 계실 거예요.

document.querySelector('li').textContent
// '@minjidocument.title = "털렸습니다"사진 좋네요'

이걸 보면 공격 코드가 화면에 글자로 보이는 것 같은데, 아니에요.

getComputedStyle(document.querySelector('li script')).display
// 'none'

<script> 태그는 브라우저가 기본적으로 안 보이게 처리합니다. 사용자 눈에 들어오는 글자는 사진 좋네요 뿐이에요. textContent는 안 보이는 태그의 내용까지 전부 읽어주기 때문에 생긴 착시입니다.

남아 있는 곳은 문서이지 화면이 아닙니다. 이 둘을 구분해서 말해야 정확해요.

확인이 끝났으면 걸러내는 함수를 반드시 되돌려 놓으세요.

// apps/web-next/app/components/CommentSection.tsx
<span dangerouslySetInnerHTML={{ __html: sanitizeComment(comment.content) }} />

💡 한 줄 정리

지난 시간의 규칙은 실행을 막지 내용을 지우지 않습니다. 걸러내기와 함께 두 겹으로 세워야 하는 이유가 여기에 있습니다.

Step 2: "남의 사이트가 대신 보냅니다"

이번엔 코드가 우리 페이지에서 안 돕니다

지금까지 다룬 건 전부 우리 페이지 안에서 남의 코드가 도는 문제였고, 그래서 우리 페이지에 규칙을 걸어 막을 수 있었어요.

오늘 오프닝에서 그린 장면은 다릅니다. 남의 사이트가 자기 페이지에서 코드를 돌리고, 그 코드가 우리 앱으로 요청을 보냅니다. 우리 페이지는 열려 있지도 않을 수 있어요.

 지난 시간까지        남의 코드가 우리 페이지 안에서 돈다
                     → 우리 페이지에 규칙을 걸어 막는다

 오늘                남의 페이지에서 우리 서버로 요청이 온다
                     → 우리 페이지에 건 규칙은 이 요청을 못 본다

핵심은 쿠키가 자동으로 따라간다는 점입니다. 브라우저는 우리 앱 주소로 요청이 나갈 때 우리 앱 쿠키를 붙여 보내고, 누가 그 요청을 시켰는지는 안 따져서, 서버 입장에서는 로그인한 사용자가 보낸 요청과 구별이 안 갑니다.

이런 공격을 요청 위조라고 부르고, 영어 앞 글자를 따서 CSRF라고 씁니다.

팔로우 버튼을 밖에서 눌러봅니다

우리 앱에서 팔로우 버튼은 서버 액션으로 동작하죠. 두 시간 전에 확인했듯이 그건 평범한 HTML 폼이라서, 폼이 보내는 것과 똑같은 요청을 밖에서 만들어 보낼 수 있습니다.

세 가지 경우로 나눠 보내볼게요. 우리 사이트에서 보낸 것처럼, 남의 사이트에서 보낸 것처럼, 그리고 출처를 아예 안 밝히고요.

요청을 보낼 때 브라우저는 Origin이라는 헤더에 "이 요청은 어느 사이트에서 시작됐다"를 적어서 보냅니다. 이 값을 바꿔가며 시험합니다.

# 남의 사이트에서 보낸 것처럼
curl -X POST -H 'Origin: https://evil.example.com' \
  -b cookie.txt -F '...' http://localhost:3000/minji

결과가 이렇게 갈립니다.

 우리 Origin       요청 성공       연습용 서버에 팔로우 요청이 도착함
 남의 Origin       500 오류        연습용 서버에 아무것도 안 도착함
 Origin 없음       요청 성공       연습용 서버에 팔로우 요청이 도착함

가운데 줄을 보세요. 막혔는데, 우리는 이걸 막는 코드를 한 줄도 안 썼어요.

이미 막고 있던 사람이 있었습니다

터미널에서 앱 서버 로그를 보면 이유가 적혀 있습니다.

`x-forwarded-host` header with value `localhost:3000` does not match
`origin` header with value `evil.example.com` from a forwarded Server
Actions request. Aborting the action.

우리가 쓰는 프레임워크가 서버 액션 요청마다 두 값을 맞춰봅니다. 요청이 도착한 우리 주소와, 요청을 시작했다고 적힌 출처요. 둘이 다르면 함수를 아예 안 부르고 중단시킵니다.

이건 우리가 켠 기능이 아니라 기본 동작이에요. 서버 액션이 주소 없이 함수로만 불린다는 점을 이용해서, 프레임워크가 그 통로 전체에 검사를 하나 걸어둔 겁니다.

그런데 세 번째 줄이 남았습니다

Origin을 아예 안 보낸 경우는 통과했습니다. 로그에는 이렇게 남아요.

⚠ Missing `origin` header from a forwarded Server Actions request.

경고만 하고 실행합니다. 왜 이렇게 만들었을까요. 브라우저가 아닌 것들이 보내는 요청에는 Origin이 원래 없는 경우가 많거든요. 서버끼리 주고받는 요청이나 명령줄 도구가 그렇습니다. 그것들까지 전부 막으면 정상적인 사용이 깨집니다.

여기서 오해하기 쉬운 게 있어요. "그럼 공격자가 Origin을 빼고 보내면 뚫리는 거 아닌가요?"라고 생각하기 쉬운데, 브라우저를 통한 공격에서는 그게 안 됩니다. Origin 헤더는 브라우저가 붙이고, 페이지의 자바스크립트는 이 값을 지우거나 바꿀 수 없어요.

지금 우리가 curl로 뺄 수 있는 건 우리가 브라우저를 안 쓰고 있기 때문이고, 그때는 피해자의 쿠키도 없죠. 오프닝에서 그린 장면의 핵심은 피해자의 브라우저를 시키는 것이었고, 그 경로에서는 Origin이 반드시 붙습니다.

💡 한 줄 정리

서버 액션으로 가는 길은 프레임워크가 출처를 대조해서 막아줍니다. 우리가 켠 게 아니라 기본으로 켜져 있습니다.

Step 3: "우리가 연 문은 어떨까요"

D-7에서 만든 그 주소

기억을 되살려볼게요. D-7에서 우리는 화면을 그리지 않는 주소를 하나 만들었습니다. 파일 이름이 page가 아니라 route였죠.

// apps/web-next/app/api/profiles/revalidate/route.ts
export async function POST(request: Request) {
  const username = new URL(request.url).searchParams.get('username');
  // ...
  revalidateTag(`profile:${username}`, 'max');
  return Response.json({ success: true, data: { username }, message: null });
}

만든 이유는 이랬습니다. 백엔드에서 어떤 사람의 정보가 바뀌었을 때 우리에게 알려달라고 열어둔 문이에요. 알려주면 우리가 굳혀둔 화면을 버리고 새로 만듭니다.

이 문을 밖에서 두드려봅시다.

네 가지 경우 전부 두드립니다

curl -X POST -H 'Origin: https://evil.example.com' \
  'http://localhost:3000/api/profiles/revalidate?username=jaehoon'

 우리 Origin + 쿠키              200
 남의 Origin + 쿠키              200
 Origin 없음 + 쿠키              200
 남의 Origin + 쿠키조차 없음      200

전부 200입니다. 마지막 줄을 보세요. 로그인도 안 했고, 남의 사이트에서 보냈는데 통과합니다.

응답도 정상이에요.

{"success":true,"data":{"username":"jaehoon"},"message":null}

Step 2에서 서버 액션이 막히던 것과 정반대죠. 같은 앱, 같은 서버인데 한쪽은 막히고 한쪽은 열려 있습니다.

이유는 단순합니다. 프레임워크가 서버 액션 통로에 걸어둔 검사는 서버 액션에만 걸려요. 우리가 손으로 만든 주소는 그 통로가 아닙니다. 우리가 연 문이니까 문지기도 우리가 세웠어야 하는데, 그때는 안 세웠습니다.

⚠️ 여기서 시험 방법을 잘못 잡기 쉽습니다

이 주소를 시험할 때 이렇게 보내는 분이 많습니다.

curl -X POST -H 'Content-Type: application/json' \
  -d '{"username":"jaehoon"}' \
  http://localhost:3000/api/profiles/revalidate

{"success":false,"data":null,"message":"username 이 필요합니다"}

400이 돌아옵니다. 이걸 보고 "막혀 있네"라고 결론 내리기 딱 좋아요.

그런데 이건 막힌 게 아닙니다. 이 주소는 이름을 주소 뒤 물음표 뒤에서 읽도록 만들어져 있어요. 위 코드의 searchParams 부분이 그겁니다. 본문에 JSON으로 넣으면 아무도 안 읽으니까 "이름이 없다" 고 답하는 거예요.

막혀서 나온 400이 아니라 이름을 못 찾아서 나온 400입니다. 문은 활짝 열려 있고, 제가 문을 안 두드리고 벽을 두드린 것뿐이에요.

시험할 때는 그 주소가 값을 어디서 읽는지 먼저 확인하세요. 짐작해서 보내면 열려 있는 문을 닫혀 있다고 기록하게 됩니다.

이 문의 정체를 다시 봅니다

문지기를 세우기 전에 하나 정리하고 갑시다. 이 문은 사람이 두드리는 문이 아닙니다.

파일 위에 우리가 적어둔 주석에 답이 있어요. 백엔드에서 정보가 바뀌었을 때 알려주는 문이라고 했으니, 이 문을 정상적으로 두드리는 쪽은 사용자의 브라우저가 아니라 백엔드 서버입니다.

이게 다음 Step을 정합니다. 브라우저가 없는 쪽을 상대하는 문이라, 세션 쿠키로는 확인할 방법이 없어요.

💡 한 줄 정리

프레임워크가 만들어준 통로는 프레임워크가 지켜주지만, 우리가 직접 연 주소는 우리가 지켜야 합니다.

Step 4: "그 문에 문지기를 세웁니다"

쿠키로는 못 세웁니다

가장 먼저 떠오르는 방법은 로그인 확인일 거예요. 우리가 앞에서 여러 번 쓴 방법이니까요.

그런데 안 됩니다. Step 3 끝에서 확인했듯이 이 문을 두드리는 쪽은 백엔드 서버라, 서버에는 브라우저가 없고 브라우저가 없으면 쿠키도 없어요. 로그인 확인을 붙이면 공격자를 막는 게 아니라 정상적인 백엔드를 막게 됩니다.

Origin 검사는 어떨까요. 이것도 안 맞습니다. 같은 이유예요. 서버끼리 주고받는 요청에는 Origin이 원래 없습니다. Step 2에서 프레임워크가 Origin 없는 요청을 통과시킨 것과 같은 사정이에요.

그래서 이 문에서 확인해야 할 건 "누가 눌렀나"가 아니라 "어느 서버가 말하나"입니다.

 사람을 확인하는 문      세션 쿠키를 본다      → 화면, 서버 액션
 서버를 확인하는 문      약속한 비밀을 본다     → 오늘 이 주소

우리 서버와 백엔드만 아는 값

방법은 이렇습니다. 우리 서버와 백엔드가 같은 값을 하나 나눠 갖고, 백엔드가 문을 두드릴 때 그 값을 함께 내밉니다. 값이 맞으면 통과, 아니면 거절이에요.

G-3 마지막에 이 이야기를 꺼냈던 것 기억하시나요. 그때 마지막 질문에서 뒷문이 완전히 닫힌 게 아니라 한 칸 옮겨갔다고 했고, 진짜 서비스에서는 서버가 서버에게 자기를 증명한다고 했습니다. 그 방법이 지금 쓰는 이것입니다.

코드로 옮기면 이렇습니다.

// apps/web-next/app/api/profiles/revalidate/route.ts
export async function POST(request: Request) {
  // 이 문을 두드리는 쪽에는 브라우저가 없다. 그래서 세션 쿠키로는 누구인지 확인할 수 없다.
  // 대신 우리 서버와 백엔드만 아는 값을 헤더로 받아 맞춰본다.
  //
  // 값을 안 정해두면 아무도 못 들어온다. 열어두는 것보다 닫아두는 쪽이 안전하다.
  const expected = process.env.REVALIDATE_SECRET;

  if (expected === undefined || request.headers.get('x-revalidate-secret') !== expected) {
    return Response.json(
      { success: false, data: null, message: '허락되지 않은 요청입니다' },
      { status: 401 },
    );
  }

  const username = new URL(request.url).searchParams.get('username');
  // 아래는 그대로입니다

검사를 맨 위에 뒀다는 점을 보세요. 이름을 읽기 전에 먼저 걸러냅니다. D-8에서 문지기의 검사 순서를 정할 때와 같은 판단이에요. 통과 못 할 요청에 일을 시키지 않습니다.

다시 두드려봅니다

이제 아까와 같은 방법으로 두드려보세요.

 비밀 맞음(백엔드가 부르는 방식)      200
 비밀 없음 + 남의 Origin             401
 비밀 없음 + 우리 세션 쿠키까지 있음    401
 비밀 틀림                          401
 비밀 맞음 + 이름 없음               400

세 번째 줄이 오늘 Step의 결정타입니다. 로그인한 사람의 쿠키를 그대로 들고 가도 401입니다.

당연해 보이지만 중요해요. 이 문은 사용자를 확인하는 문이 아니라는 걸 코드가 실제로 그렇게 동작한다는 뜻이니까요. 오프닝에서 그린 장면, 그러니까 피해자의 브라우저를 시켜서 쿠키를 달고 보내는 공격이 여기서는 통하지 않습니다. 브라우저는 우리 비밀을 모르거든요.

마지막 줄도 보세요. 비밀이 맞으면 그 뒤로 넘어가고, D-7에서 만든 이름 검사가 그대로 살아 있습니다. 문지기를 세우면서 원래 있던 동작을 안 건드렸어요.

비밀을 안 정해두면 어떻게 될까요

REVALIDATE_SECRET을 아예 안 정해둔 채로 두드려보면 이렇습니다.

 헤더 없음          401
 아무 헤더나 넣어봄   401
 빈 값 헤더         401

전부 막힙니다. 정해둔 값이 없으면 아무도 못 들어옵니다.

이건 의도한 동작이에요. 설정을 빠뜨렸을 때 문이 열린 채로 있는 것과 닫힌 채로 있는 것 중에 고르라면 닫힌 쪽이 낫습니다. 열려 있으면 아무도 모르고, 닫혀 있으면 백엔드 담당자가 바로 연락하거든요.

💡 한 줄 정리

문지기가 무엇을 확인할지는 그 문을 누가 두드리는지가 정합니다. 브라우저가 없는 쪽을 상대하는 문은 쿠키로 못 지킵니다.

Step 5: "그 비밀은 어디에 둘까요"

코드 안에 적으면 안 됩니다

Step 4에서 우리는 process.env.REVALIDATE_SECRET을 읽었어요. 파일에 값을 직접 적지 않았습니다. 왜 그랬을까요.

코드에 직접 적으면 그 값이 소스 저장소에 들어갑니다. 저장소를 볼 수 있는 사람은 전부 그 값을 알게 되고, 값을 바꾸려면 코드를 고쳐서 다시 배포해야 해요. 개발용과 운영용을 다르게 쓸 수도 없어서, 이런 값은 코드 밖에 두고 실행할 때 읽어옵니다. D-10에서 주소를 그렇게 다뤘던 것과 같은 방법이에요.

우리 저장소에는 다른 사람이 따라 할 수 있게 예시 파일을 둡니다.

# apps/web-next/.env.example

# 백엔드가 "이 사람 정보가 바뀌었다" 고 알려올 때 함께 내미는 값.
# 우리 서버와 백엔드만 알아야 한다 — 브라우저로 나가면 안 된다.
#   openssl rand -base64 32
REVALIDATE_SECRET=여기에-직접-만든-값을-넣으세요

실제 값은 .env.local에 넣고, 이 파일은 저장소에 안 올라갑니다.

이름 하나로 운명이 갈립니다

여기가 이 Step의 핵심입니다. 우리가 쓰는 프레임워크에는 규칙이 하나 있어요.

환경 변수 이름이 NEXT_PUBLIC_으로 시작하면 그 값은 브라우저로 나갈 수 있게 됩니다. 그렇지 않으면 무슨 수를 써도 서버에만 남아요.

 REVALIDATE_SECRET               브라우저로 나갈 길이 없다
 NEXT_PUBLIC_REVALIDATE_SECRET   나갈 수 있다 — 읽는 코드가 브라우저로 가면

두 번째 줄을 정확히 읽어야 합니다. 이름을 그렇게 짓는 것만으로 값이 자동으로 새어 나가지는 않아요. 그 값을 읽는 코드가 브라우저로 실려 갈 때 비로소 값이 그 파일 안에 글자 그대로 박힙니다.

D-3에서 그은 선이 여기서 다시 나옵니다. 그때 'use client'가 긋는 선이 가져오기를 따라 내려간다고 했죠. 값이 새는 조건도 똑같아요. 그 선 안쪽에서 읽으면 새고, 바깥에서만 읽으면 안 샙니다.

위험해지려면 두 가지가 동시에 필요합니다. 이름이 NEXT_PUBLIC_으로 시작할 것, 그리고 그 값을 브라우저로 가는 코드가 읽을 것이요.

둘이 만나면 개발자 도구를 열어 파일을 뒤지는 누구나 그 값을 읽을 수 있고, Step 4에서 세운 문지기는 아무 의미가 없어집니다. 공격자가 값을 보고 그대로 헤더에 넣으면 되니까요.

무서운 건 아무것도 안 깨진다는 점입니다. 빌드도 되고, 타입 검사도 통과하고, 백엔드도 정상 동작하고, 화면도 멀쩡해요. 오늘 우리 과제가 이 둘을 하나씩 붙여가며 확인합니다.

우리 앱을 확인해봅니다

그럼 우리 앱에는 이런 이름이 몇 개나 있을까요. 세어봅시다.

grep -rn "NEXT_PUBLIC_" app lib proxy.ts next.config.ts .env.example

0

한 개도 없습니다.

여기서 잠깐 멈춰야 해요. 0이 나왔을 때 두 가지 가능성이 있습니다. 진짜로 없는 것과, 명령이 제대로 안 돌아서 아무것도 못 찾은 것이요. 둘 다 화면에는 0으로 똑같이 보입니다.

같은 명령이 실제로 뭔가를 찾아내는지 확인해보세요, 반드시 있는 걸로요.

grep -rn "process.env" app lib proxy.ts next.config.ts | wc -l

4

찾습니다. 아까 0은 그러니 진짜 0이에요. 앞으로도 "없다"를 근거로 뭔가를 결론 내릴 때는 이렇게 한 번 더 확인하는 습관을 들이세요.

찾아낸 네 곳이 전부 서버에서만 읽는 값입니다. 백엔드 주소, 소셜 로그인 열쇠 두 개, 그리고 개발 서버인지 판단하는 값이요.

D-10에서 넘겨둔 숙제

D-10에서 앱을 컨테이너에 담을 때 이 이야기를 잠깐 꺼내고 넘어갔습니다. 그때 표로 정리했던 걸 이제 채울 수 있어요.

 서버에서 읽는 값        실행할 때 정해진다
                        이미지 하나로 개발용·운영용을 다르게 띄울 수 있다
                        방문자가 볼 수 없다

 NEXT_PUBLIC_ 값        빌드할 때 정해져 파일에 박힌다
                        환경을 바꾸려면 다시 빌드해야 한다
                        방문자가 전부 볼 수 있다

그래서 브라우저가 알아도 되는 것만 두 번째에 두는데, 지도 서비스의 공개 키나 화면에 표시할 버전 번호 같은 것들이 그렇습니다.

우리 앱에 그런 값이 하나도 없는 건 우연이 아닙니다. D-3에서 서버와 클라이언트의 경계를 그은 뒤로, 바깥과 이야기하는 일을 전부 서버 쪽에 뒀거든요. 브라우저가 직접 백엔드를 부르지 않으니 브라우저가 알아야 할 비밀도 없습니다.

💡 한 줄 정리

비밀은 코드 밖에 두고 실행할 때 읽고, 이름 앞에 붙는 글자 하나가 그 값이 브라우저로 나가는지를 정합니다.

마무리

오늘 배운 핵심 세 가지

💡 하나. 막는 것과 지우는 것은 다릅니다. 지난 시간에 세운 규칙은 위험한 태그를 없애지 않았어요. 문서 안에 그대로 두고 실행만 막았고, 그래서 걸러내기와 함께 두 겹으로 세워야 합니다. 한 겹만 있으면 다른 한 겹이 하던 일이 통째로 비어요.

💡 둘. 우리 페이지에 건 규칙은 우리 페이지 밖에서 오는 요청을 못 봅니다. 남의 사이트가 자기 쪽에서 우리 앱으로 요청을 보내면 그 규칙은 손댈 데가 없습니다. 그건 다른 방법으로 막아야 하고, 서버 액션에 대해서는 프레임워크가 이미 막고 있었어요.

💡 셋. 문지기가 무엇을 확인할지는 그 문을 누가 두드리는지가 정합니다. 사람이 두드리는 문은 세션 쿠키를 보고, 서버가 두드리는 문은 약속한 비밀을 봅니다. 브라우저가 없는 쪽에 쿠키를 요구하면 공격자가 아니라 정상적인 상대를 막게 됩니다.

다음 시간 예고

이걸로 보안 세 시간이 끝났습니다. 우리 화면에서 남의 코드가 도는 문제, 브라우저에게 미리 알려두는 방법, 그리고 오늘 바깥과의 경계까지요.

돌아보면 오늘 우리가 한 일은 대부분 재보는 것이었어요. 두드려보고, 응답을 읽고, 열려 있는지 닫혀 있는지 확인했습니다. 코드는 Step 4에서 몇 줄 고친 게 전부였죠.

그런데 오늘 우리가 재본 건 전부 우리 노트북에서였습니다. 진짜 사용자가 쓰는 앱에서는 우리가 옆에서 지켜볼 수가 없어요. 누군가의 화면에서 무언가 터졌을 때, 우리는 그걸 어떻게 알게 될까요.

다음 시간부터는 그 이야기입니다. 배포한 다음에 벌어지는 일을 우리가 어떻게 알아채고, 사용자가 실제로 느끼는 속도를 어떻게 재는지요.

과제

[구현] 문지기를 "고쳐" 보세요

Step 4에서 우리가 쓴 검사에는 이런 줄이 있었습니다.

const expected = process.env.REVALIDATE_SECRET;

if (expected === undefined || request.headers.get('x-revalidate-secret') !== expected) {

expected === undefined 부분이 군더더기처럼 보일 수 있어요. 값이 없으면 어차피 헤더와 안 맞을 테니까요.

먼저 확인해보세요. 그 조건을 지우고, REVALIDATE_SECRET도 안 정해둔 채로 두드려보세요. 통과하나요?

그다음이 진짜 과제입니다. 값이 없을 때를 대비해서 이렇게 "고쳐" 봅시다. 더 안전해 보이는 코드예요.

const expected = process.env.REVALIDATE_SECRET ?? '';

이 상태에서 REVALIDATE_SECRET을 안 정해두고, 이번엔 빈 값 헤더 하나를 보내보세요.

curl -X POST -H 'x-revalidate-secret;' \
  'http://localhost:3000/api/profiles/revalidate?username=jaehoon'

무슨 일이 일어나는지 확인하고 왜 그렇게 되는지 설명한 다음, 빌드도 되고 타입 검사도 통과하는 이 수정을 코드 리뷰에서 어떻게 발견할 수 있을지도 답해보세요.

확인이 끝나면 원래대로 되돌리세요.

[구현] 이름 하나를 바꿔보세요 — 예상과 다를 겁니다

Step 5에서 이름 앞에 붙는 글자가 값의 운명을 가른다고 했죠. 직접 확인하는 과제입니다.

REVALIDATE_SECRET을 NEXT_PUBLIC_REVALIDATE_SECRET으로 바꾸세요. .env.local과 문지기 코드 양쪽 다요. 다 바꿨으면 프로덕션으로 빌드하세요.

이제 빌드 결과물에서 그 값을 찾아보세요. 브라우저가 받아가는 파일들이 어디에 모이는지는 D-10에서 확인했습니다.

아마 못 찾으실 겁니다. 왜 그런지 설명해보세요. 이름은 분명히 바꿨는데요.

힌트는 D-3에 있습니다. 그때 우리는 'use client'가 긋는 선이 어디를 따라 내려가는지 봤어요. 지금 그 값을 읽는 파일은 그 선의 어느 쪽에 있나요?

그다음, 값이 실제로 새어 나가게 만들어보세요. 클라이언트 컴포넌트를 아주 작게 하나 만들어서 그 값을 읽게 하고, 화면 어딘가에 붙인 다음 다시 빌드해서 같은 방법으로 찾아보세요.

두 상태의 결과를 표로 정리하고, 마지막으로 답해보세요. 값이 새어 나가려면 무엇과 무엇이 동시에 있어야 하나요?

⚠️ 값을 찾을 때 대상 폴더를 정확히 고르세요. 서버만 쓰는 파일에서 나온 것과 브라우저가 받아가는 파일에서 나온 것은 뜻이 완전히 다릅니다.

확인이 끝나면 반드시 전부 되돌리세요.

[탐구] 서버 액션도 두드려보세요

Step 2에서는 제가 결과를 보여드렸는데, 이번엔 직접 재보는 과제입니다.

팔로우 폼을 밖에서 제출해보세요. Origin을 세 가지로 바꿔가면서요. 우리 주소, 남의 주소, 그리고 헤더를 아예 빼고요.

⚠️ 두 가지를 조심하세요. 첫째, 폼이 선언한 형식과 같은 방식으로 보내야 합니다. 화면 소스에서 폼 태그를 열어 어떤 형식인지 먼저 확인하세요. 둘째, 좋아요 버튼은 이 방법으로 못 누릅니다. 왜 그런지도 함께 확인해보세요. D-8에서 그 버튼에 무엇을 얹었는지 떠올려보면 답이 보입니다.

판정은 응답 코드만 보지 말고 연습용 서버 로그로 하세요. 요청이 실제로 거기까지 갔는지가 진짜 답입니다.

그리고 마지막으로 답해보세요. 세 경우 중 통과한 것이 있다면, 그게 실제 공격에서도 통하는 경로일까요?

[탐구] 두 문을 나란히 놓아보세요

오늘 우리는 같은 앱 안에서 서로 다르게 지켜지는 두 개의 문을 봤습니다. 팔로우로 가는 길과 우리가 만든 주소요.

표를 하나 만들어서 채워보세요.

그리고 답해보세요. 우리가 앞으로 새 주소를 하나 더 만든다면, 이 표의 어느 칸을 먼저 정해야 할까요?

생각해볼 주제

1. 프레임워크가 대신 막아주는 것을 우리는 어떻게 알 수 있을까요

오늘 Step 2에서 우리는 아무 코드도 안 썼는데 공격이 막히는 걸 봤습니다. 알고 막은 게 아니라 재보다가 알게 됐어요.

이런 게 얼마나 더 있을지, 우리가 모르는 채로 지켜지고 있는 것들이 무엇일지, 그리고 그걸 모르는 상태가 왜 위험한지도 함께 생각해보세요. 지켜주는 줄 모르고 직접 또 막는 것과, 안 지켜주는데 지켜준다고 믿는 것 중에 어느 쪽이 더 위험할까요.

2. 비밀을 나눠 가진 두 쪽 중 한쪽이 바뀌면

Step 4에서 우리 서버와 백엔드가 같은 값을 나눠 가졌고, 잘 동작하죠.

그 값을 바꿔야 할 때가 오면 문제가 생깁니다. 누가 실수로 유출했거나, 정기적으로 바꾸기로 했거나요. 두 쪽이 동시에 바뀌지 않으면 그사이에 요청이 전부 거절됩니다.

이걸 어떻게 다뤄야 할지, 그리고 이 문제가 오늘 우리가 고른 방법에만 있는 것인지 아니면 나눠 가진 비밀을 쓰는 모든 방법에 있는 것인지도 함께 생각해보세요.

3. 두 겹 중 하나만 할 수 있다면 어디에 두시겠어요

지난 시간에 이미 비슷한 질문을 드렸는데, 오늘 본 것을 얹어서 다시 생각해보세요.

오늘 Step 1에서 우리는 실행만 막는 것과 아예 지우는 것이 다르다는 걸 봤습니다. 실행만 막으면 위험한 값이 데이터베이스에 계속 쌓여요.

이 관점에서 두 겹의 순서를 다시 보면 어떨지, 그리고 이미 쌓여버린 값들은 어떻게 해야 할지도 함께 생각해보세요. 나중에 걸러내기를 강화하면 그것들도 안전해지나요?