말로 만든 내 사이트, 새는 곳 없나 점검하기 — 관리자 말고 일반 사용자 눈으로

말로 만든 사이트는 겉으로는 잘 돌아갑니다. 로그인도 되고 화면도 멀쩡합니다. 그런데 관리자 계정으로만 눌러 보면 새는 곳이 보이지 않습니다. 관리자는 원래 다 볼 수 있으니까요. 그래서 이 편은 순서를 바꿉니다. 먼저 「누가 무엇을 볼 수 있어야 하는지」를 표로 적고, 다섯 가지를 한 가지씩 점검하고 고친 다음, 일반 직원 입장으로 같은 점검을 처음부터 다시 합니다. 아래 말을 순서대로 한 줄씩 치면 됩니다. 🤖 답은 제가 클로드로 실제로 돌려 받은 것이고, 대상은 제가 일부러 허술하게 만든 연습용 가나다전자 공지·건의 게시판입니다. 예시 이름은 전부 가짜입니다.

시작 전에

• 점검할 내 사이트 폴더(폴더 이름은 영문)를 준비하고 그 폴더에서 클로드(Claude Code)를 엽니다. 여는 방법은 15편 「시작 전에」와 같습니다. 아직 만든 사이트가 없으면 이 편은 읽어만 두고, 사이트를 만든 뒤에 하세요.
• 고치기 전에 저장해 두세요. 이 편에서는 클로드가 파일을 여러 곳 고칩니다. 마음에 안 들면 되돌릴 수 있게 17편처럼 먼저 저장 지점을 만들어 두세요.
• 승인 방식은 Manual 로 두세요(15편). 허락 창이 뜨면 명령을 읽고, 인터넷에 요청을 보내거나, 무언가를 설치하거나, 지우는 명령은 거절하세요. 제 시험에서는 클로드에게 파일 읽기·찾기·고치기만 허용했습니다. 그래서 클로드는 사이트를 띄워 보지 않고 코드를 읽고 따라가 보는 것으로 점검했고, 점검 답에는 「띄워 시험하지는 않았다」는 말이 자주 붙습니다.
• 점검 범위는 브라우저로 내려가는 파일(화면 파일)과 서버 코드입니다. 서버에만 두는 비밀 파일(키를 적어 둔 설정 파일 같은 것)을 클로드에게 열어 보여 줄 필요는 없습니다.
• 제 화면과 클로드의 답이 글자 하나까지 같지는 않을 것입니다. 「이렇게 나오면 성공」 표시만 맞으면 다음으로 가세요.

1단계 · 누가 무엇을 볼 수 있어야 하는지 표부터

점검에는 기준이 있어야 합니다. 기준 없이 「이상한 데 없어?」라고 물으면 클로드도 무엇이 이상한지 모릅니다. 먼저 등급(직원 · 부서장 · 관리자)과 자료(공지 · 건의)별로 「누가 볼 수 있는지」를 표로 적게 합니다. 파일(rules.md)로 적어 두면 새 대화에서도 쓸 수 있습니다. 내 사이트의 등급과 자료 이름으로 바꿔 치세요.

✅ 이렇게 나오면 성공 — rules.md 가 생기고, 표의 O·X 가 내 생각과 같으면 됩니다. (위 답의 표는 줄였습니다. 실제 표는 공지 줄이 모두 O, 건의 줄은 「그 외 직원」 칸만 X 로 나왔습니다.) 내가 짧게 쓴 말(「부서장」)을 클로드가 자기 식으로 풀어 적었으니 내 뜻과 맞는지 확인하세요. 다르면 이렇게 말하세요: "부서장은 모든 부서 건의를 볼 수 있게 표를 고쳐 줘."

2단계 · 입력한 글이 화면에 들어가는 곳

첫 점검입니다. 사람이 입력한 글(공지 제목, 건의 내용, 이름)이 화면에 그대로 들어가면, 글 대신 화면을 바꾸는 글자를 넣어 둔 사람이 남의 화면에서 그것을 실행시킬 수 있습니다(저장형 XSS). 말에 「~만」과 「다른 문제는 고치지 말고 알려만 줘」를 붙이는 것이 요령입니다. 한 번에 한 가지씩만 고치게 하면 무엇이 바뀌었는지 눈으로 따라갈 수 있습니다(「막히면」 1번).

✅ 이렇게 나오면 성공 — 「innerHTML 을 textContent 로 바꿨다」는 말과 고친 파일 이름, 그리고 맨 끝에 「고치지 않고 알려만 드리는 문제」 목록이 보이면 됩니다. 제 답은 그 목록에 여덟 가지를 적었습니다. 클로드는 점검하다 다른 문제도 다 봅니다. 그것들은 아래 단계에서 고칩니다. 다만 textContent 로 바꾼다고 다 막히지는 않습니다. 링크 주소나 눌렀을 때 실행되는 글처럼 다른 길로 들어가는 자리도 있습니다(OWASP 도 한 가지 방법으로는 XSS 를 다 막지 못한다고 합니다). 그래서 「고치지 않은 곳이 남아 있지 않은지 다시 찾아서 알려 줘」를 한 번 더 말하세요(제 시험에는 넣지 않았습니다).

3단계 · 주소 번호만 바꾸면 남의 자료가 보이나

로그인한 직원이 주소 끝 번호를 다른 번호로 바꿨을 때 남의 건의가 열리면 안 됩니다. 화면이 내 것만 골라 보여 주는 것은 막는 것이 아닙니다. 막는 것은 서버가 자료마다 「이 사람이 볼 수 있나」를 확인하는 일입니다. 1단계의 표가 이때 기준이 됩니다.

✅ 이렇게 나오면 성공 — 「서버가 확인한다」는 말과 「없는 번호와 볼 수 없는 번호에 같은 답」이 보이면 됩니다. 그리고 클로드가 「목록으로는 여전히 다 보입니다」 라고 남은 구멍을 알려 준 것도 성공입니다. 이 구멍은 7단계에서 다시 나옵니다.

4단계 · 일반 사용자가 자기 등급·부서를 스스로 바꿀 수 있나

「내 정보」 화면에서 이름, 부서, 등급을 고쳐 저장하게 만든 사이트가 많습니다. 서버가 보낸 칸을 그대로 저장하면 직원이 등급 칸을 「관리자」로 바꿔 저장하는 것만으로 관리자가 됩니다. OWASP 는 사용자가 바꿔도 되는 칸을 목록으로 정해 두고 그 칸만 받으라고 합니다.

✅ 이렇게 나오면 성공 — 「서버가 이름만 받는다」와 「화면 칸도 고칠 수 없게 바꿨다」가 둘 다 보이면 됩니다. 답이 스스로 「이게 실제로 막는 부분입니다」라고 구분했습니다. 화면 칸을 잠그는 것은 안내이고 문은 서버입니다. 이제 부서와 등급은 관리자용 화면이 있어야 바꿀 수 있습니다. 필요하면 새로 부탁하세요.

5단계 · 브라우저로 내려가는 파일 안의 키·비밀번호

화면 파일은 누구나 내려받습니다. 개발자 도구만 열면 다 보입니다. 그 안에 키나 비밀번호가 있으면 이미 공개된 것입니다(OWASP 의 웹 보안 시험 안내서도 화면 쪽 코드에 적은 비밀 키·비밀번호는 샐 수 있다고 적고 있습니다). 연습 게시판에는 알림용 키라고 적힌 가짜 값 하나를 넣어 두었습니다. 값은 답에 그대로 찍히므로, 아래 인용에서는 「…」로 가렸습니다.

✅ 이렇게 나오면 성공 — 키가 든 파일 이름과 「브라우저 쪽에서 뺐다」는 말이 보이면 됩니다. 이 단계에서 가장 중요한 것은 마지막 문단입니다. 진짜 키였다면 코드에서 지우는 것으로는 끝나지 않습니다. 이미 내려간 키는 발급처(그 키를 준 서비스)에서 폐기하고 새로 받는 일이 남고, 그것은 사람의 몫입니다(OWASP 도 노출된 키는 즉시 폐기하라고 합니다). 다만 모든 키가 비밀은 아닙니다. 밖에 보여도 되는 공개용 키도 있으니, 헷갈리면 이렇게 물어보세요: "이 키는 브라우저에 있어도 되는 종류야?" 진짜 키가 든 사이트라면 위 말 끝에 「값은 답에 쓰지 말고 파일 이름과 줄만 알려 줘」를 덧붙이세요(제 시험에는 넣지 않았습니다).

6단계 · 로그인 없이 열리는 주소

화면에서 로그인을 요구해도, 서버가 주소를 직접 부르는 요청에 로그인 확인을 하지 않으면 그냥 열립니다. 「점검용」「나중에 지울 것」이라는 설명이 붙은 주소가 특히 위험합니다. 급할 때 만들고 잊기 때문입니다. 연습 게시판에도 그런 주소(내보내기)를 하나 넣어 두었습니다.

✅ 이렇게 나오면 성공 — 「로그인이 없으면 거절(401)」과 「화면 파일은 일부러 열어 뒀다」가 보이면 됩니다. 클로드가 바뀐 동작(공지도 이제 로그인해야 보인다)을 알려 주었으니 내 뜻과 맞는지 확인하세요(「막히면」 4번). 그리고 마지막 문단을 눈여겨보세요. 로그인만 하면 누구나 남의 목록과 내보내기를 볼 수 있다고 합니다. 관리자 눈으로는 이것이 문제로 보이지 않습니다. 다음 단계가 그 이야기입니다.

7단계 · 관리자 말고 일반 직원 입장에서 처음부터 다시

가장 중요한 단계입니다. 앞에서 고친 것을 일반 직원 한 사람의 입장에서 처음부터 다시 따라가게 합니다. 사람 이름을 넣어 말하면 클로드가 그 사람으로 코드를 따라갑니다. 내 사이트의 일반 직원 이름으로 바꿔 치세요.

✅ 이렇게 나오면 성공 — 앞 단계에서 「알려만 줬던」 목록과 내보내기가 이번에 고쳐지고, 클로드가 못 고친 것을 따로 적으면 됩니다. 클로드는 사람이 정할 일(로그인을 어떤 방식으로 할지)을 멋대로 정하지 않고 물어봤습니다. 이것도 성공입니다. 이 연습 게시판의 「로그인」은 주소에 사용자 번호를 적는 가짜라서 이 구멍이 남았습니다. 로그인을 붙이는 방법은 10편에 있습니다. 진짜 로그인이 있어도 서버가 「누구인지」를 로그인 정보가 아니라 화면이 보낸 값(주소·입력칸)으로 정하면 같은 구멍이니, 이 점검은 그대로 하세요.

8단계 · 새 기능을 만들 때도 같은 기준으로 — 규칙 파일에 적기

이번에 찾은 기준을 내일 만들 화면에도 쓰도록 규칙 파일에 적습니다. 규칙 파일은 15편과 같은 CLAUDE.md 입니다. 새 화면이나 새 주소를 만들 때마다 같은 다섯 가지 구멍이 새로 생길 수 있기 때문입니다.

✅ 이렇게 나오면 성공 — 폴더에 CLAUDE.md 가 생기고, 다섯 가지 기준과 「관리자 입장만 보지 말 것」이 들어 있으면 됩니다. 파일을 열어 읽어 보세요.

9단계 · 새 대화에서 규칙대로 하는지 확인

지금 대화를 닫고 같은 폴더에서 새 대화를 엽니다. 새 대화는 앞 이야기를 모르니 규칙은 파일에서 읽어 와야 합니다. 규칙은 말하지 않고 작은 기능만 부탁합니다. (내 사이트에 맞는 작은 기능으로 바꾸세요.)

✅ 이렇게 나오면 성공 — 점검을 말하지 않았는데도 「서버가 확인」「받는 칸은 하나」「글자로만 화면에 넣기」가 보이면 됩니다. 다만 앞에서 고쳐 둔 코드를 보고 따라 했을 수도 있습니다. 규칙 파일을 읽었는지 확실히 보려면 「막히면」 7번의 말을 쓰세요. 클로드가 정하지 않은 것(누가 바꿀 수 있나)을 자기가 정했다고 밝히고 확인을 청한 점도 눈여겨보세요. 그 부분은 내 사이트의 규칙이니 내가 확인해야 합니다.

다 됐습니다 — 이제 이렇게 말하면 됩니다

항상 이 폴더에서 클로드를 열고 이야기합니다. 기준은 규칙 파일이 알고 있습니다.

• 「○○ 화면 하나 만들어 줘.」 (규칙 파일을 읽고 서버 확인·글자로 넣기를 지킵니다.)
• 「방금 만든 기능을 일반 직원 입장에서 다시 점검해 줘.」
• 「관리자 말고 로그인 안 한 사람 입장에서도 똑같이 점검해 줘.」

처음 점검은 직원들에게 열기 전에, 그 뒤로는 새 기능을 열기 전에 하세요. 이 다섯 가지는 흔한 구멍일 뿐 전부가 아닙니다. 다섯 가지가 모두 「막음」이어도 안전하다는 보증은 아니니, 돈이나 개인정보를 다루는 사이트라면 전문가 점검도 받으세요.

막히면

내 것만, 허락받은 것만 점검합니다. 아래 처방도 모두 내 사이트 폴더 안에서 파일을 읽고 고치는 말입니다.

1. 한 가지만 시켰는데 클로드가 여러 곳을 고쳤다 → 제 첫 시도에서 실제로 났습니다. 말에 「~만」과 「나머지는 알려만」을 붙이지 않았더니, 3단계에서 남의 건의 보기뿐 아니라 등급 바꾸기와 열린 내보내기 주소까지 한꺼번에 고쳤습니다. 무엇이 바뀌었는지 따라가기 어렵습니다. 이렇게 다시 말하세요: "이번엔 ○○만 고쳐 줘. 다른 문제는 고치지 말고 알려만 줘." 이미 많이 바뀌었다면 17편 방식으로 저장해 둔 것과 견주어 보세요.
2. 클로드가 「서버를 띄워 시험하지는 않았다」고 한다 → 정상입니다. 이 편은 코드를 읽고 따라가 보는 점검입니다. 진짜 화면에서의 확인은 내가 직접 일반 직원 계정으로 로그인해서 하세요(내 사이트에서만). 주소 끝 번호를 바꿔 보고, 목록·내보내기 같은 주소를 주소창에 직접 쳐 보세요. 단, 4단계처럼 화면에서 잠근 칸은 화면으로 시험이 안 됩니다. 잠긴 칸은 안내일 뿐이라 서버가 막는지는 따로 봐야 합니다. 이렇게 물어보세요: "등급 칸을 보내면 서버가 무시하는 줄이 어디인지 보여 줘."
3. 모든 점검이 「문제없음」으로 나왔다 → 클로드는 읽은 파일 안에서만 압니다. 자료를 지키는 규칙이 사이트 폴더 밖(서비스 콘솔 같은 곳)에 있으면 볼 수 없습니다. 이렇게 말해 보세요: "자료를 지키는 규칙이 이 폴더 안에 있는지, 밖에 있는지 알려 줘." 이 경우는 제 시험에서 겪지 못했습니다. 자세한 것은 10편에 있습니다.
4. 고쳤더니 정상 사용이 안 된다 → 6단계에서 실제로 났습니다. 로그인 없이 열리는 주소를 막았더니 공지도 로그인해야 보이게 바뀌었습니다. 내 뜻이 「직원 모두」면 그대로 두고, 「누구나」면 예외를 부탁하세요. 막는 데만 힘쓰면 써야 할 사람이 못 쓰게 됩니다. 7단계의 일반 직원 점검에서 해야 하는 일이 되는지도 함께 확인하세요.
5. 진짜 키가 나왔다 → 코드에서 지우는 것만으로 끝나지 않습니다. 키를 준 서비스에서 폐기하고 새로 받아 서버 쪽 설정에 넣으세요(사람의 몫). 클로드 답에 키 값이 찍혔다면 그 대화에도 남은 것입니다. 이렇게 말하세요: "키 값은 쓰지 말고 파일 이름과 줄만 알려 줘."
6. 「진짜 로그인이 없어서 못 막는다」고 한다 → 7단계에서 실제로 났습니다. 클로드가 못 고친다고 한 것은 정상입니다. 로그인 방식은 사람이 정해야 합니다. 이렇게 말하세요: "회사 구글 계정으로 로그인하게 하고 싶어. 먼저 정해야 할 것을 물어봐 줘." 순서는 10편을 보세요.
7. 새 대화인데 규칙대로 안 한다 → 클로드를 연 폴더가 CLAUDE.md 가 있는 폴더가 아닌 경우가 흔합니다. 이렇게 다시 말하세요: "지금 열린 폴더 경로를 말하고, 그 폴더의 CLAUDE.md 를 읽은 다음 점검 기준을 한 줄씩 요약해 줘." 자세한 점검은 15편의 「막히면」을 보세요.
8. 클로드가 점검을 망설이거나 멈춘다 → 제 시험에서는 한 번도 나지 않았습니다. 「내 사이트의 파일을 읽고 고치는 일」임을 분명히 하고 「점검해 줘」「확인해 줘」「고쳐 줘」로 말하세요. 남의 사이트가 대상이라면 멈추는 것이 맞습니다. 그런 곳에는 하지 마세요.

한 번에 맡기기 (익숙해진 다음에)

역할: 너는 내가 말로 만든 사이트를 「일반 사용자 눈으로」 점검하고 고쳐 주는 도우미다. 나는 코드를 모르는 초보자이니 어려운 말은 풀어서, 짧게 말해 줘.

맥락: 지금 열려 있는 이 폴더가 내가 만든 사이트다(내가 점검해도 되는 내 것). 사이트는 <사이트가 하는 일 한 줄>이다. 누가 무엇을 볼 수 있어야 하는지는 이렇다 — <예: 공지는 모두, 건의는 쓴 사람·쓴 사람과 같은 부서의 부서장·관리자만>. 사용자 등급은 <등급 이름들>이다.

입력: <운영체제>, <쓰는 클로드(Claude Code)>, 사이트가 하는 일은 <한 줄>.

작업:
① 이 폴더의 파일을 읽고 고치기만 한다. 사이트를 띄우거나, 인터넷에 요청을 보내거나, 무언가를 설치하지 않는다.
② 누가 무엇을 볼 수 있어야 하는지 표를 rules.md 에 적는다.
③ 다섯 가지를 하나씩 점검한다. (가) 입력한 글이 화면에 들어가는 곳 (나) 주소 끝 번호만 바꾸면 남의 건의가 보이는지 — 목록 주소도 (다) 일반 사용자가 자기 등급·부서를 바꿀 수 있는지 (라) 브라우저로 내려가는 파일 안의 키·비밀번호 (마) 로그인 없이 열리는 주소
④ 점검한 항목은 그 자리에서 고친다. 고치다가 다른 항목의 문제가 보이면 그때는 고치지 말고 알려만 준다(그 항목 차례에 고친다).
⑤ 다 고친 뒤, 관리자 말고 일반 직원 입장에서 다섯 가지를 처음부터 다시 점검한다.
⑥ 앞으로 새 화면·새 주소를 만들 때도 지킬 기준을 CLAUDE.md 에 적는다.
⑦ 마지막에 초보자 눈높이로 무엇이 새고 있었고 무엇을 막았는지 설명한다.

제약: 키·비밀번호 값을 답이나 파일에 다시 쓰지 않는다(찾으면 파일 이름과 줄만 알린다). 진짜 키로 보이면 코드에서 지우는 것만으로는 부족하고 발급처에서 새로 받아야 한다고 알린다. 이 폴더 밖의 파일은 읽지도 쓰지도 않는다. 파일을 지우지 않는다. 내가 정할 일(로그인 방식 같은 것)은 멋대로 정하지 말고 물어볼 것을 적어 둔다.

출력: 항목별 점검 결과(문제 있음/없음), 고친 파일, 못 고친 것과 이유, 내가 정해야 할 것.

검증: 일반 직원 입장에서 다섯 가지를 다시 따라가 막혔는지 근거(파일과 줄)와 함께 말한다. 하나라도 못 막았으면 완료로 보고하지 말고 남은 문제에 적는다.

내가 만들 때는

9월 27일 오전, 직원 몇 명이 회사 플랫폼을 쓰기 시작하기 전날 이렇게 말했습니다. 「내일부터 출근하는데.. 몇명 직원들이 이거 사용함에서 문제 없이 되어야되.. 혹시나 모르니깐 다시 한번 테스트하고.. 점검해봐」 조금 뒤에는 이렇게도 물었습니다. 「너 지금 점검은 제 3자된 입장에서 하고 있어?? 그리고 내가 처음에 계획했던데로 되었는지.. 전부 확인해봐..」 이 편의 핵심이 둘째 말입니다. 만든 사람의 눈으로 점검하면 만든 사람이 아는 길로만 지나갑니다. 일반 직원은 모르는 길로도 갑니다.

그전에 이미 한 번 크게 당했습니다. 9월 26일 하루에만 「누구나 쓰는 값을 남이 믿는」 꼴의 구멍이 다섯 번 나왔고, 전부 최고 관리자 계정으로만 시험해서 안 보이던 것들이었습니다. 그래서 한 번에 훑었습니다. 일반 직원의 눈으로 네 갈래(자료 규칙 · 메신저 · 파일 저장소 · 인터넷에 열린 문)를 읽기만 하며 조사하고, 확인한 것을 고쳤습니다. 나온 것은 이 편의 다섯 가지와 겹치는 종류입니다. 직원이 쓴 글이 화면에 그대로 들어가던 자리(저장형 XSS), 남의 자료가 보이거나 덮어써지던 자리, 사용자가 자기 값을 직접 쓸 수 있던 자리, 인터넷에 열려 있던 문입니다. 이 편의 다섯 번째인 「브라우저로 내려가는 파일 속 키」는 그때 나온 것이 아니라 흔한 점검 항목이라 제가 더했습니다.

고친 뒤에는 두 가지를 했습니다. 하나는 고치는 방법을 한 가지로 정한 것입니다. 글을 넣는 자리마다 제각각 고치지 않고 정해 둔 도우미로만 넣게 했고, 그 도우미가 쓰이는 곳이 본체 화면에서 8곳에서 316곳으로 늘었습니다(함수 정의 줄까지 센 값). 시험 두 벌이 옛 모양이 다시 생기지 않게 지킵니다. 이 편의 8단계가 그 뜻입니다. 다른 하나는 시험입니다. 고친 구멍에는 시험을 붙였고, 새 규칙 시험은 고치기 전 상태로도 돌려서 실제로 실패하는지 확인했습니다. 통과만 보면 시험이 아무것도 안 보고 있을 수 있어서입니다. 규칙 시험은 9월 26일 저녁 97개에서 9월 27일 오전 172개가 됐습니다. 막고 나서 새로 생긴 일도 있었습니다. 규칙을 조이자 받는 사람이 비어 있는 메시지를 아무도 못 읽게 되어, 알림 넷이 조용히 멈춰 있었습니다. 이 편 「막히면」 4번(막았더니 정상 사용이 안 된다)이 그 이야기입니다.

한계도 있습니다. 이 편의 점검은 클로드가 코드를 읽고 하는 것이라 진짜 화면에서 눌러 보는 시험을 대신하지 못합니다(「막히면」 2번). → 뒷이야기 13단계에서 자세히 보세요. 로그인을 붙이는 방법은 따라 하기 10편, 고치기 전에 저장해 두는 방법은 따라 하기 17편에 있습니다.