1. AI가 짜준 코드, 그대로 배포해도 될까

결론부터 말하자면, 안 됩니다. AI는 "동작하는 코드"는 잘 짭니다. 그런데 "공격이 들어와도 동작하는 코드"는 따로 시켜야 짜줍니다.

AI에게 시켜서 만든 코드를 배포했고, 서비스가 해킹당했다면 책임은 누구에게 있을까요? 여러분에게 있습니다. AI가 짜줬다고 해서 "내가 짠 게 아니니까"라고 빠져나갈 수 없습니다. 서비스가 인터넷에 올라가는 순간부터, 그 코드에 대한 책임은 내게 있습니다.

여기서부터는 AI가 짜준 코드에서 가장 자주 발견되는 취약점 네 가지를 짚어드립니다. 이름과 한 줄 설명만 알아도 충분합니다. 이 책의 목표는 여러분이 이 기술을 쓰거나 암기하게 하는 것이 아니라, AI에게 "내 코드의 취약점을 점검해줘"라고 시킬 수 있게 만드는 것입니다. 마지막 절에 그 점검 프롬프트를 한 덩어리로 정리해 두었습니다. 그대로 복사해서 쓰세요.

2. SQL 인젝션

한 줄 설명: 입력 칸 하나로 회원 DB를 통째로 가져가는 공격.

회원 조회 페이지에서 사번 1을 입력하면 보통 그 사람 한 명만 나오죠. 그런데 사이트가 입력을 잘못 다루면, 사번 자리에 1' OR '1'='1 같은 짧은 문장을 넣었을 때 전체 회원이 다 표시됩니다. 같은 입력 칸으로 회원 테이블 전체 다운로드, 더 심하면 테이블 자체 삭제까지 갑니다.

왜 일어나는가: AI에게 처음 짜라고 시킨 DB 코드는 종종 사용자가 친 글자를 명령문에 그대로 끼워 붙입니다. DB는 입력에 따옴표가 섞여 있어도 데이터인지 명령인지 구별을 못 합니다.

법적 위험 한 줄: 회원 DB가 유출되면 개인정보보호법상 72시간 내 통지·신고 의무가 발생하고, "안전성 확보조치 의무 위반"으로 과징금 대상이 됩니다.

3. XSS

한 줄 설명: 댓글 한 줄로 모든 방문자의 쿠키를 가져가는 공격.

게시판이나 검색창에 평범한 글자 대신 <script>...</script> 같은 코드 조각을 적었을 때, 사이트가 그걸 글자로 보지 않고 진짜 코드로 실행해버리는 게 문제입니다. 한 번 실행되면 그 페이지를 보는 사람의 로그인 쿠키가 공격자 서버로 흘러갑니다. 쿠키를 가져간 공격자는 자기 브라우저에 그 쿠키를 심어 그 사람 계정으로 그대로 로그인합니다.

검색창은 한 명이 한 번 클릭해야 터집니다. 방명록·댓글창처럼 글이 저장되는 자리는 다릅니다. 한 번 적어두면 그 페이지를 보러 오는 모든 사람의 브라우저에서, 영원히, 같은 코드가 실행됩니다.

법적 위험 한 줄: 세션 쿠키 탈취로 회원이 사칭당하면 개인정보보호법상 안전성 확보조치 의무 위반과 통지 의무로 이어집니다.

4. CSRF

한 줄 설명: 다른 사이트가 우리 사이트로 요청을 대신 보내게 만드는 공격.

흐름이 좀 낯섭니다. 사용자가 쇼핑몰에 로그인한 상태로 다른 사이트(공격자가 만든 평범해 보이는 페이지)를 방문합니다. 그 페이지엔 보이지 않는 코드 한 줄이 입력되어 있고, 그 한 줄이 쇼핑몰로 비밀번호 변경 요청을 대신 보냅니다. 사용자의 브라우저는 그 요청을 보내면서 쇼핑몰의 로그인 쿠키를 자동으로 같이 실어 줍니다. 쇼핑몰 입장에선 정상 사용자가 요청한 것으로 보입니다.

사용자는 폼을 채우지도, 버튼을 누르지도 않았습니다. 페이지를 한 번 본 것뿐인데 비밀번호가 바뀌어 있습니다.

법적 위험 한 줄: 회원 계정이 임의 조작되어 손해가 발생하면 안전성 확보조치 의무 위반과 함께 사용자 손해배상 책임으로 이어질 수 있습니다.

5. 남의 데이터를 자기 것처럼 조작

한 줄 설명: 로그인만 확인하고 "본인 것"인지는 확인 안 하는 흔한 실수. 보안 용어로는 IDOR라고 부릅니다.

사고 빈도로는 위 셋(SQL·XSS·CSRF)보다도 자주 봅니다. AI가 짜준 코드는 보통 "로그인했는지"만 확인하고, "이 사람이 정말 이 데이터의 주인인지"는 확인하지 않습니다. 결과적으로 로그인된 누구라도 주소창의 숫자만 바꿔서 남의 글을 자기 글처럼 수정할 수 있게 됩니다.

내 글 수정 페이지 주소가 /posts/3/edit 이라고 칩시다. 숫자 3을 2로 바꿔 들어가면 사장님이 쓴 글의 수정 페이지가 그대로 열립니다. 사이트가 막지 못합니다. 이 패턴은 글뿐 아니라 주문 상세, 결제 내역, 개인 메시지, 프로필 편집에서도 똑같이 나타납니다.

법적 위험 한 줄: 남의 결제 내역이나 개인 메시지를 무단 열람·수정할 수 있는 상태는 개인정보보호법 제29조 위반으로, 노출된 회원 1명당 손해배상 책임으로 이어집니다.

6. 의존성

AI에게 "할 일 관리 앱 만들어줘"라고 시키면, AI는 보통 수십 개를 설치하는 코드를 같이 줍니다. 문제는 그 수십 개 안에서 한 개라도 보안 구멍이 발견되면 우리 서비스도 같이 뚫린다는 점입니다. 이걸 공급망 공격이라고 부릅니다.

7. AI에게 시킬 종합 점검 프롬프트

여기까지 읽으셨다면, 이제 SQL이나 자바스크립트를 한 줄도 직접 쓸 필요가 없습니다. 아래 한 덩어리를 Cursor, Claude Code, Copilot 같은 도구에 프로젝트를 열어둔 채로 그대로 붙여넣으면, AI가 다섯 항목을 차례로 훑고 발견된 자리마다 (1) 파일·줄 번호 (2) 왜 위험한지 한 줄 (3) 수정 코드 제안을 묶어 보고해줍니다.

아래 5가지 항목으로 이 프로젝트의 웹 보안 취약점을 점검해줘.
각 항목마다 (1) 발견된 위치(파일·줄 번호) (2) 왜 위험한지 한 줄 (3) 수정 코드 제안 을 묶어서 보고해줘.
하나도 발견되지 않으면 "해당 없음" 으로 명확히 표시해줘.

1) SQL 인젝션
   - DB 를 다루는 모든 자리(쿼리 실행, ORM 의 raw 쿼리 포함)에서 사용자 입력이
     문자열 결합/템플릿 리터럴로 SQL 안에 글자로 끼어들어가는 자리를 찾아줘.
   - 발견 시 파라미터 바인딩(?, :name, Prepared Statement)으로 바꾸는 코드를 제안.

2) XSS (저장형/반사형 모두)
   - 사용자 입력 또는 외부 API 응답을 HTML 로 넣는 자리:
     React 의 dangerouslySetInnerHTML, Vue 의 v-html, Svelte 의 {@html},
     바닐라 JS 의 .innerHTML / document.write 모두 포함.
   - 각 자리마다 데이터 출처(상수 / DB / 사용자 입력 / 외부 응답)를 같이 보고.
   - 사용자 입력이 들어가는 자리는 DOMPurify 또는 textContent 사용으로 바꾸는 제안.

3) CSRF
   - 상태를 변경하는 모든 엔드포인트(POST / PUT / PATCH / DELETE,
     그리고 데이터를 바꾸는 GET 요청)에 대해 다음을 점검:
     · HTTP 메서드 (GET 으로 상태 변경하면 위험)
     · 쿠키의 SameSite 속성
     · CSRF 토큰 검증 여부
     · Origin / Referer 헤더 검사 여부
   - 비밀번호 변경, 결제, 주소 변경 같은 영향이 큰 엔드포인트는 우선순위 ↑.

4) IDOR (남의 데이터를 자기 것처럼 조작)
   - 사용자별로 다른 데이터를 다루는 API 를 모두 찾아줘.
     예: 글 수정/삭제, 주문 조회, 결제 내역, 개인 메시지, 프로필 편집.
   - 각 API 에서 "로그인 검사" 만 하고 끝나는지,
     "이 사용자가 이 데이터의 주인인지" 까지 검사하는지 확인.
   - 빠진 곳은 ownerId 비교 + 403 반환 코드 제안.

5) 의존성
   - package.json / requirements.txt / pyproject.toml 등에 등록된 패키지 중
     알려진 취약점이 있는 옛 버전이 있는지 점검.

마지막에 우선순위 표 한 줄로 정리: [Critical / High / Medium / Low] 별로 몇 개씩 나왔는지.

같은 프롬프트는 just.weniv.co.kr/vuln 의 마지막 카드에서 "프롬프트 복사" 버튼 한 번으로 가져갈 수 있습니다. 새 프로젝트를 띄울 때마다, 또는 배포 직전마다 한 번씩 돌려보세요.

다음 장은 코드 바깥의 이야기입니다. 법, 라이선스, 개인정보. 코드는 다 잘 짰는데 사업이 멈춰버리는 가장 흔한 이유들입니다.