보안 취약점 데모 사이트 만들기 — 안전 분류기와 file:// 를 넘어서

About this offer

결론부터 말하면 이렇다. 보안 취약점 시연 사이트를 만들 때 진짜 어려운 건 XSS나 SQL Injection 코드를 짜는 게 아니었다. 진짜 벽은 두 개였다. "해킹"이라는 표현을 AI 안전 분류기가 어떻게 받아들이는지, 그리고 더블클릭으로 여는 정적 파일이 브라우저 안에서 얼마나 할 수 있는 게 없는지. 상황 사내 바이브코딩 강의에서 실습으로 보여줄 사이트를 만들어야 했다. AI로 코드를 짤 때 흔히 딸려오는 취약점 4종 — XSS, SQL Injection, 파일 업로드, Rate limit(DDoS) — 을 눈으로 보여주는 사이트다. 구성은 단순했다. 한쪽엔 "사용자가 쓰는 화면", 다른 쪽엔 "그로 인해 뭐가 새는지 보는 화면". 왼쪽에서 공격하면 오른쪽에 결과가 뜨는 연출이 핵심이었다. 첫 번째 벽 — 말 한마디에 응답이 끊긴다 안전 분류기 : AI 응답이 위험한 요청인지 판단해서 생성 자체를 막는 필터링 단계. 초기 요청에 "해킹", "SQL Injection", "악성 스크립트 업로드" 같은 말을 그대로 섞어 썼더니 두 번 연속 응답이 끊겼다. 문제는 단어가 아니라 프레이밍이었다. "공격 도구를 만들어달라"로 읽히면 막히고, "취약한 코드 때문에 뭐가 새는지 보여주는 관찰 대시보드를 만들어달라"로 읽히면 통과됐다. 목적은 똑같은데 표현만 바꿨을 뿐이다. 이후로는 이 프레임을 설계 전체에 그대로 유지했다 — 공격 재현이 아니라 관찰. 두 번째 벽 — 화면을 나누면 왜 서로 못 알아볼까 프레이밍 문제를 풀고 나니 구조 문제가 남았다. 처음엔 "사용자 화면"과 "해커 화면"을 각각 별도 HTML 파일로 만들려 했다. 그런데 배포 형태가 서버 없이 더블클릭으로 여는 file:// 방식이라는 걸 다시 확인하고 나서 멈췄다. file:// 로 열린 두 개의 HTML 파일은 브라우저 보안 정책상 서로 다른 출처(origin)로 취급된다. localStorage도 BroadcastChannel도 탭 사이에서 공유되지 않거나 불안정하게 동작한다. "왼쪽에서 입력하면 오른쪽에 바로 뜬다"는 연출 자체가 깨질 수 있는 구조였다. 해결 — 파일을 하나로 합치니 문제 자체가 사라졌다 프레임워크 없이 단일 HTML 파일 안에 좌우 분할 레이아웃을 두는 쪽으로 바꿨다. 파일을 하나로 합치면 두 화면이 같은 문서, 같은 메모리 안의 상태를 공유하니 탭 간 통신 문제 자체가 사라진다. 별도 동기화 로직을 설계할 필요가 없어졌다. 랩은 4개 — XSS, SQL Injection, 파일 업로드, Rate limit — 각각에 취약 모드/안전 모드 토글을 붙였다. 업로드 랩에는 사진처럼 보이지만 열면 스크립트가 실행되는 예시 파일을 직접 만들어서, 취약 모드에서 실제로 실행되는 걸 눈으로 보여줬다. Rate limit(DDoS)은 원래 이런 점검 항목에서 곧잘 빠지는 축에 든다. 그래도 "커맨드 한 줄로 보안 점검을 돌리면 안 보고 지나가는 자리"라는 이유로 넣기로 했다. 눈에 보이지 않는 것도 눈으로 보여줘야 실습이 된다는 판단이었다. 트레이드오프 취약/안전 토글은 코드와 연출 분량이 두 배가 된다. 그래도 "지적은 AI가 하고, 고칠지는 사람이 정한다"는 메시지의 핵심이라 그대로 뒀다. 처음엔 코드부터 보여주는 구성이었는데, 비개발자 피드백을 받고 나서 뒤집었다. "이렇게 뚫렸어요 / 이렇게 막아요" 카드를 앞에 두고, 코드는 접어서 옵션으로만 남겼다. 애니메이션(유출 빔, 공격 성공 배너, 단계별 따라하기)은 스크린샷 정적 캡처로는 타이밍 확인이 안 됐다. 화면을 눈으로 보는 대신 상태값을 프로그램적으로 확인하는 방식으로 검증 방법 자체를 바꿨다. file:// 환경에서는 브라우저 확장 권한도 막히기 때문에, 검증은 로컬 서버를 별도로 띄워서 했다. 배포는 file:// , 검증은 서버 — 이 둘을 분리해야 했다. 교훈 보안·해킹을 다루는 교육 콘텐츠는 "방법"이 아니라 "결과를 관찰하는 대시보드"로 프레이밍해야 안전 분류기도, 청중의 이해도 통과한다. 그리고 file:// 로 배포해야 하는 정적 페이지는 탭 간 상태 공유가 막힌다는 전제를 깔고, 별도 파일보다 단일 파일 내 분할 UI를 먼저 고려하는 게 맞다. 코드 문제가 아니라 구조 문제였다. 그리고 그 구조 문제는 배포 방식 하나를 먼저 확인했으면 처음부터 안 생겼을 문제였다.

Offer details

Provider

velog

Source

velog-rss

Score

54.4

Confidence

49%