웹 애플리케이션 보안 체크리스트를 벽에 붙여두기만 하고 배포 게이트로 쓰지 않으면, 사고는 대개 어려운 취약점보다 빼먹은 기본 설정에서 납니다. 저도 여러 팀에서 비슷한 장면을 반복해서 봤습니다. 로그인은 붙었는데 세션 쿠키 속성이 비어 있고, 파일 업로드는 되는데 저장 위치가 웹 루트 안쪽이고, API는 인증이 있는데 객체 단위 권한 검사가 빠져 있는 식이었죠. WAF(Web Application Firewall, 웹 애플리케이션 방화벽)나 클라우드 보안 서비스가 있어도 이 층의 누락은 결국 애플리케이션 팀이 책임지게 되더라고요.

본 글은 보안 학습과 본인이 관리하는 시스템의 방어를 위한 교육 목적입니다. 타인의 시스템에 대한 무단 접근·공격은 불법이며 법적 처벌 대상입니다. 여기서는 웹 애플리케이션 보안 체크리스트를 단순 항목 나열이 아니라, 배포 직전 무엇을 어떤 기준으로 통과시킬지에 맞춰 다시 묶어보겠습니다. 특히 개발자 입장에서 자주 헷갈리는 지점, 예외를 허용해도 되는 조건, 장애를 만들지 않고 강도를 높이는 순서를 같이 적었습니다.

개발, 배포, 운영 단계에서 인증, 입력값 검증, 비밀정보 관리, 로깅, 취약점 스캔이 연결되는 전체 흐름을 보여주는 이미지입니다.

웹 애플리케이션 보안 체크리스트가 왜 필요한가

체크리스트는 문서가 아니라 릴리스 품질 게이트여야 합니다. 제 기준으로는 세 번 걸어야 의미가 있습니다. 첫째, PR(Pull Request) 리뷰에서 설계 결함을 걸러냅니다. 둘째, CI/CD(Continuous Integration/Continuous Deployment, 지속적 통합/배포)에서 자동으로 확인 가능한 항목을 실패 처리합니다. 셋째, 운영 반영 직전에 환경 차이로 누락된 설정을 다시 봅니다. 이 셋 중 하나라도 빠지면 개발 환경에서는 괜찮았는데 운영에서만 새는 문제가 남습니다.

현장에서 자주 터지는 실패 모드는 생각보다 단순합니다. 임시 우회 설정이 운영까지 남아 있거나, 프레임워크 기본값을 과신하거나, 스캔 도구 결과를 숫자로만 읽고 실제 실행 경로를 보지 않는 경우가 많습니다. 근본 원인은 거의 늘 같습니다. 보안 항목이 기능 정의서에는 없는데 운영 책임에는 포함돼 있기 때문입니다. 그래서 체크리스트는 책임 소재를 분명히 하는 문서이기도 합니다. 누가 보고, 언제 막고, 어떤 경우 예외를 허용하는지까지 있어야 흔들리지 않습니다.

웹 애플리케이션 보안 체크리스트에서 보는 OWASP Top 10

OWASP Top 10을 그대로 외우는 건 실무에서 큰 도움이 안 될 때가 많습니다. OWASP도 이 목록을 최소 기준이자 출발점에 가깝다고 설명합니다. 개발자는 위험 범주를 코드와 설정의 점검 포인트로 번역해서 보는 편이 훨씬 실용적입니다. 제가 팀 문서로 옮길 때는 아래처럼 바꿔 적습니다.

• Broken Access Control(접근 제어 실패): 요청 단위가 아니라 객체 단위로 권한을 확인하는지 봅니다.
• Cryptographic Failures(암호화 실패): TLS 종료 지점, 쿠키 보안 속성, 저장 시 암호화 대상이 맞는지 봅니다.
• Injection(인젝션): 쿼리 생성, 명령 실행, 템플릿 렌더링에서 입력이 코드로 해석될 여지가 있는지 봅니다.
• Security Misconfiguration(보안 설정 오류): 디버그 모드, 기본 계정, 관리 포트 노출, 과한 CORS(Cross-Origin Resource Sharing) 허용을 봅니다.
• Vulnerable and Outdated Components(취약하거나 오래된 구성요소): 취약 버전 자체보다 실행 경로에 실제로 닿는지, 직접 의존성인지 먼저 봅니다.
• Identification and Authentication Failures(식별 및 인증 실패): 세션 고정, 토큰 만료, 재인증 정책, 관리자 기능 보호를 봅니다.

이렇게 바꿔 놓으면 보안팀 용어를 개발 작업으로 연결하기 쉬워집니다. 제 경험상 팀이 가장 빨리 개선하는 영역도 여기입니다. 보안 이슈라고 적는 순간 막연해지는데, 이 API는 객체 소유자 검사가 빠져 있다고 쓰면 바로 수정 단위가 되거든요.

실무에서 바로 쓰는 웹 애플리케이션 보안 체크리스트

항목은 많아 보여도, 배포 전에 정말 체크할 것만 남기면 의외로 운영 가능합니다. 저는 아래 10개를 기본 축으로 둡니다. 관리자 페이지, 일반 사용자 서비스, 내부 API까지 거의 공통으로 먹힙니다.

1. 인증과 세션: 세션 쿠키에 HttpOnly, Secure, SameSite가 있는지, 세션 만료와 재발급 정책이 분리돼 있는지 봅니다.
2. 인가와 권한: 화면 숨김과 별개로 서버가 리소스별 권한을 검증하는지 봅니다.
3. 입력값 검증: 허용 목록 기준인지, 길이 제한과 타입 검사가 서버에서 강제되는지 봅니다.
4. 출력 인코딩: HTML, URL, JavaScript 문자열, JSON 응답 문맥을 섞지 않는지 봅니다.
5. 비밀정보 관리: 코드 저장소, 빌드 로그, 런타임 환경 변수 출력, 에러 리포트에 시크릿이 남지 않는지 봅니다.
6. 의존성 관리: 취약 패키지 유무보다 수정 가능 여부, 직접 의존성 여부, 런타임 노출 여부를 같이 봅니다.
7. 보안 헤더: Content-Security-Policy, X-Content-Type-Options, Referrer-Policy가 실제 응답에 붙는지 확인합니다.
8. 로깅과 모니터링: 로그인 실패, 권한 거부, 관리자 기능 실행, 비정상 오류는 남기되 민감정보는 마스킹합니다.
9. 에러 처리: 사용자 응답은 단순하게, 내부 로그는 추적 가능하게 분리돼 있는지 봅니다.
10. 파일 업로드: 확장자뿐 아니라 MIME 타입, 저장 경로, 후처리 파이프라인, 실행 권한을 같이 봅니다.

웹 애플리케이션 보안 체크리스트 우선순위와 판정 기준

체크리스트를 돌릴 때 제가 고정으로 보는 결정 포인트

보안 점검은 좋은 설정을 모으는 일이 아니라 충돌하는 목표 사이에서 우선순위를 정하는 일에 가깝습니다. 예를 들어 CSP(Content Security Policy)는 강하게 잠글수록 안전하지만, 이미 인라인 스크립트와 다중 CDN에 기대고 있는 서비스라면 한 번에 강제 적용하면 장애가 납니다. 반대로 SameSite 쿠키는 보수적으로 잡을수록 좋지만 외부 인증 연동이 있으면 리다이렉트 흐름을 깨뜨릴 수 있습니다. 이 지점에서 성급하게 밀어붙이면 보안팀도 개발팀도 둘 다 지치더라고요.

실전 구현 1: HTTP 보안 헤더와 쿠키 설정

헤더는 비용 대비 효과가 좋습니다. 다만 추가했다와 제대로 적용됐다는 완전히 다른 얘기입니다. 리버스 프록시에서 넣었는데 애플리케이션 서버가 덮어쓰는 경우도 있고, CDN이 일부 헤더를 제거하는 경우도 있습니다. 제 기준으로는 응답에 실제로 존재하는지, 브라우저 콘솔에서 정책 충돌이 없는지까지 봐야 끝입니다. 이거 확인 안 하면 겉으로만 안전해 보이는 상태가 은근 자주 남습니다.

server {
    listen 443 ssl http2;
    server_name example.com;

    add_header X-Content-Type-Options "nosniff" always;
    add_header X-Frame-Options "DENY" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;
    add_header Permissions-Policy "geolocation=(), microphone=(), camera=()" always;
    add_header Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; object-src 'none'; frame-ancestors 'none'; base-uri 'self'; form-action 'self'; upgrade-insecure-requests" always;

    # nginx 1.19.3+ 기준
    proxy_cookie_flags ~ secure httponly samesite=lax;

    location / {
        proxy_pass http://app_upstream;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Request-Id $request_id;
    }
}

여기서 주의할 점도 분명합니다. X-Frame-Options: DENY는 관리 콘솔이나 외부 임베드 요구가 있으면 충돌할 수 있습니다. SameSite=Strict는 가장 보수적이지만 외부 로그인 연동이나 결제 리다이렉트 흐름을 깨뜨릴 수 있어, 일반적인 웹앱은 Lax부터 검토하는 편이 현실적입니다. style-src 'unsafe-inline'은 이상적이진 않지만, 기존 서비스에서 인라인 스타일 제거가 안 끝났다면 임시로 두고 범위를 줄여가는 식이 보통 더 안전합니다.

검증은 아래 정도면 충분합니다. 중요한 건 한 번 찍고 끝내지 않고, 로그인 전후 응답과 주요 페이지 응답을 각각 보는 겁니다. 쿠키 속성은 인증 이후에야 보이는 경우가 많거든요.

curl -I https://example.com
curl -s -D - -o /dev/null https://example.com | grep -Ei 'content-security-policy|x-frame-options|x-content-type-options|referrer-policy|permissions-policy'

# 로그인 후에는 브라우저 개발자 도구 또는 프록시에서 Set-Cookie 속성을 확인
# 확인 포인트: HttpOnly; Secure; SameSite=Lax 또는 SameSite=Strict

판단 기준도 애매하게 두지 않는 편이 좋습니다. 보안 헤더가 아예 없으면 설정 누락으로 보고 바로 수정합니다. CSP 위반 로그가 다수 보이면 정책이 앱 구조와 맞지 않는다는 뜻이지, 무조건 완화하라는 의미는 아닙니다. 어떤 스크립트나 스타일이 어디서 로드되는지부터 분류해야 합니다. 관련 글이 있다면 여기서 보안 헤더 가이드나 OWASP Top 10 해설로 내부 링크를 연결해 두면 검색 유입에도 도움이 됩니다.

리버스 프록시에서 보안 헤더를 추가하고, 뒤쪽 애플리케이션으로 요청을 전달하는 구조를 설명하는 이미지입니다.

실전 구현 2: 의존성 취약점 점검과 결과 읽는 법

의존성 스캔은 돌렸느냐보다 읽을 줄 아느냐가 더 중요합니다. 현업에서 진짜 시간을 잡아먹는 건 경고 숫자보다 우선순위 판단입니다. 저는 세 가지만 먼저 봅니다. 직접 의존성인가, 수정 가능한가, 운영 런타임에 실제로 실리나. 이 순서로 보면 노이즈가 꽤 줄어듭니다.

# Node.js
npm audit --audit-level=high
npm outdated
npm ls --depth=2

# Python 3.10+ 환경 예시
python -m pip install --upgrade pip
python -m pip install pip-audit
pip-audit
python -m pip list --outdated

npm audit 결과에서 fix available가 있으면 예외 등록보다 업데이트 가능성부터 보는 게 맞습니다. 다만 자동 수정이 항상 정답은 아닙니다. 메이저 버전 상승이 포함되면 빌드나 런타임 동작이 바뀔 수 있으니까요. 저는 직접 의존성이면 changelog를 확인하고 테스트가 있는 범위에서 먼저 올리고, 간접 의존성이면 상위 패키지 업데이트로 해결되는지부터 봅니다.

초반에 제가 가장 많이 실수했던 것도 여기였습니다. CI에서 high 이상이면 전부 배포 차단으로 걸어두니, 결국 개발팀이 예외 파일만 늘리더라고요. 그 뒤부터는 룰을 바꿨습니다. 운영 노출 경로 + 수정 가능 + 직접 의존성이면 차단, 그 외는 보완 통제와 일정 관리로 보되 만료일 없는 예외는 금지. 이 기준이 있어야 스캔 도구가 업무를 막는 장치가 아니라 우선순위 도구가 됩니다.

결과 해석 기준

• high 또는 critical이라도 개발 전용 패키지인지 운영 경로인지 먼저 구분합니다.
• fix available가 있으면 예외보다 업데이트를 우선합니다.
• 같은 루트 패키지에서 파생된 경고는 묶어서 봐야 실제 작업량이 보입니다.
• 패치가 없으면 차단보다 보완 통제를 문서화하고 재검토 일정을 박아두는 편이 낫습니다.

실전 구현 3: 시크릿 관리와 로그 마스킹

시크릿은 코드에만 안 넣으면 끝이라고 생각하기 쉬운데, 실제 누출 경로는 훨씬 많습니다. CI 로그, 컨테이너 시작 스크립트, 예외 스택, 디버그 엔드포인트, 운영자가 급히 남긴 임시 로그가 다 후보입니다. 특히 장애 대응 중에 잠깐 보자고 찍은 로그가 오래 남는 경우가 정말 많습니다. 이 부분은 한 번 터지면 수습이 꽤 번거롭더라고요.

# 런타임 환경 변수 이름만 점검
printenv | cut -d= -f1 | grep -Ei 'token|secret|password|key'

# 저장소 내 하드코딩 흔적 점검
git grep -nE '(API_KEY|SECRET_KEY|PASSWORD|TOKEN|ACCESS_KEY|PRIVATE_KEY)'

# 로그 샘플에서 민감 키 이름 확인
grep -RniE 'authorization:|bearer |set-cookie|password|secret|token' ./logs 2>/dev/null

이 명령은 어디까지나 자신이 관리하는 시스템의 방어 점검용입니다. 결과를 외부에 공유하거나 협업 채널에 그대로 붙이면 안 됩니다. 제 경험상 가장 안전한 운영 방식은 두 가지입니다. 첫째, 시크릿 값 자체를 로그에 남기지 않도록 애플리케이션 레벨에서 필터링합니다. 둘째, 장애 분석에 필요한 식별자는 토큰 전체가 아니라 해시나 앞뒤 일부만 남깁니다.

예를 들어 로그에 Authorization 헤더 전체를 남기면 분석은 편하지만 유출 리스크가 너무 큽니다. 반대로 아무것도 안 남기면 장애 추적이 막힙니다. 저는 보통 request id, 사용자 내부 식별자, 권한 결과, 실패 원인 코드까지만 남기고, 비밀번호·세션 ID·Bearer 토큰 전문은 금지합니다. 여기서 중요한 건 민감정보를 빼자가 아니라 분석 가능한 최소 정보만 남기자는 원칙입니다.

재현 가능한 점검 시나리오: 권한 검증 누락 찾기

추상적인 원칙보다 실제 점검 절차 하나가 더 오래 남습니다. 그래서 저는 배포 전 권한 검증 확인을 꼭 시나리오로 남깁니다. 대상은 관리자 페이지, 주문 조회, 프로필 수정, 첨부파일 다운로드처럼 사용자별 소유권이 분명한 기능입니다. 절차는 복잡하지 않습니다. 내가 관리하는 테스트 환경에서 정상 계정으로 로그인하고, 네트워크 탭에서 해당 요청의 URL, 메서드, 응답 코드를 확인합니다. 그런 다음 같은 계정 상태에서, 시스템이 허용하지 않아야 하는 다른 리소스에 대한 접근 요청이 서버에서 차단되는지만 봅니다.

여기서 핵심은 우회 기법을 늘어놓는 게 아니라 서버가 객체 소유권을 기준으로 차단하는지 확인하는 데 있습니다. 정상이라면 403 Forbidden 또는 서비스 정책에 맞는 거부 응답이 나와야 합니다. 만약 화면에서는 버튼이 숨겨져 있는데 응답 자체는 나온다면, 그건 거의 전형적인 Broken Access Control입니다. 프런트엔드 조건 분기와 서버 권한 검증을 같은 것으로 취급한 결과죠.

이 시나리오가 좋은 이유는 재현성이 있기 때문입니다. QA가 다시 돌리기 쉽고, 개발자가 수정 후 검증 기준으로 삼기 쉽습니다. 또 성능 부담도 거의 없습니다. 별도 스캐너 없이 브라우저 개발자 도구와 애플리케이션 로그만으로 충분히 확인 가능한 경우가 많습니다. 저는 이런 체크가 문서에 한 줄로만 적혀 있을 때보다, 어떤 화면에서 무엇을 봐야 하는지 적혀 있을 때 팀이 훨씬 덜 놓친다고 봅니다.

정상 사용자 요청과 권한 없는 요청을 구분하고, 서버가 403으로 차단하는 흐름을 보여주는 이미지입니다.

주의사항과 트러블슈팅

보안 설정은 강하게 넣을수록 좋아 보이지만, 운영에서는 늘 부작용과 같이 옵니다. 그래서 저는 장애를 만드는 설정과 리스크를 줄이는 설정을 구분해서 적용합니다. 이 선을 잘 잡아야 팀이 보안을 싫어하지 않습니다.

• CSP 적용 후 화면이 깨짐: 대개 근본 원인은 인라인 스크립트, 서드파티 CDN, 레거시 위젯입니다. 이럴 땐 정책을 즉시 느슨하게 풀기보다 Report-Only로 위반 출처를 수집하고, 인라인 제거 작업부터 시작하는 편이 낫습니다.
• SameSite 설정 후 로그인 연동 문제: OAuth 2.0, SSO(Single Sign-On), 결제 리다이렉트가 있으면 Strict가 과할 수 있습니다. 외부 리다이렉트가 있는 웹앱은 먼저 Lax를 검토하세요.
• 취약점 스캔 결과가 너무 많음: 근본 원인은 중복 경고와 간접 의존성입니다. 루트 패키지별로 묶고, 직접 의존성부터 줄이는 편이 실제 효과가 큽니다.
• 에러를 숨겼더니 운영 분석이 어려움: 사용자 응답과 내부 로그를 분리하지 않았기 때문입니다. 외부 응답은 일반화하고, 내부에는 request id, 예외 클래스, 상위 원인만 남기면 됩니다.

파일 업로드는 특히 낙관적으로 보면 안 됩니다. 확장자 검사만으로는 부족하고, 저장 위치가 웹 루트 안쪽이면 더 위험합니다. 제 추천은 분명합니다. 사용자 업로드는 웹에서 직접 실행되지 않는 위치에 저장하고, 필요하면 별도 서빙 계층이나 비공개 스토리지의 서명 URL 같은 방식으로 노출하세요. 이미지라면 업로드 직후 원본을 그대로 노출하기보다 후처리 파이프라인을 거친 파생본만 서빙하는 편이 더 안전합니다. 원본 메타데이터(EXIF 등) 처리 여부도 같이 확인하셔야 합니다.

웹 애플리케이션 보안 체크리스트 검증: 배포 전에 무엇을 확인하면 되나

배포 직전 검증은 길게 할 필요 없습니다. 대신 짧아도 빠뜨리면 안 되는 순서가 있습니다. 제가 운영 중인 서비스에서 주로 쓰는 순서는 아래와 같습니다. 이 순서가 좋은 이유는 헤더, 권한, 의존성, 로그 노출처럼 서로 다른 계층을 짧은 시간 안에 교차 검증할 수 있기 때문입니다.

1. 주요 응답 헤더 확인: curl -I와 실제 로그인 후 응답에서 헤더와 쿠키 속성을 봅니다.
2. 로그인/권한 흐름 확인: 일반 사용자와 관리자 요청이 서버에서 의도대로 구분되는지 봅니다.
3. 취약점 스캔 결과 확인: 직접 의존성, 수정 가능, 런타임 노출 여부로 우선순위를 정합니다.
4. 로그 샘플 확인: 토큰, 비밀번호, 개인정보가 평문으로 남지 않는지 확인합니다.
5. 에러 페이지 확인: 내부 경로, 프레임워크 버전, 스택 트레이스 노출이 없는지 봅니다.

이때 기준을 분명히 적어두면 팀이 덜 흔들립니다. 예를 들어 인증·권한 실패는 예외 없이 수정 대상, 직접 의존성의 수정 가능한 고위험 취약점은 배포 전 우선 조치, 로그 민감정보 노출은 기능 영향과 무관하게 즉시 수정, CSP 경고는 실제 차단 영향과 위반 출처를 확인한 뒤 단계 적용. 이렇게 써두면 이번엔 바쁘니까 넘어가자는 말이 줄어듭니다.

# 배포 전 방어 점검 예시 순서
curl -I https://example.com
curl -s -D - -o /dev/null https://example.com/login | grep -Ei 'set-cookie|content-security-policy|x-frame-options|x-content-type-options'
npm audit --audit-level=high
pip-audit
git grep -nE '(API_KEY|SECRET_KEY|PASSWORD|TOKEN)'
# 로그 샘플은 운영 정책에 따라 마스킹된 사본으로만 확인

여기서 하나 더 중요합니다. 자동화 가능한 항목과 사람 판단이 필요한 항목을 섞지 않는 게 좋습니다. 헤더 존재 여부, 의존성 스캔, 하드코딩 흔적 검색은 CI에서 자동화하기 좋습니다. 반면 권한 설계의 타당성, CSP 위반 허용 범위, 예외 승인 타당성은 여전히 사람이 봐야 합니다. 둘을 구분하지 않으면 자동화가 과신으로 바뀌거나, 반대로 전부 수작업이 되어 금방 지칩니다.

헤더 점검, 의존성 스캔, 권한 검증, 로그 마스킹 상태를 한눈에 보여주는 결과 요약 이미지입니다.

운영 문서로 남길 때 좋은 형태

체크리스트는 문서함에 들어가면 죽습니다. 살아 있으려면 PR 템플릿, 배포 파이프라인, 장애 대응 문서에 각각 연결돼야 합니다. 제가 추천하는 방식은 문서를 길게 쓰는 게 아니라, 각 접점에 질문을 짧게 심는 겁니다. 예를 들어 PR 템플릿에는 새 API 추가 시 인증/인가 확인, 민감정보 로그 출력 없음, 시크릿 하드코딩 없음 정도만 있어도 효과가 큽니다. 배포 파이프라인에는 헤더 검사, 의존성 스캔, 기본 grep 검사를 자동화하고요.

반대로 하지 말아야 할 것도 있습니다. 체크리스트를 보안팀 전용 문서로 분리해 두는 방식입니다. 그러면 개발자는 릴리스 압박을 먼저 받고, 보안 항목은 마지막 승인 절차로만 남습니다. 그 구조에서는 늘 늦습니다. 개발자가 수정할 수 있는 형태로, 배포 전에 다시 확인할 수 있는 문장으로 바꿔야 실제로 작동합니다.

FAQ: 현업에서 자주 나오는 질문

보안 도구를 도입했는데도 왜 불안할까요?

도구는 탐지해주지만, 권한 설계와 예외 판단을 대신해주지는 않습니다. 특히 객체 단위 권한, 로그 민감정보, 운영 설정 차이는 도구만으로 다 걸러지지 않습니다. 그래서 웹 애플리케이션 보안 체크리스트가 필요합니다.

개발 속도가 느려지지 않나요?

초반에는 조금 느려집니다. 다만 운영 사고가 나면 기능 개발, 고객 대응, 로그 조사, 롤백까지 한 번에 붙습니다. 제가 체감한 차이는 단순했습니다. 초기에 배포 기준을 분명히 둔 팀이 결국 더 빨랐습니다. 재작업이 줄기 때문입니다.

OWASP Top 10을 다 외워야 하나요?

그럴 필요 없습니다. 인증, 권한, 입력값, 설정, 의존성 같은 개발 작업 단위로 번역해서 보시면 됩니다. 외우는 것보다 배포 체크 질문으로 바꾸는 편이 훨씬 실용적입니다.

인증, 인가, 입력값 검증, 보안 헤더, 의존성 관리, 로그 마스킹을 핵심만 정리한 요약 이미지입니다.

마무리: 상황별로 이렇게 가시면 됩니다

이미 운영 중인 서비스에서 빠르게 리스크를 줄여야 한다면, 저는 권한 검증 확인 → 보안 헤더와 쿠키 속성 점검 → 의존성 스캔 우선순위 정리 → 시크릿·로그 점검 순서로 가시라고 말씀드립니다. 개인정보 처리 API나 관리자 기능이 있으면 접근 제어가 첫 번째입니다. 정적 페이지 비중이 큰 서비스라면 CSP와 배포 헤더 설정이 먼저고요. 외부 로그인 연동이 많다면 SameSite와 리다이렉트 흐름부터 조심해서 보셔야 합니다.

신규 프로젝트라면 더 단순합니다. PR 템플릿에 체크 항목을 심고, CI에 자동 검사 가능한 부분을 붙이고, 운영 반영 직전에 권한과 로그 샘플만 사람이 다시 보면 됩니다. 이 순서가 가장 덜 지치고, 가장 오래 갑니다.

보안은 거대한 장비보다 작은 누락에서 먼저 무너집니다. 본 글은 보안 학습과 본인이 관리하는 시스템의 방어를 위한 교육 목적이며, 타인의 시스템에 대한 무단 접근·공격은 불법이며 법적 처벌 대상입니다. 체크리스트를 문서로만 두지 말고 배포 흐름에 연결해 두세요. 그 순간부터 품질 관리가 아니라 사고 예방 장치가 됩니다.