빠른 웹앱 스팟체크를 위한 Claude Code 보안 체크리스트

가벼운 보안 스팟체크란\n\n가벼운 보안 스팟체크는 배포 전에 명백하고 영향이 큰 문제를 빠르게(보통 303개의 실제 사용자 여정을 선택하세요. 로그인, 비밀번호 재설정, 결제, 관리자 편집 화면이 좋은 후보입니다.\n\n다음으로 보호해야 할 자산을 구체적으로 적으세요: 사용자 계정, 결제 동작, 개인 데이터, 관리자 전용 작업 등.\n\n그런 다음 위협 가정을 평범한 말로 적으세요. 단순히 호기심 있는 사용자인가, 스크립트를 가진 외부 공격자인가, 일부 접근 권한을 가진 내부자인가? 답에 따라 "충분히 안전"의 기준이 달라집니다.\n\n마지막으로 통과와 실패 기준을 정의해 스팟체크가 감이 아닌 실제 발견으로 끝나게 하세요. 단순한 규칙이 잘 먹힙니다:\n\n- 통과: 모든 민감한 동작에 명시적 인증(authn)과 권한 검사(authz)가 있다.\n- 실패: 어떤 엔드포인트라도 클라이언트를 신뢰해 사용자 ID나 역할을 결정한다.\n- 통과: 입력은 UI가 아니라 서버 측에서 검증된다.\n- 실패: 시크릿이 로그, 설정, 클라이언트 코드에 나타난다.\n\n실패가 어떻게 보일지 설명할 수 없다면 범위가 아직 too fuzzy합니다.\n\n## Claude Code에 제공할 컨텍스트 준비\n\n스팟체크는 모델이 올바른 곳을 보고 있어야만 효과가 있습니다. 검토가 추측이 아닌 증거를 낼 수 있도록 소규모 코드 번들과 노트를 모으세요.\n\n보안에 중요한 경로를 공유하는 것부터 시작하세요: 요청 진입점과 누가 누구인지, 무엇을 할 수 있는지 결정하는 코드. 데이터 흐름을 보여주기에 충분한 주변 코드를 포함하세요.\n\n실용적인 번들은 보통 다음을 포함합니다:\n\n- 인증 진입부: 세션/JWT 파싱, 쿠키 설정, 로그인 콜백, 인증 미들웨어\n- 라우트 + 핸들러: 컨트롤러, RPC 메서드, GraphQL 리졸버, 백그라운드 잡 핸들러\n- 데이터 계층: ORM 쿼리, 원시 SQL 헬퍼, 쿼리 빌더, 민감 테이블 마이그레이션\n- 정책 검사: 역할 검사, 소유권 검사, 기능 플래그, 관리자 전용 엔드포인트\n- 검증: 요청 스키마 밸리데이터, 파일 업로드 핸들러, 역직렬화 코드\n\n세션 대 JWT, 토큰이 어디에 저장되는지(쿠키 또는 헤더), 리버스 프록시나 API 게이트웨이 동작, 큐/크론 워커, 그리고 어떤 "내부 전용" 엔드포인트가 있는지 같은 환경 노트를 몇 줄 추가해 가정을 명확히 하세요.\n\n버그를 쫓기 전에 진입점, 권한이 필요한 엔드포인트, 접근하는 데이터 저장소의 목록을 요청하세요. 이렇게 하면 놓치는 표면이 줄어듭니다.\n\n또한 구체적인 출력 형식에 합의하세요. 발견, 심각도, 영향을 받는 엔드포인트/파일, 증거(정확한 스니펫 또는 라인 범위), 익스플로잇 시나리오, 수정 제안을 포함한 간단한 표가 잘 작동합니다.\n\n## 3030분: 흐름 추적\n- 10분: 기록 작성\n\n목표는 완벽한 커버리지가 아닙니다. 테스트 가능한 소수의 발견을 만드는 것이 목적입니다.\n\n앱을 열어 두고 읽으면서 UI를 클릭해 어떤 요청이 발생하는지 관찰하세요. 노트는 특정 엔드포인트, 파라미터, 데이터 소스를 가리켜야 합니다.\n\n한 번에 끝낼 수 있는 워크플로우 예:\n\n1. 진입점과 신뢰 경계를 스케치하세요. 공개 라우트, 로그인 필요 라우트, 관리자 라우트, 웹훅, 업로드, 서드파티 콜백을 적고 사용자 제어에서 서버 신뢰로 데이터가 넘어가는 지점을 표시하세요.\n2. 중요한 각 엔드포인트에 대해 누가 누구인지 증명하는 지점과 그 위치를 적으세요. 체크가 "미들웨어"라면 모든 라우트가 실제로 그 미들웨어를 사용하는지 확인하세요.\n3. 권한 검증도 동일하게 하세요. 위험한 동작(다른 사용자의 데이터 보기, 역할 변경, 내보내기, 삭제) 중 하나를 골라 권한 결정이 데이터베이스 쿼리까지 어떻게 이어지는지 추적하세요.\n4. 사용자 입력이 싱크에 도달하는 과정을 추적하세요. 하나의 파라미터를 선택해 요청에서 SQL/ORM 쿼리, 템플릿 렌더링, 명령 실행, URL 요청(SSRF), 리다이렉트, 파일 경로로 어디로 가는지 따라가세요.\n5. 추적하면서 시크릿과 설정 흐름을 스캔하세요. 토큰이 로그, 클라이언트 코드, 에러 메시지, 환경 덤프에 있는지 찾으세요.\n\n유용한 습관: "괜찮아 보인다"고 판단될 때마다 어떻게 깨뜨릴지 적으세요. 깨뜨릴 시도가 설명되지 않으면 대개 검증이 부족한 것입니다.\n\n## 인증(Authn) 스팟체크: 사용자를 증명하라\n\n인증은 앱이 "이 요청이 이 사용자에게 속한다"고 결정하는 지점입니다. 빠른 스팟체크는 모든 줄을 읽는 것이 아니라, 정체성이 확립되는 지점을 찾아 그 지름길과 실패 경로를 확인하는 것입니다.\n\n신뢰 경계를 찾으세요: 정체성이 처음 생성되거나 수용되는 곳은 어디인가? 세션 쿠키, JWT 베어러 토큰, API 키, 엣지의 mTLS일 수 있습니다. Claude Code에 "익명"이 사용자 id로 바뀌는 정확한 파일과 함수를 지목하고 같은 일을 하는 다른 경로가 무엇인지 나열하라고 요청하세요.\n\n점검할 인증 항목:\n\n- 모든 인증 진입점(웹 로그인, API 토큰, 모바일 인증, 내부 서비스 인증)을 식별하고 일관된 정체성 모델로 수렴하는지 확인하세요.\n- 로그인과 비밀번호 재설정에 대해 속도 제한, 잠금, 사용자 열거(존재 유무에 따른 다른 오류 메시지나 타이밍)를 점검하세요.\n- 세션과 쿠키를 검사하세요: HttpOnly, Secure, SameSite, 만료, 로그인 시 회전(rotation), 권한 변경 시 회전, 로그아웃 무효화(단순히 "쿠키 삭제"가 아닌 서버 측 무효화).\n- MFA와 복구 경로를 검토하세요. 복구 경로가 MFA보다 약하지 않은지(예: 이메일만으로 재설정되어 MFA를 우회하는 경우) 확인하세요.\n- 인증 실패 로깅을 검토하세요: 운영에는 유용하지만 공격자에게 도움이 되는 세부(예: "사용자 존재")나 토큰 덤프가 노출되지 않게 하세요.\n\n실용 예: 재설정 이메일이 "계정이 없습니다"를 반환하면 빠른 열거 문제가 됩니다. 메시지가 일반적이라도 타이밍 차이는 같은 사실을 유출할 수 있으니 응답 시간도 점검하세요.\n\n## 권한(Authz) 스팟체크: 사용자가 허용되었는지 증명하라\n\n권한 부여 오류는 가장 큰 피해를 냅니다: "이 사용자가 이 리소스에서 이 행동을 할 수 있는가?" 빠른 스팟체크는 그 가정을 일부러 깨보려 해야 합니다.\n\n역할과 권한을 평이한 언어로 적으세요. 사람이 이해하기 쉽게:\n\n- 소유자(owner)는 멤버를 초대할 수 있다\n- 멤버는 자신의 프로필을 수정할 수 있다\n- 지원팀은 결제 정보를 볼 수 있지만 플랜을 변경할 수는 없다\n- 관리자(admin)는 프로젝트를 삭제할 수 있다\n\n그 다음 모든 민감 동작이 서버에서(프론트엔드가 아니라) 권한 검사를 하는지 확인하세요. 버튼을 숨기는 것만으로는 충분하지 않습니다. 공격자는 API를 직접 호출할 수 있습니다.\n\n빠른 스캔으로 자주 발견되는 항목:\n\n- 생성, 삭제, 내보내기, 역할 변경, 결제 접근을 하는 엔드포인트/뮤테이션 찾기\n- 각 엔드포인트에 대해 서버 측 권한 검사 찾아보기(프론트엔드가 아님)\n- 사용자 제어 ID(projectId, userId, orgId)를 찾아 소유권 검증이 있는지 확인\n- 관리자 전용 경로가 역할이 없을 때 실패하는지(닫힌 실패) 확인\n- 테넌시 경계 확인: orgId/accountId가 요청 입력에서만 오는지 아닌지, 세션 컨텍스트에서 가져오는지 확인\n\n고전적 IDOR 냄새는 단순합니다: 가 사용자 제어인 같은 요청에서 서버가 현재 사용자나 테넌트 소유 여부를 확인하지 않고 로드하면 문제입니다.\n\n실제 답변을 강제하는 프롬프트 예:\n\n"이 엔드포인트에 대해 접근을 결정하는 정확한 코드를 보여주고, 다른 orgId의 사용자가 접근할 수 있게 하는 구체적 조건을 나열하세요. 없다면 파일과 함수 이름으로 이유를 설명하세요."\n\n## 입력 검증: 나쁜 데이터를 초반에 막기\n\n대부분의 빠른 웹 앱 문제는 앱이 개발자가 예상하지 못한 입력을 수용할 때 시작합니다. "입력"은 사용자나 다른 시스템이 영향을 줄 수 있는 모든 것을 의미합니다.\n\n점검하려는 엔드포인트의 입력을 이름 붙이세요:\n\n- URL 쿼리와 경로 값\n- 요청 본문 필드(중첩 JSON 포함)\n- 헤더(인증 헤더, 콘텐츠 타입, 전달된 IP)\n- 쿠키\n- 파일 업로드(이름, 크기, 타입, 메타데이터)\n\n검증은 데이터가 앱에 들어오는 경계 가까이에서 이뤄져야 합니다. 타입(문자열 vs 숫자), 최대 길이, 필수 여부, 형식(이메일, UUID, 날짜) 같은 기본을 확인하세요.\n\n역할, 상태 필드, 정렬 방향 같은 알려진 값에는 허용목록(allowlist)을 선호하세요. 몇 가지 나쁜 값을 차단하는 것보다 우회하기 어렵습니다.\n\n에러 처리도 확인하세요. 앱이 입력을 거부할 때 원시 값을 응답, 로그, UI에 그대로 반영하지 마세요. 작고 사소한 검증 버그가 데이터 유출이나 인젝션을 돕는 경우가 많습니다.\n\n위험한 엔드포인트(로그인, 검색, 업로드, 관리자 동작)를 위한 간단한 "잘못된 입력" 미니 플랜:\n\n- 과도하게 긴 문자열(10,000자 이상)\n- 잘못된 타입(문자열 대신 배열 등)\n- 예상치 못한 열거 값\n- 의미를 바꿀 수 있는 특수 문자\n- 필수 필드의 빈 값\n\n예: 정렬 파라미터가 임의의 문자열을 허용하면 나중에 SQL 조각이 될 수 있습니다. "date"나 "price" 같은 허용목록은 초기에 그 실수를 방지합니다.\n\n## 빠르게 스캔할 일반적인 인젝션 표면\n\n대부분의 빠른 리뷰는 같은 몇 군데에서 문제를 찾습니다: 사용자 입력이 코드, 쿼리, 경로, URL로 해석되는 곳을 찾아라. 이 섹션에서는 "입력이 신뢰 경계를 넘는다"는 순간을 사냥합니다.\n\n진입점(쿼리 파라미터, 헤더, 쿠키, 업로드, 관리자 폼)에서 데이터가 어디로 가는지 추적하세요.\n\n### 빠른 스캔 대상\n\n다음 패턴을 찾아 각 항목에 대해 구체적인 호출 지점과 페이로드 예시를 요구하세요:\n\n- SQL 인젝션: 문자열로 만든 쿼리, 동적 , 빌더에서 사용자 값을 조인하는 경우\n- XSS: HTML 렌더링, 템플릿, 마크다운 미리보기, 리치 텍스트 에디터에서 "나중에 정화"를 가정하는 경우\n- 명령 인젝션: 이미지 처리, PDF 도구, 백업, 또는 사용자 제어 플래그를 전달하는 같은 셸 호출\n- SSRF: 웹훅, 링크 미리보기, URL로부터 가져오기 기능, 사용자 URL을 받는 내부 상태 체크\n- 경로 탈출(Path traversal): 파일 다운로드 엔드포인트, ZIP 추출, 이후 파일을 이름으로 읽는 업로드 파이프라인\n\n역직렬화와 템플릿 인젝션도 주의하세요. 사용자 제공 JSON, YAML, 템플릿 문자열을 파싱하면 커스텀 타입, 표현식, 서버 측 렌더링을 지원할 때 특히 위험할 수 있습니다.\n\n기능이 URL, 파일명, 포맷된 텍스트를 허용하면 코드 경로와 테스트로 증명할 때까지 악용될 수 있다고 가정하세요.\n\n## 시크릿 처리: 노출과 약한 저장소 찾기\n\n시크릿 문제는 어디를 봐야 할지 알면 대개 쉽게 들립니다. 시크릿이 어디에 있는지, 어디로 실수로 복사되는지에 집중하세요.\n\n시크릿이 자주 나타나는 곳:\n\n- 환경 변수와 앱 설정 파일\n- CI 출력과 빌드 로그(실패한 배포 로그 포함)\n- 클라이언트 번들과 모바일 빌드(사용자에게 배포되는 것)\n- 디버그 엔드포인트, 헬스 페이지, 관리자 도구\n- 에러 페이지, 스택 트레이스, 분석 이벤트\n\n그런 다음 구체적인 답을 요구하세요: 오늘 시크릿이 노출된다면 다음에 무슨 일이 발생하나? 좋은 시스템은 회전 경로(새 키 발급), 폐기(기존 키 비활성화), 빠른 재배포 방법이 있습니다. "나중에 바꿀 것"이라는 대답은 발견으로 다루세요.\n\n최소 권한(least privilege)도 빠른 개선점입니다. 키가 과도한 권한을 갖고 있으면 사고가 커집니다. 테이블을 드롭할 수 있는 DB 사용자, 계정을 관리할 수 있는 서드파티 토큰, 환경 간 공유되는 API 키를 찾아보세요. 서비스별, 환경별 최소 권한 키를 선호하세요.\n\n빠른 스팟체크용 프롬프트 예시:\n\n- "하드코딩된 토큰, 비밀번호, 개인 키를 검색하세요. 정확한 파일 경로와 일치한 문자열 패턴을 나열하세요."\n- "요청 헤더, 쿠키, env vars, 전체 에러 객체를 로그로 남기는 코드를 찾아보세요. 로그 라인과 민감한 필드가 어디에 나타날 수 있는지 보여주세요."\n- "시크릿이 스냅샷, 내보내기, 빌드 아티팩트에 들어갈 수 있는지 확인하세요. 무엇이 캡처되고 어디에 저장되는지 식별하세요."\n\n마지막으로 방어책을 확인하세요: 시크릿을 소스 컨트롤에서 차단(pre-commit/CI), 백업이나 스냅샷에 평문 자격증명이 포함되지 않도록 하세요. 플랫폼이 스냅샷과 롤백을 지원하면 시크릿은 런타임에 주입되고 저장 이미지에 박혀있지 않은지 확인하세요.\n\n## 구체적인 발견을 강제하는 프롬프트(복사-붙여넣기 패턴)\n\n모호한 프롬프트는 모호한 답을 낳습니다. 모델이 증거(정확한 위치, 따라갈 수 있는 추적, 실행 가능한 재현, 주장을 틀리게 하는 조건)를 제시하게 만드세요.\n\n한 번에 하나의 패턴을 사용하고, 결과를 확인한 뒤 수정하도록 요청하세요.\n\n- 파일 수준 증거: "레포에서 auth, sessions, tokens, middleware를 검색하세요. 관련 파일, 함수, 라인 범위를 정확히 이름으로 대고 관련 스니펫을 인용하세요. 코드로 지목할 수 없다면 '증거 없음'이라고 답하세요."\n- 입력에서 싱크로의 추적: "사용자 제어 입력(헤더, 쿼리, 바디, 쿠키) 하나를 골라 엔트리 포인트부터 사용처(SQL, HTML, 셸, 템플릿, 리다이렉트, 파일 경로)까지 단계별 데이터 흐름을 보여주세요. 체인에 있는 각 함수를 나열하세요."\n- 재현 단계: "curl 최소 재현을 주세요(메서드, URL 형태, 헤더, 바디). 예상 상태 코드와 성공/실패 응답 예시를 포함하세요. 가정(역할, 인증 상태)을 명시하세요."\n- 오탐 제어: "이 발견을 반증하려면 무엇을 확인해야 하나요? 구성 플래그, 미들웨어 순서, 허용목록 검증, 파라미터라이즈드 쿼리, 프레임워크 이스케이프 같은 260분 리뷰와 배포 전 짧은 체크를 권합니다.\n\n반복하기 쉽게 재사용 가능한 프롬프트 팩과 체크리스트 템플릿을 만드세요. 경로, 가드, 실패 요청, 기대 동작을 보여주는 구체적 출력에 프롬프트를 집중시키세요. 팀이 이미 작업하는 곳에 팩을 보관해 건너뛰지 않게 하세요.\n\n채팅으로 앱을 만드는 경우 계획 단계에 체크리스트를 넣으세요. authn/authz, 입력, 시크릿에 대한 짧은 "보안 가정"을 추가하고 첫 동작 버전 직후 스팟체크를 실행하세요.\n\n플랫폼 예시: Platforms like Koder.ai (koder.ai) 같은 플랫폼은 빠르게 반복하면서 검토 체크포인트를 유지하기에 잘 맞습니다. 스냅샷과 롤백을 위험한 변경 주변에 두면 보안 수정이 동작을 깨뜨렸을 때도 신속히 처리하며 배포할 수 있습니다.