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

가벼운 보안 스팟체크란

가벼운 보안 스팟체크는 배포 전에 명백하고 영향이 큰 문제를 빠르게(보통 30~60분) 찾아내기 위한 검토입니다. 전체 감사는 아닙니다. 안전 점검처럼 생각하세요: 실제 앱에서 자주 실패하는 경로를 훑고, 추측이 아닌 증거를 찾습니다.

이 Claude Code 보안 체크리스트는 일상적인 웹 앱에서 가장 자주 깨지는 영역에 집중합니다:

• 인증 가정(사용자를 어떻게 식별하는지)
• 권한 부여(사용자가 무엇을 할 수 있는지)
• 입력 검증
• 시크릿 처리
• 일반적인 인젝션 표면(SQL, 명령 실행, 템플릿 렌더링, 리다이렉트, 업로드)

이는 버그의 부재를 증명하거나 복잡한 위협 행위자를 모델링하거나 침투 테스트를 대체하려는 것이 아닙니다.

"구체적인 발견(Concrete findings)"이란 기록하는 모든 문제에 개발자가 즉시 조치할 수 있는 증거가 있어야 한다는 뜻입니다. 각 발견에 대해 다음을 캡처하세요:

• 정확한 파일과 함수/핸들러 이름
• 위험한 동작을 한 문장으로
• 최소 재현 단계(요청, 페이로드, 클릭 경로)
• 왜 중요한지(영향)와 누가 실행할 수 있는지
• 안전한 수정 방향(전체 재작성 아님)

AI는 도우미일 뿐 권위가 아닙니다. 검색, 요약, 테스트 제안에 활용하되, 코드를 직접 읽고 가능한 경우 실제 요청으로 재현해 확인하세요. 모델이 특정 위치와 단계로 지목하지 못하면 그 주장은 검증되지 않은 것으로 다루세요.

10분 안에 범위 정하기

빠른 검토는 대상 범위를 좁혀야만 효과적입니다. Claude Code에게 무엇을 보게 할지 정하기 전에 오늘 증명하려는 것과 확인하지 않을 것을 결정하세요.

실수로 비용이 발생하거나 데이터가 노출되거나 권한을 부여하는 1~3개의 실제 사용자 여정을 선택하세요. 로그인, 비밀번호 재설정, 결제, 관리자 편집 화면이 좋은 후보입니다.

다음으로 보호해야 할 자산을 구체적으로 적으세요: 사용자 계정, 결제 동작, 개인 데이터, 관리자 전용 작업 등.

그런 다음 위협 가정을 평범한 말로 적으세요. 단순히 호기심 있는 사용자인가, 스크립트를 가진 외부 공격자인가, 일부 접근 권한을 가진 내부자인가? 답에 따라 "충분히 안전"의 기준이 달라집니다.

마지막으로 통과와 실패 기준을 정의해 스팟체크가 감이 아닌 실제 발견으로 끝나게 하세요. 단순한 규칙이 잘 먹힙니다:

• 통과: 모든 민감한 동작에 명시적 인증(authn)과 권한 검사(authz)가 있다.
• 실패: 어떤 엔드포인트라도 클라이언트를 신뢰해 사용자 ID나 역할을 결정한다.
• 통과: 입력은 UI가 아니라 서버 측에서 검증된다.
• 실패: 시크릿이 로그, 설정, 클라이언트 코드에 나타난다.

실패가 어떻게 보일지 설명할 수 없다면 범위가 아직 too fuzzy합니다.

Claude Code에 제공할 컨텍스트 준비

스팟체크는 모델이 올바른 곳을 보고 있어야만 효과가 있습니다. 검토가 추측이 아닌 증거를 낼 수 있도록 소규모 코드 번들과 노트를 모으세요.

보안에 중요한 경로를 공유하는 것부터 시작하세요: 요청 진입점과 누가 누구인지, 무엇을 할 수 있는지 결정하는 코드. 데이터 흐름을 보여주기에 충분한 주변 코드를 포함하세요.

실용적인 번들은 보통 다음을 포함합니다:

• 인증 진입부: 세션/JWT 파싱, 쿠키 설정, 로그인 콜백, 인증 미들웨어
• 라우트 + 핸들러: 컨트롤러, RPC 메서드, GraphQL 리졸버, 백그라운드 잡 핸들러
• 데이터 계층: ORM 쿼리, 원시 SQL 헬퍼, 쿼리 빌더, 민감 테이블 마이그레이션
• 정책 검사: 역할 검사, 소유권 검사, 기능 플래그, 관리자 전용 엔드포인트
• 검증: 요청 스키마 밸리데이터, 파일 업로드 핸들러, 역직렬화 코드

세션 대 JWT, 토큰이 어디에 저장되는지(쿠키 또는 헤더), 리버스 프록시나 API 게이트웨이 동작, 큐/크론 워커, 그리고 어떤 "내부 전용" 엔드포인트가 있는지 같은 환경 노트를 몇 줄 추가해 가정을 명확히 하세요.

버그를 쫓기 전에 진입점, 권한이 필요한 엔드포인트, 접근하는 데이터 저장소의 목록을 요청하세요. 이렇게 하면 놓치는 표면이 줄어듭니다.

또한 구체적인 출력 형식에 합의하세요. 발견, 심각도, 영향을 받는 엔드포인트/파일, 증거(정확한 스니펫 또는 라인 범위), 익스플로잇 시나리오, 수정 제안을 포함한 간단한 표가 잘 작동합니다.

30~60분 검토를 위한 단계별 워크플로우

시간을 정하세요:

• 10분: 상황 파악
• 15~30분: 흐름 추적
• 10분: 기록 작성

목표는 완벽한 커버리지가 아닙니다. 테스트 가능한 소수의 발견을 만드는 것이 목적입니다.

앱을 열어 두고 읽으면서 UI를 클릭해 어떤 요청이 발생하는지 관찰하세요. 노트는 특정 엔드포인트, 파라미터, 데이터 소스를 가리켜야 합니다.

한 번에 끝낼 수 있는 워크플로우 예:

1. 진입점과 신뢰 경계를 스케치하세요. 공개 라우트, 로그인 필요 라우트, 관리자 라우트, 웹훅, 업로드, 서드파티 콜백을 적고 사용자 제어에서 서버 신뢰로 데이터가 넘어가는 지점을 표시하세요.
2. 중요한 각 엔드포인트에 대해 누가 누구인지 증명하는 지점과 그 위치를 적으세요. 체크가 "미들웨어"라면 모든 라우트가 실제로 그 미들웨어를 사용하는지 확인하세요.
3. 권한 검증도 동일하게 하세요. 위험한 동작(다른 사용자의 데이터 보기, 역할 변경, 내보내기, 삭제) 중 하나를 골라 권한 결정이 데이터베이스 쿼리까지 어떻게 이어지는지 추적하세요.
4. 사용자 입력이 싱크에 도달하는 과정을 추적하세요. 하나의 파라미터를 선택해 요청에서 SQL/ORM 쿼리, 템플릿 렌더링, 명령 실행, URL 요청(SSRF), 리다이렉트, 파일 경로로 어디로 가는지 따라가세요.
5. 추적하면서 시크릿과 설정 흐름을 스캔하세요. 토큰이 로그, 클라이언트 코드, 에러 메시지, 환경 덤프에 있는지 찾으세요.

유용한 습관: "괜찮아 보인다"고 판단될 때마다 어떻게 깨뜨릴지 적으세요. 깨뜨릴 시도가 설명되지 않으면 대개 검증이 부족한 것입니다.

인증(Authn) 스팟체크: 사용자를 증명하라

인증은 앱이 "이 요청이 이 사용자에게 속한다"고 결정하는 지점입니다. 빠른 스팟체크는 모든 줄을 읽는 것이 아니라, 정체성이 확립되는 지점을 찾아 그 지름길과 실패 경로를 확인하는 것입니다.

신뢰 경계를 찾으세요: 정체성이 처음 생성되거나 수용되는 곳은 어디인가? 세션 쿠키, JWT 베어러 토큰, API 키, 엣지의 mTLS일 수 있습니다. Claude Code에 "익명"이 사용자 id로 바뀌는 정확한 파일과 함수를 지목하고 같은 일을 하는 다른 경로가 무엇인지 나열하라고 요청하세요.

점검할 인증 항목:

• 모든 인증 진입점(웹 로그인, API 토큰, 모바일 인증, 내부 서비스 인증)을 식별하고 일관된 정체성 모델로 수렴하는지 확인하세요.
• 로그인과 비밀번호 재설정에 대해 속도 제한, 잠금, 사용자 열거(존재 유무에 따른 다른 오류 메시지나 타이밍)를 점검하세요.
• 세션과 쿠키를 검사하세요: HttpOnly, Secure, SameSite, 만료, 로그인 시 회전(rotation), 권한 변경 시 회전, 로그아웃 무효화(단순히 "쿠키 삭제"가 아닌 서버 측 무효화).
• MFA와 복구 경로를 검토하세요. 복구 경로가 MFA보다 약하지 않은지(예: 이메일만으로 재설정되어 MFA를 우회하는 경우) 확인하세요.
• 인증 실패 로깅을 검토하세요: 운영에는 유용하지만 공격자에게 도움이 되는 세부(예: "사용자 존재")나 토큰 덤프가 노출되지 않게 하세요.

실용 예: 재설정 이메일이 "계정이 없습니다"를 반환하면 빠른 열거 문제가 됩니다. 메시지가 일반적이라도 타이밍 차이는 같은 사실을 유출할 수 있으니 응답 시간도 점검하세요.

권한(Authz) 스팟체크: 사용자가 허용되었는지 증명하라

권한 부여 오류는 가장 큰 피해를 냅니다: "이 사용자가 이 리소스에서 이 행동을 할 수 있는가?" 빠른 스팟체크는 그 가정을 일부러 깨보려 해야 합니다.

역할과 권한을 평이한 언어로 적으세요. 사람이 이해하기 쉽게:

• 소유자(owner)는 멤버를 초대할 수 있다
• 멤버는 자신의 프로필을 수정할 수 있다
• 지원팀은 결제 정보를 볼 수 있지만 플랜을 변경할 수는 없다
• 관리자(admin)는 프로젝트를 삭제할 수 있다

그 다음 모든 민감 동작이 서버에서(프론트엔드가 아니라) 권한 검사를 하는지 확인하세요. 버튼을 숨기는 것만으로는 충분하지 않습니다. 공격자는 API를 직접 호출할 수 있습니다.

빠른 스캔으로 자주 발견되는 항목:

• 생성, 삭제, 내보내기, 역할 변경, 결제 접근을 하는 엔드포인트/뮤테이션 찾기
• 각 엔드포인트에 대해 서버 측 권한 검사 찾아보기(프론트엔드가 아님)
• 사용자 제어 ID(projectId, userId, orgId)를 찾아 소유권 검증이 있는지 확인
• 관리자 전용 경로가 역할이 없을 때 실패하는지(닫힌 실패) 확인
• 테넌시 경계 확인: orgId/accountId가 요청 입력에서만 오는지 아닌지, 세션 컨텍스트에서 가져오는지 확인

고전적 IDOR 냄새는 단순합니다: {id}가 사용자 제어인 GET /projects/{id} 같은 요청에서 서버가 현재 사용자나 테넌트 소유 여부를 확인하지 않고 로드하면 문제입니다.

실제 답변을 강제하는 프롬프트 예:

"이 엔드포인트에 대해 접근을 결정하는 정확한 코드를 보여주고, 다른 orgId의 사용자가 접근할 수 있게 하는 구체적 조건을 나열하세요. 없다면 파일과 함수 이름으로 이유를 설명하세요."

입력 검증: 나쁜 데이터를 초반에 막기

대부분의 빠른 웹 앱 문제는 앱이 개발자가 예상하지 못한 입력을 수용할 때 시작합니다. "입력"은 사용자나 다른 시스템이 영향을 줄 수 있는 모든 것을 의미합니다.

점검하려는 엔드포인트의 입력을 이름 붙이세요:

• URL 쿼리와 경로 값
• 요청 본문 필드(중첩 JSON 포함)
• 헤더(인증 헤더, 콘텐츠 타입, 전달된 IP)
• 쿠키
• 파일 업로드(이름, 크기, 타입, 메타데이터)

검증은 데이터가 앱에 들어오는 경계 가까이에서 이뤄져야 합니다. 타입(문자열 vs 숫자), 최대 길이, 필수 여부, 형식(이메일, UUID, 날짜) 같은 기본을 확인하세요.

역할, 상태 필드, 정렬 방향 같은 알려진 값에는 허용목록(allowlist)을 선호하세요. 몇 가지 나쁜 값을 차단하는 것보다 우회하기 어렵습니다.

에러 처리도 확인하세요. 앱이 입력을 거부할 때 원시 값을 응답, 로그, UI에 그대로 반영하지 마세요. 작고 사소한 검증 버그가 데이터 유출이나 인젝션을 돕는 경우가 많습니다.

위험한 엔드포인트(로그인, 검색, 업로드, 관리자 동작)를 위한 간단한 "잘못된 입력" 미니 플랜:

• 과도하게 긴 문자열(10,000자 이상)
• 잘못된 타입(문자열 대신 배열 등)
• 예상치 못한 열거 값
• 의미를 바꿀 수 있는 특수 문자
• 필수 필드의 빈 값

예: 정렬 파라미터가 임의의 문자열을 허용하면 나중에 SQL 조각이 될 수 있습니다. "date"나 "price" 같은 허용목록은 초기에 그 실수를 방지합니다.

빠르게 스캔할 일반적인 인젝션 표면

대부분의 빠른 리뷰는 같은 몇 군데에서 문제를 찾습니다: 사용자 입력이 코드, 쿼리, 경로, URL로 해석되는 곳을 찾아라. 이 섹션에서는 "입력이 신뢰 경계를 넘는다"는 순간을 사냥합니다.

진입점(쿼리 파라미터, 헤더, 쿠키, 업로드, 관리자 폼)에서 데이터가 어디로 가는지 추적하세요.

빠른 스캔 대상

다음 패턴을 찾아 각 항목에 대해 구체적인 호출 지점과 페이로드 예시를 요구하세요:

• SQL 인젝션: 문자열로 만든 쿼리, 동적 ORDER BY, IN (...) 빌더에서 사용자 값을 조인하는 경우
• XSS: HTML 렌더링, 템플릿, 마크다운 미리보기, 리치 텍스트 에디터에서 "나중에 정화"를 가정하는 경우
• 명령 인젝션: 이미지 처리, PDF 도구, 백업, 또는 사용자 제어 플래그를 전달하는 convert 같은 셸 호출
• SSRF: 웹훅, 링크 미리보기, URL로부터 가져오기 기능, 사용자 URL을 받는 내부 상태 체크
• 경로 탈출(Path traversal): 파일 다운로드 엔드포인트, ZIP 추출, 이후 파일을 이름으로 읽는 업로드 파이프라인

역직렬화와 템플릿 인젝션도 주의하세요. 사용자 제공 JSON, YAML, 템플릿 문자열을 파싱하면 커스텀 타입, 표현식, 서버 측 렌더링을 지원할 때 특히 위험할 수 있습니다.

기능이 URL, 파일명, 포맷된 텍스트를 허용하면 코드 경로와 테스트로 증명할 때까지 악용될 수 있다고 가정하세요.

시크릿 처리: 노출과 약한 저장소 찾기

시크릿 문제는 어디를 봐야 할지 알면 대개 쉽게 들립니다. 시크릿이 어디에 있는지, 어디로 실수로 복사되는지에 집중하세요.

시크릿이 자주 나타나는 곳:

• 환경 변수와 앱 설정 파일
• CI 출력과 빌드 로그(실패한 배포 로그 포함)
• 클라이언트 번들과 모바일 빌드(사용자에게 배포되는 것)
• 디버그 엔드포인트, 헬스 페이지, 관리자 도구
• 에러 페이지, 스택 트레이스, 분석 이벤트

그런 다음 구체적인 답을 요구하세요: 오늘 시크릿이 노출된다면 다음에 무슨 일이 발생하나? 좋은 시스템은 회전 경로(새 키 발급), 폐기(기존 키 비활성화), 빠른 재배포 방법이 있습니다. "나중에 바꿀 것"이라는 대답은 발견으로 다루세요.

최소 권한(least privilege)도 빠른 개선점입니다. 키가 과도한 권한을 갖고 있으면 사고가 커집니다. 테이블을 드롭할 수 있는 DB 사용자, 계정을 관리할 수 있는 서드파티 토큰, 환경 간 공유되는 API 키를 찾아보세요. 서비스별, 환경별 최소 권한 키를 선호하세요.

빠른 스팟체크용 프롬프트 예시:

• "하드코딩된 토큰, 비밀번호, 개인 키를 검색하세요. 정확한 파일 경로와 일치한 문자열 패턴을 나열하세요."
• "요청 헤더, 쿠키, env vars, 전체 에러 객체를 로그로 남기는 코드를 찾아보세요. 로그 라인과 민감한 필드가 어디에 나타날 수 있는지 보여주세요."
• "시크릿이 스냅샷, 내보내기, 빌드 아티팩트에 들어갈 수 있는지 확인하세요. 무엇이 캡처되고 어디에 저장되는지 식별하세요."

마지막으로 방어책을 확인하세요: 시크릿을 소스 컨트롤에서 차단(pre-commit/CI), 백업이나 스냅샷에 평문 자격증명이 포함되지 않도록 하세요. 플랫폼이 스냅샷과 롤백을 지원하면 시크릿은 런타임에 주입되고 저장 이미지에 박혀있지 않은지 확인하세요.

구체적인 발견을 강제하는 프롬프트(복사-붙여넣기 패턴)

모호한 프롬프트는 모호한 답을 낳습니다. 모델이 증거(정확한 위치, 따라갈 수 있는 추적, 실행 가능한 재현, 주장을 틀리게 하는 조건)를 제시하게 만드세요.

한 번에 하나의 패턴을 사용하고, 결과를 확인한 뒤 수정하도록 요청하세요.

• 파일 수준 증거: "레포에서 auth, sessions, tokens, middleware를 검색하세요. 관련 파일, 함수, 라인 범위를 정확히 이름으로 대고 관련 스니펫을 인용하세요. 코드로 지목할 수 없다면 '증거 없음'이라고 답하세요."
• 입력에서 싱크로의 추적: "사용자 제어 입력(헤더, 쿼리, 바디, 쿠키) 하나를 골라 엔트리 포인트부터 사용처(SQL, HTML, 셸, 템플릿, 리다이렉트, 파일 경로)까지 단계별 데이터 흐름을 보여주세요. 체인에 있는 각 함수를 나열하세요."
• 재현 단계: "curl 최소 재현을 주세요(메서드, URL 형태, 헤더, 바디). 예상 상태 코드와 성공/실패 응답 예시를 포함하세요. 가정(역할, 인증 상태)을 명시하세요."
• 오탐 제어: "이 발견을 반증하려면 무엇을 확인해야 하나요? 구성 플래그, 미들웨어 순서, 허용목록 검증, 파라미터라이즈드 쿼리, 프레임워크 이스케이프 같은 2~3개 체크를 나열하세요. 존재한다면 위험이 어떻게 달라지는지 설명하세요."
• 가장 작은 안전한 수정 + 테스트: "문제를 차단하면서 정상 케이스를 깨지 않는 가장 작은 변경을 제안하세요. 그런 다음 추가할 테스트 하나(이름, 의도, 입력, 예상 결과)를 작성하세요. 트레이드오프가 있으면 적으세요."

출력이 여전히 모호하면 고정하세요:

"파일 경로, 함수 이름, 위험한 라인, 한 문장 영향만 답하세요."

현실적인 예: 직감에서 검증된 이슈로 전환하기

프로필 업데이트 엔드포인트는 종종 접근 제어 버그를 숨깁니다. 이 체크리스트로 진행할 수 있는 작은 사례를 소개합니다.

시나리오: API 엔드포인트가 사용자 프로필을 업데이트합니다:

PATCH /api/profile?accountId=123와 JSON { "displayName": "Sam" }

Claude Code에게 핸들러를 찾고 accountId가 어떻게 사용되는지 추적해 서버가 소유권을 강제하는지 증명하라고 요청합니다.

자주 보이는 결과:

• Authn: 요청은 세션이나 토큰을 요구하므로 보호된 것처럼 보입니다.
• Authz: 핸들러가 쿼리 문자열의 accountId를 신뢰하고 그 계정을 검사하지 않고 업데이트합니다.
• 입력 검증: displayName은 트림되지만 accountId는 정수인지 검증되지 않습니다.
• 인젝션 표면: SQL이 "... WHERE account_id=" + accountId처럼 문자열 연결로 만들어집니다.

좋은 작성 방식은 구체적입니다:

• 심각도: 높음 (IDOR + 잠재적 SQL 인젝션)
• 증거: 유효한 로그인으로 다른 사용자의 accountId를 바꿔 요청하면 다른 계정이 변경됨; SQL이 신뢰할 수 없는 입력으로부터 구성됨
• 수정: 클라이언트의 accountId를 무시하고 서버에서 인증된 사용자의 계정 ID를 사용; 쿼리를 파라미터화하세요
• 테스트: 다른 계정을 업데이트 시도하고 403을 기대; 숫자가 아닌 accountId는 거부

수정 후 빠르게 재확인하세요:

• 같은 요청을 다른 accountId로 시도해 실패하는지 확인하세요.
• 로그가 쿼리 파라미터가 아닌 인증된 ID를 사용함을 보여주는지 확인하세요.
• 쿼리가 문자열 빌드가 아니라 플레이스홀더/파라미터를 사용하는지 확인하세요.
• 잘못된 입력(문자, 매우 큰 숫자)에 대한 음수 테스트 하나를 실행하세요.

스팟체크에서 실제 이슈를 놓치게 하는 함정

가장 빠르게 취약점을 놓치는 방법은 UI가 시행하는 것을 그대로 신뢰하는 것입니다. 버튼이 숨겨져 있거나 비활성화되어 있다고 해서 권한 검사가 된 것은 아닙니다. 서버가 요청을 허용하면 누구나 다른 사용자 ID나 역할로 재생할 수 있습니다.

또 다른 흔한 실수는 모호한 요청입니다. "보안 리뷰 해줘"는 일반적인 보고서를 낳습니다. 스팟체크는 좁은 범위(어떤 엔드포인트, 어떤 역할, 어떤 데이터)와 엄격한 출력 형식(파일명, 함수, 위험 라인, 최소 재현)을 필요로 합니다.

AI 출력에도 같은 규칙이 적용됩니다: 코드 위치와 실행 단계가 없으면 주장을 수용하지 마세요. 발견에 구체적 코드 위치와 재현 단계가 포함되지 않으면 검증되지 않은 것으로 처리하세요.

스팟체크가 빗나가는 빠른 방법들

자주 반복되는 함정:

• 관리자 페이지라서 "관리자 전용"이라고 가정하고 서버가 강제하는지 확인하지 않음
• "X를 우회할 수 있다"는 식으로 광범위한 결과를 요청하고 구체적 재현을 요구하지 않음
• "가능한 SQL 인젝션"을 수용하지만 쿼리 구성 지점과 입력 경로를 찾지 않음
• 웹훅, 예약 작업, 임포트 도구, 내부 관리자 동작 같은 덜 명백한 진입점을 건너뜀
• 증상만 패치(필터나 정규식 추가)하고 근본 원인(경계에서의 검증 누락, 중앙화된 권한 검사 없음)을 놓침

모든 새 엣지 케이스마다 필터를 추가하고 있다면 멈추세요. 보통 수정은 더 앞단에 있습니다: 경계에서 입력을 검증하고 권한 검사를 명시적이고 중앙화하여 모든 코드 경로가 그것을 사용하게 하세요.

배포 전 빠르게 실행할 수 있는 체크

이것들이 전체 리뷰를 대체하지는 않지만, 모두 피곤할 때 실수로 빠지는 문제를 잡아냅니다. 빠르게 증명할 수 있는 요청, 페이지, 로그 라인을 중심으로 하세요.

보통 효과적인 다섯 가지 빠른 스팟체크:

• 인증 마찰: 연속으로 잘못된 로그인 10회를 시도하세요. 속도 제한, 잠금, 또는 최소한 지연이 있는가? 오류 메시지나 타이밍으로 이메일 존재 여부를 알 수 있는가?
• ID 교체로 권한 확인: 실제 리소스(주문, 송장, 프로필)를 골라 URL, JSON 바디, GraphQL 변수의 ID를 바꿔보세요. 자신의 것이 아닌 데이터(메타데이터 포함)를 받는가?
• 입력 가드레일: 핵심 필드(이메일, 이름, 검색, 파일 업로드)에 긴 문자열, 특이한 유니코드, 예상치 못한 타입(문자열 대신 숫자)을 넣어보세요. 길이 제한과 허용목록을 적용하는가?
• 시크릿 노출: 최근 로그와 클라이언트 번들에서 토큰, API 키, JWT, 또는 "Authorization: Bearer" 문자열을 검색하세요. 에러 페이지도 확인하세요. "스테이징에만 있던 것"이 종종 실수로 배포됩니다.
• 인젝션 표면: SQL, 필터, 템플릿 렌더링, 셸 명령, 리다이렉트 URL에 문자열 연결이 있는지 확인하세요. 입력이 강한 검증 없이 이러한 곳에 도달하면 위험으로 가정하세요.

다음 주에 배포할 수 있는 상위 3개 수정을 적어 두세요. 바람 목록이 아니라 실제로 배포 가능한 항목을 적습니다. 예: (1) 로그인과 비밀번호 재설정에 속도 제한 추가, (2) "id로 가져오기" 엔드포인트에 서버 측 소유권 검사 적용, (3) 검색 필드에 입력 길이 제한과 불허 문자 거부.

다음 단계: 이 체크리스트를 빌드 프로세스의 일부로 만들기

스팟체크는 결과가 실제 배포에 영향을 줄 때만 가치가 있습니다. 이 체크리스트를 일회성 구조가 아닌 작고 반복 가능한 빌드 단계로 취급하세요.

모든 발견을 이해하기 어렵지 않은 백로그 항목으로 만드세요:

• 수정: 코드나 설정에서 무엇이 바뀔지
• 테스트: 수정되었음을 증명할 방법(요청 하나, 단위 테스트 하나, QA 단계 하나)
• 담당자: 책임 있는 한 사람
• 목표일: 다음 릴리스나 특정 날짜
• 증거: 문제를 보여준 파일/엔드포인트와 정확한 요청 또는 페이로드

팀 규모와 위험에 맞는 주기를 선택하세요. 많은 팀은 모든 릴리스마다 하는 것이 최선입니다. 릴리스가 잦다면 월간 30~60분 리뷰와 배포 전 짧은 체크를 권합니다.

반복하기 쉽게 재사용 가능한 프롬프트 팩과 체크리스트 템플릿을 만드세요. 경로, 가드, 실패 요청, 기대 동작을 보여주는 구체적 출력에 프롬프트를 집중시키세요. 팀이 이미 작업하는 곳에 팩을 보관해 건너뛰지 않게 하세요.

채팅으로 앱을 만드는 경우 계획 단계에 체크리스트를 넣으세요. authn/authz, 입력, 시크릿에 대한 짧은 "보안 가정"을 추가하고 첫 동작 버전 직후 스팟체크를 실행하세요.

플랫폼 예시: Platforms like Koder.ai (koder.ai) 같은 플랫폼은 빠르게 반복하면서 검토 체크포인트를 유지하기에 잘 맞습니다. 스냅샷과 롤백을 위험한 변경 주변에 두면 보안 수정이 동작을 깨뜨렸을 때도 신속히 처리하며 배포할 수 있습니다.