무료 프롬프트
FREE
스킬
보안 검토 스킬 (security-review) — 외부 노출 보안 점검
이온디
2026.07.17
1
0
평점
0.0
리뷰 0개
사용 방법
본문을 복사해 AI 도구에서 실행하세요
-
STEP 1
아래 본문에서 역할, 목적, 입력값, 출력 형식을 확인합니다.
-
STEP 2
ChatGPT, Claude, Gemini, Codex의 대화창이나 프로젝트 지침에 붙여넣습니다.
-
STEP 3
예시 입력값을 내 업무 정보로 바꾼 뒤 실행하고 결과를 검토합니다.
security-review는 반복 업무를 더 안정적으로 처리하기 위한 AI 에이전트 스킬입니다.
사용자가 “보안검사”, “보안 진단”, “SecureScan”, “Secu-scan”, “security headers”, “CSP/HSTS 확인”, “SSL/TLS 점검”, “DNS/SPF/DMARC 확인”, “노출 파일/시크릿 스캔”, “취약점 리포트 검토”, “보안 점수 올려줘”라고 요청할 때 사용한다. 웹사이트의 외부 보안 진단 결과를 실제 HTTP 응답, 서버/프레임워크 설정, DNS 레코드, 공개 HTML/JS 자산, 코드 정책과 대조해 검증하고, CSP, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, 쿠키 보안, HTTPS 리다이렉트, 민감 파일 노출, 공개 JS 시크릿 패턴, SPF/DMARC, 재검사 비교를 치명도와 우선순위로 정리한다.
사용 방법
Codex나 호환되는 AI 에이전트의 스킬 폴더에 아래 SKILL.md 내용을 저장한 뒤, 설명에 포함된 트리거 문장으로 호출하세요.
사용 예:
security-review 스킬 사용해줘.
이 작업은 security-review 기준으로 진행해줘.
원본 위치
.codex/skills/security-review/SKILL.md
SKILL.md
---
name: security-review
description: 사용자가 “보안검사”, “보안 진단”, “SecureScan”, “Secu-scan”, “security headers”, “CSP/HSTS 확인”, “SSL/TLS 점검”, “DNS/SPF/DMARC 확인”, “노출 파일/시크릿 스캔”, “취약점 리포트 검토”, “보안 점수 올려줘”라고 요청할 때 사용한다. 웹사이트의 외부 보안 진단 결과를 실제 HTTP 응답, 서버/프레임워크 설정, DNS 레코드, 공개 HTML/JS 자산, 코드 정책과 대조해 검증하고, CSP, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, 쿠키 보안, HTTPS 리다이렉트, 민감 파일 노출, 공개 JS 시크릿 패턴, SPF/DMARC, 재검사 비교를 치명도와 우선순위로 정리한다.
---
# Security Review
## 버전
- v1.1.0 (2026-07-14): Secu-scan 리브랜딩 에디션 기준으로 DNS/SPF/DMARC, 노출 민감 파일, 공개 HTML/JS 시크릿 패턴, A~F 등급, AI 수정 프롬프트, 재검사 비교 항목을 추가했다.
- v1.0.0 (2026-07-14): SecureScan 같은 외부 보안 진단 결과를 실제 응답 헤더와 코드 설정으로 재검증하고, CSP/HSTS 등 보안 헤더 보완 우선순위를 제시하는 스킬을 추가했다.
## 목적
- 외부 보안 검사 도구 결과를 그대로 받아들이지 않고 실제 사이트 응답과 코드 설정으로 확인한다.
- 보안 헤더, HTTPS/TLS, 쿠키, 인증 흐름, 민감 경로/파일 노출, DNS 이메일 보안, 공개 자산 시크릿 노출을 출시 전 관점으로 점검한다.
- “점수 올리기”보다 실제 브라우저 방어 효과와 운영 리스크를 기준으로 우선순위를 정한다.
## 절대 규칙
- 운영 사이트에 부하를 주는 침투 테스트, 무차별 대입, 대량 스캔, 파괴적 요청은 수행하지 않는다.
- 사용자가 명시적으로 “수정까지” 요청하기 전에는 코드와 서버 설정을 변경하지 않는다.
- 외부 리포트의 판정을 실제 `curl -I`, 브라우저 네트워크, 서버 설정, 미들웨어 코드로 재확인한다.
- `Content-Security-Policy-Report-Only`는 보고 전용이다. 실제 차단 헤더인 `Content-Security-Policy`와 구분해 평가한다.
- 개발/로컬 도메인과 운영 도메인의 헤더가 다를 수 있으므로 대상 URL과 환경을 분리해 기록한다.
- 보안 조치는 기능 깨짐 가능성이 있으므로 CSP, HSTS, 쿠키 정책은 단계적 적용과 회귀 확인을 권장한다.
## 검수 준비
1. 대상 URL, 리포트 원문, 점검 일시, 점수, 발견 항목을 정리한다.
2. 라이브 URL과 로컬 URL이 다르면 둘 다 확인 가능한지 구분한다.
3. `curl -I` 또는 `curl -sS -D - -o /dev/null`로 루트, 로그인, 게시글 상세, 정적 파일, API 대표 URL의 응답 헤더를 확인한다.
4. 민감 파일 대표 경로, 공개 JS 번들, DNS TXT 레코드는 저속/대표 샘플로만 확인한다.
5. 코드에서 보안 헤더를 설정하는 미들웨어, reverse proxy, 배포 설정, CDN 설정을 찾는다.
6. 외부 도구 결과와 실제 응답이 다르면 캐시, 프록시, 배포 누락, report-only/실제 헤더 차이를 의심한다.
## 핵심 체크리스트
### 1. HTTPS와 TLS
- HTTPS가 적용되어 있고 인증서가 유효한가.
- HTTP가 HTTPS로 리다이렉트되는가.
- 리다이렉트가 루프 없이 canonical 도메인으로 끝나는가.
- 혼합 콘텐츠가 없는가.
- TLS 버전/암호군은 외부 도구 확인이 필요하면 미확인으로 분리한다.
### 2. HSTS
- 운영 HTTPS 응답에 `Strict-Transport-Security`가 있는가.
- 권장 기본값: `max-age=31536000; includeSubDomains`
- 모든 서브도메인이 HTTPS 준비된 것이 확실할 때만 `preload`를 검토한다.
- 로컬/개발 도메인에는 HSTS를 강제하지 않아도 된다.
- HSTS가 없으면 SSL stripping 방어 약화로 Medium 이상 이슈로 기록한다.
### 3. CSP
- 실제 차단 헤더 `Content-Security-Policy`가 있는가.
- `Content-Security-Policy-Report-Only`만 있으면 “CSP 준비 중이나 실제 차단 미적용”으로 기록한다.
- 최소 기준:
- `default-src 'self'`
- `base-uri 'self'`
- `frame-ancestors 'self'` 또는 필요한 도메인
- `object-src 'none'`
- `img-src 'self' data: blob: https:`
- `style-src`, `script-src`, `connect-src`, `font-src`는 실제 외부 리소스에 맞춰 제한
- `unsafe-inline`, `unsafe-eval`은 있으면 이유를 확인하고 제거 계획을 세운다. 프론트 코드가 깨질 수 있으므로 먼저 report-only로 수집 후 enforce 전환한다.
- CSP가 없으면 XSS 피해 확산 방어 약화로 High 이슈로 기록한다.
### 4. 기본 보안 헤더
- `X-Content-Type-Options: nosniff`
- `X-Frame-Options: SAMEORIGIN` 또는 CSP `frame-ancestors`
- `Referrer-Policy: strict-origin-when-cross-origin` 이상
- `Permissions-Policy`로 camera, microphone, geolocation 등 불필요 권한 제한
- `Cross-Origin-Opener-Policy`, `Cross-Origin-Resource-Policy`는 서비스 특성에 따라 선택 적용한다.
### 5. 쿠키와 세션
- 인증 쿠키에 `HttpOnly`, `Secure`, `SameSite=Lax` 또는 필요한 정책이 있는가.
- HTTPS 운영 환경에서 `Secure`가 빠진 인증 쿠키는 High로 본다.
- 로그아웃 후 보호 페이지 접근이 막히는가.
- 외부 리다이렉트가 가능한 `next` 파라미터가 없는지 확인한다.
### 6. 인증/권한 기본
- 로그인 실패, 회원가입, 비밀번호 찾기, 댓글/추천/첨부 API에 rate limit 또는 오류 제어가 있는가.
- 비로그인 API 요청은 401/403으로 막히는가.
- 작성자/관리자 외 수정·삭제가 서버에서 막히는가.
- 오류 응답이 스택트레이스, DB 정보, 비밀값을 노출하지 않는가.
### 7. 민감 경로와 정보 노출
- `/admin`, `/debug`, `/docs`, `/openapi.json`, 백업 파일, `.env`, `.git`, 로그 파일이 공개되지 않는가.
- 대표 민감 파일 경로를 확인한다: `/.env`, `/.git/config`, `/config.php.bak`, `/backup.zip`, `/db.sql`, `/phpinfo.php`, `/server-status`.
- 디렉터리 리스팅이 켜져 있지 않은지 `/uploads/`, `/files/`, `/static/` 같은 공개 디렉터리 대표 경로에서 확인한다.
- robots.txt는 색인 제어용이지 접근 제어가 아니므로 민감 경로 보호를 대체하지 않는다.
- 서버 배너, 프레임워크 디버그 페이지, 상세 예외 화면이 운영에 노출되지 않는가.
### 8. DNS와 이메일 도메인 보안
- `A`, `AAAA`, `CNAME` 기본 해석과 운영 도메인 일관성을 확인한다.
- `TXT` 레코드에서 SPF가 있는지 확인한다. 예: `v=spf1 ...`.
- `_dmarc.{domain}` TXT 레코드에서 DMARC가 있는지 확인한다. 예: `v=DMARC1; p=none/quarantine/reject`.
- DKIM은 발송 서비스마다 selector가 다르므로 selector를 모르면 미확인으로 둔다.
- SPF/DMARC가 없으면 이메일 스푸핑 위험으로 Medium 또는 Low로 기록한다. 메일 발송 도메인이 아니면 감점은 낮춘다.
### 9. 공개 HTML/JS 시크릿 패턴
- 홈, 로그인, 대표 상세, 주요 JS 번들을 대상으로 공개된 API 키/토큰 패턴을 확인한다.
- 탐지 예시: `sk-`, `xoxb-`, `AKIA`, `AIza`, `ghp_`, `Bearer `, `private_key`, `client_secret`, `access_token`, `refresh_token`.
- 공개되어도 되는 클라이언트 키와 비밀 서버 키를 구분한다. 예: 결제 client key는 공개 가능할 수 있으나 secret key는 공개되면 안 된다.
- false positive 가능성이 높으므로 발견 문자열의 주변 맥락, 파일 경로, 용도를 확인한 뒤 판정한다.
### 10. 리포트와 재검사 비교
- 종합 점수와 A~F 등급을 함께 출력한다.
- 등급 기준: A 90~100, B 80~89, C 70~79, D 60~69, F 59 이하. Blocker가 있으면 점수와 관계없이 F 또는 공개 보류로 둔다.
- 각 발견 사항마다 AI 코딩 도구에 붙여넣을 수 있는 수정 프롬프트를 짧게 작성한다.
- 이전 리포트가 있으면 항목별로 `신규`, `유지`, `개선`, `악화`, `해결`을 표시한다.
- 재검사는 같은 URL, 같은 대표 경로, 같은 DNS 기준으로 비교한다.
## SecureScan 리포트 해석 규칙
외부 리포트가 아래처럼 나올 때는 다음 순서로 재확인한다.
- **CSP 누락**:
1. `Content-Security-Policy`와 `Content-Security-Policy-Report-Only`를 모두 확인한다.
2. report-only만 있으면 도구가 “누락”으로 보는 것이 맞다. 실제 차단 헤더를 추가해야 점수가 오른다.
3. 코드에서 CSP를 추가할 경우 먼저 현재 JS/CSS/이미지/폰트/CDN 사용처를 확인해 깨짐을 방지한다.
- **HSTS 누락**:
1. HTTPS 응답에 `Strict-Transport-Security`가 있는지 확인한다.
2. reverse proxy/CDN에서 추가하는지 앱 미들웨어에서 추가하는지 결정한다.
3. 서브도메인 준비 상태를 모르면 `includeSubDomains` 적용 전 운영자 확인을 권장한다.
- **통과 항목**:
- HTTPS, HTTP→HTTPS, TLS 인증서, nosniff, x-frame-options, referrer-policy, permissions-policy가 실제 응답에도 있는지 한 번 더 확인한다.
- **민감 파일 노출**:
- 200이어도 실제 내용이 에러 페이지/SPA fallback인지 구분한다.
- `.env`, `.git/config`, 백업 파일에서 실제 비밀값이나 설정 내용이 보이면 Blocker로 본다.
- **DNS/SPF/DMARC**:
- 외부 DNS 조회가 불가능하면 미확인으로 분리하고 사용자가 DNS 조회 결과를 붙여넣을 수 있는 요청 문구를 제공한다.
- **코드 내 시크릿**:
- 공개 HTML/JS에서만 판단한다. 비공개 서버 소스의 시크릿 존재 여부는 별도 코드 리뷰로 분리한다.
## 점수 산정
100점 만점으로 잠정 점수를 낸다.
- HTTPS/TLS: 15점
- CSP/XSS 방어: 20점
- HSTS/전송 보안: 15점
- 기본 보안 헤더: 15점
- 쿠키/세션: 10점
- 인증/권한/API 방어: 10점
- 민감 파일/시크릿 노출: 10점
- DNS/이메일 보안: 5점
치명도 기준:
- Blocker: 인증 우회, 운영 디버그/비밀값 노출, `.env`/`.git`/DB 백업 실제 노출, 관리자 무단 접근, HTTPS 미적용
- High: CSP 없음, 인증 쿠키 Secure/HttpOnly 누락, 보호 API 권한 우회, 상세 스택트레이스 운영 노출
- Medium: HSTS 없음, rate limit 부족, 과도하게 넓은 CSP, 보안 헤더 일부 누락, SPF/DMARC 부재
- Low: 서버 배너, 사소한 policy 개선, 문서화 부족
## 수정 요청을 받은 경우
1. 먼저 실제 응답 헤더를 다시 확인한다.
2. 앱 미들웨어, reverse proxy, CDN 중 현재 프로젝트가 실제로 사용하는 위치를 찾는다.
3. 운영에 안전한 순서로 수정한다.
- HSTS는 HTTPS 운영 도메인에만 적용한다.
- CSP는 report-only에서 실제 차단으로 바꿀 때 정적 리소스, 에디터, 이미지 업로드, 소셜 로그인, 결제, YouTube 임베드가 깨지지 않는지 확인한다.
4. 수정 후 루트, 로그인, 글쓰기, 상세, 정적 파일, API 대표 URL의 헤더를 재확인한다.
5. 민감 파일 대표 경로, 공개 JS 시크릿 패턴, DNS/SPF/DMARC를 재확인한다.
6. 외부 SecureScan/Secu-scan 결과와 내부 curl 결과가 다르면 캐시/CDN/배포 누락 가능성을 기록한다.
## 출력 형식
```text
보안 검수 범위
- 대상:
- 기준 리포트:
- 확인한 URL:
- 확인하지 못한 범위:
보안 점수
- 점수: 00/100
- 등급: A~F
- 공개 판단:
- 축별 점수:
- HTTPS/TLS:
- CSP/XSS 방어:
- HSTS/전송 보안:
- 기본 보안 헤더:
- 쿠키/세션:
- 인증/권한/API:
- 민감 파일/시크릿 노출:
- DNS/이메일 보안:
주요 이슈
1. [High] 이슈 제목
- 위치:
- 증거:
- 위험:
- 권장 조치:
- 수정 난이도:
- AI 수정 프롬프트:
외부 리포트 대조
- 항목:
- 외부 도구 판정:
- 실제 응답/코드 확인:
- 최종 판정:
Fix 체크리스트
- [ ] [High] CSP 실제 헤더 적용
- [ ] [Medium] HSTS 적용
- [ ] [Blocker] 노출 민감 파일 차단
- [ ] [Medium] SPF/DMARC 레코드 보완
- [ ] [High] 공개 JS/HTML 시크릿 제거
재검사 비교
- 신규:
- 유지:
- 개선:
- 악화:
- 해결:
재검수
- 수정 후 확인 URL:
- 외부 도구 재검사 필요:
```
리뷰
별점과 함께 남기는 사용 후기
아직 리뷰가 없습니다
리뷰를 작성하려면 로그인하세요.
첫 리뷰를 남겨보세요.