SimpleWebUtils
ENKO
모든 도구로 돌아가기

보안 헤더 확인기 | 마지막 응답 점검

보안브라우저에서 실행(업로드 없음)

크기가 제한된 HTTP 응답 헤더 캡처를 붙여넣고 마지막 응답의 시행 CSP, RFC 6797 HSTS, nosniff, 프레임 보호, Referrer-Policy, Permissions-Policy, 교차 출처 정책을 점검합니다. 분석은 로컬에서 이루어지며 Report-Only 모니터링과 실제 시행을 구분하고, 사이트의 안전을 인증한다고 과장하지 않고 응답 문맥에 맞는 검토 결과를 제공합니다.

다음에 할 작업

관련 작업 흐름을 이어가거나 이 작업 다음에 자주 사용하는 도구를 열어보세요.

작업 가이드

배포 전에 Content-Security-Policy 헤더 분석하기

CSP가 필요한 리소스를 차단하거나 후보 정책이 과도한 보고서를 만들거나 프록시가 의도한 헤더를 바꿀 때 사용하는 절차입니다. 로컬 정책 파싱, 브라우저 위반 증거, 마지막 배포 엣지 재확인을 결합하며 정적 결과를 보안 인증으로 취급하지 않습니다.

열기관련 도구

CSP 헤더 분석기 | Content Security Policy 검토

CSP 정책, 첫 유효 directive, source expression과 시행 문맥을 로컬에서 검토합니다.

열기관련 도구

요청·응답 디버깅용 HTTP 헤더 파서

HTTP 헤더 블록을 로컬에서 분석하고 민감값 마스킹과 프로토콜 진단을 제공합니다.

열기관련 도구

IDN 변환기: 유니코드와 퓨니코드 도메인 변환

IDN 하나를 엄격하게 검증하며 유니코드와 퓨니코드 사이에서 변환합니다.

열기

이 도구 사용 방법

curl -I, 브라우저 DevTools, CDN 로그, 리버스 프록시에서 배포 응답을 캡처하고 공유 전 쿠키, Authorization 값, 불필요한 비밀정보를 제거합니다.

응답 하나 또는 리다이렉트 체인을 붙여넣습니다. 제한된 입력을 로컬에서 파싱하며 마지막 응답 블록만 판정합니다.

감지된 응답 종류를 확인합니다. 명시적인 HTML에는 문서 권장 항목을 적용하고, 비문서 콘텐츠에서는 HTML 전용 누락을 생략하며, 종류를 모르면 보수적으로 검토합니다.

HSTS max-age=0, 효력이 없는 시행 CSP, 스크립트에 영향을 주는 wildcard나 unsafe source 같은 고위험 항목부터 해결합니다.

Report-Only는 시행이 아니고 HSTS는 HTTPS에서만 동작하며 COOP와 COEP는 popup과 교차 출처 리소스에 영향을 줄 수 있다는 배포 문맥에서 경고를 검토합니다.

보고서를 복사하거나 다운로드해 출시 체크리스트에 남긴 뒤 실제 엣지를 다시 확인하고 인증, 인가, 의존성, 애플리케이션 보안 테스트를 이어갑니다.

이 도구를 써야 할 때

프로덕션 출시 검토

middleware, framework, CDN, 리버스 프록시 변경 뒤 최종 공개 HTML 응답을 출시 기준선과 비교합니다.

CSP 전환 확인

CSP 전환이 Report-Only 관찰에 머물고 의도한 정책이 시행 헤더로 옮겨지지 않은 상태를 찾습니다.

엣지와 리다이렉트 비교

리다이렉트 체인과 대체 호스트를 비교해 apex, www, 언어 경로, 오류 응답에서 헤더가 빠진 지점을 찾습니다.

교차 출처 격리 준비

교차 출처 격리 문서가 필요한 API를 켜기 전에 COOP와 COEP가 호환되는 쌍인지 확인합니다.

로컬 검토 증거

내부 URL을 제3자에게 제출하지 않고 비밀정보를 줄인 반복 가능한 요약을 PR, 장애 기록, 배포 체크리스트에 첨부합니다.

흔한 실수

배포 엣지 대신 localhost만 확인함

개발 서버에는 CDN, 리버스 프록시, 호스팅 엣지가 추가하는 규칙이 없을 수 있습니다. apex, www, 언어별 경로를 포함해 사용자가 실제로 받는 공개 응답을 캡처하세요.

Report-Only를 실제 보호로 오해함

Content-Security-Policy-Report-Only는 위반을 기록하지만 차단하지 않습니다. 전환 중 관찰용으로 유지할 수 있지만 시행 CSP 기준을 충족한 것으로 계산하면 안 됩니다.

잘못된 응답 블록을 읽음

curl 캡처에는 리다이렉트와 마지막 응답이 함께 들어갈 수 있습니다. 각 hop을 의도적으로 확인하고 리다이렉트뿐 아니라 최종 HTML 응답에도 정책이 있는지 보세요.

HTTPS 범위 확인 없이 HSTS를 켬

안전하지 않은 HTTP에서 받은 HSTS는 무시되고 max-age=0은 저장된 정책을 제거합니다. includeSubDomains는 HTTPS가 준비되지 않은 하위 도메인을 막을 수 있으므로 적용 범위를 먼저 확인하세요.

깨끗한 결과를 보안 인증서처럼 사용함

헤더는 특정 브라우저 위험을 줄일 뿐 인증, 인가, 세션, 의존성 취약점, 서버 설정, 애플리케이션 로직을 시험하지 않습니다. 별도의 보안 검사를 출시 계획에 남겨 두세요.

예시

의도적으로 구성한 HTML 기준선 점검

1년 이상의 HSTS, 프레임을 제한하는 시행 CSP, nosniff, 보수적인 referrer 정책, 제한된 권한, 완성된 COOP/COEP 격리 쌍을 가진 HTML 응답입니다.

입력
HTTP/2 200
content-type: text/html; charset=utf-8
strict-transport-security: max-age=63072000; includeSubDomains
content-security-policy: default-src 'self'; object-src 'none'; frame-ancestors 'none'
x-content-type-options: nosniff
referrer-policy: strict-origin-when-cross-origin
permissions-policy: camera=(), microphone=(), geolocation=()
cross-origin-opener-policy: same-origin
cross-origin-embedder-policy: require-corp
출력
문서 응답, 보안 헤더 7개 감지, 누락 권장 항목 0개, 경고 0개, 고위험 0개입니다. 시행 CSP와 완성된 COOP/COEP 격리 쌍이 있습니다.

Report-Only 전환 누락 찾기

모니터링 정책은 배포 전 관찰에 유용하지만 CSP나 frame-ancestors를 시행하지 않습니다. 결과에는 시행 CSP와 프레임 보호가 계속 누락으로 남습니다.

입력
HTTP/2 200
content-type: text/html
strict-transport-security: max-age=31536000
content-security-policy-report-only: default-src 'self'; frame-ancestors 'none'
x-content-type-options: nosniff
referrer-policy: no-referrer
permissions-policy: geolocation=()
출력
시행 Content-Security-Policy 없이 Report-Only CSP만 감지했습니다. 시행 CSP와 프레임 보호를 계속 검토해야 합니다.

API 응답에서 HTML 전용 경고 제외

명시적인 JSON 응답은 비문서 콘텐츠로 분류되므로 문서 전용 CSP, 프레임, referrer, permissions 누락을 기준선 실패로 보고하지 않습니다.

입력
HTTP/2 200
content-type: application/json
strict-transport-security: max-age=31536000
x-content-type-options: nosniff
출력
비문서 응답, HSTS와 nosniff 감지, 문서 전용 권장 항목 생략, 경고 0개, 고위험 0개입니다.

보안 헤더 검토 결과를 계산하는 방식

크기가 제한된 HTTP 파서는 응답 블록을 분리하고 마지막 블록을 분석합니다. 따라서 강한 리다이렉트가 약한 최종 HTML 응답을 가리지 않으며, 요청 시작 줄은 응답처럼 채점하지 않고 거부합니다.

RFC 6797 HSTS는 보안 전송으로 받은 헤더만 처리합니다. 토큰 또는 인용된 max-age 값을 허용하고 max-age=0은 정책 제거로 판정하며, 반복 HSTS에서는 첫 필드를 사용하고 선택 사항인 preload 토큰을 필수로 요구하지 않습니다.

W3C CSP에서 Content-Security-Policy는 시행되고 Content-Security-Policy-Report-Only는 관찰만 합니다. 여러 시행 CSP 필드는 모두 적용되므로 허용하며, Report-Only의 frame-ancestors는 프레임 보호로 계산하지 않습니다.

Referrer-Policy에는 fallback 토큰을 나열할 수 있습니다. 사양 알고리즘에 따라 마지막으로 인식한 토큰이 유효하며 same-origin, no-referrer, strict-origin, strict-origin-when-cross-origin을 보수적인 결과로 분류합니다.

COOP와 COEP 값을 따로 검증하고 COOP same-origin과 COEP require-corp 또는 credentialless가 함께 있을 때만 교차 출처 격리가 완성됐다고 표시합니다. CORP는 개별 리소스 정책이지 모든 페이지의 필수 헤더로 취급하지 않습니다.

모든 처리는 브라우저 로컬에서 이루어지고 원본 Cookie나 Authorization 헤더는 생성 보고서에 포함하지 않습니다. 입력 제한으로 과도한 캡처를 막으며 이 결과는 전체 보안 감사를 대체하지 않습니다.

자주 묻는 질문

깨끗한 결과면 사이트가 안전하다는 뜻인가요?

아니요. 붙여넣은 헤더를 로컬에서 분석해 범위가 제한된 보수적 검토 힌트를 제공합니다. 침투 테스트, 취약점 스캔, 전체 보안 감사를 대체하지 않습니다.

이 도구가 내 웹사이트에 요청을 보내나요?

아니요. curl -I, 브라우저 DevTools, CDN 로그, 리버스 프록시에서 응답 헤더를 복사하세요. 도구는 URL을 요청하거나 로그인하거나 붙여넣은 내용을 원격 스캐너로 보내지 않습니다.

왜 Report-Only는 CSP 점검을 통과하지 못하나요?

Content-Security-Policy는 실제로 시행됩니다. Content-Security-Policy-Report-Only는 차단 없이 위반만 관찰하므로 Report-Only만 있으면 CSP 전환이 끝나지 않은 상태입니다.

왜 HSTS max-age=0을 고위험으로 표시하나요?

RFC 6797에 따라 HSTS는 보안 전송으로 받아야 합니다. max-age=0은 저장된 HSTS 정책을 제거하며, 긴 max-age는 영향을 받는 모든 호스트가 HTTPS로 안정적으로 서비스될 때만 적용해야 합니다.

응답 블록을 여러 개 붙이면 무엇을 검사하나요?

curl과 프록시 캡처에는 리다이렉트나 중간 응답이 자주 포함되므로 파서는 마지막 응답 블록을 사용합니다. 앞선 hop의 리다이렉트와 전송 동작도 중요하면 별도로 확인하세요.

모든 API 응답에 모든 헤더가 필요한가요?

아니요. CSP와 프레임 보호는 주로 문서 응답에 필요하고 교차 출처 격리는 애플리케이션 구조에 따라 달라집니다. 명시적인 비문서 Content-Type에서는 문서 전용 누락을 경고하지 않습니다.

CSP 헤더를 여러 번 보낼 수 있나요?

가능합니다. 반복된 시행 CSP는 각 정책이 모두 적용되어 응답을 더 제한합니다. 반면 HSTS나 X-Frame-Options 같은 단일값 성격의 헤더 반복은 검토 경고로 표시합니다.

이 도구를 검증한 방법

관리 및 검수 검토일

검증 방법: 보안 헤더 확인기로 “시행 기준선을 가진 마지막 프로덕션 HTML 응답” 샘플 입력을 정확히 재현했습니다. 결과 비교에는 “개발 서버가 아닌 배포 엣지 캡처하기”, “리다이렉트 경계를 보존하고 마지막 응답 확인하기” 단계를 포함했습니다. 이어서 연결된 테스트 근거에서 “Report-Only를 시행 CSP로 계산함”, “모든 하위 도메인 소유 없이 HSTS 옵션을 복사함” 조건을 점검했습니다.

기대 결과: 최종 문서 응답에서 보안 헤더 7개, 누락 권장 헤더 0개, 경고 0개와 강제 적용 CSP를 확인했으며, localhost나 리디렉션 응답만으로는 같은 검사를 통과하지 못했습니다.

공식 출처와 표준

검증한 작업 가이드 열기

관련 작업 가이드

도구를 열기 전에 자주 쓰는 작업 흐름과 예시를 확인하세요.

작업 가이드

배포 전에 Content-Security-Policy 헤더 분석하기

CSP가 필요한 리소스를 차단하거나 후보 정책이 과도한 보고서를 만들거나 프록시가 의도한 헤더를 바꿀 때 사용하는 절차입니다. 로컬 정책 파싱, 브라우저 위반 증거, 마지막 배포 엣지 재확인을 결합하며 정적 결과를 보안 인증으로 취급하지 않습니다.

작업 가이드

HTTP 응답 헤더 확인하기

브라우저 요청, API 응답, 리디렉션, CDN 캐시가 예상과 다를 때 설정을 먼저 바꾸지 않고 제한이 명확한 비식별 헤더 기록부터 만드는 흐름입니다.

작업 가이드

국제 도메인을 퓨니코드로 변환해 DNS 확인하기

한 곳에서는 국제 도메인이 읽기 쉬운 유니코드로, 다른 곳에서는 xn-- ASCII 라벨로 보일 때 등록 또는 보안 승인과 혼동하지 않고 정확히 비교하는 절차입니다.

작업 가이드

위험한 동작을 답습하지 않고 정적 HTML 뷰를 Pug로 옮기는 방법

HTML을 Pug로 변환하면 태그를 반복해서 다시 쓰는 수고는 줄지만, 신뢰할 수 있는 마이그레이션에는 원본 기준, 의존성 목록, 활성 코드 재설계, 명시적인 템플릿 locals, 대상 애플리케이션 테스트가 더 필요합니다. 이 절차는 하나의 완결된 뷰를 변환하고 브라우저 보정과 보존된 이벤트 및 URL을 검토하고 페이지 의존성을 옮긴 뒤, 애플리케이션에 필요한 Pug 로직만 추가하고 문법이 파싱된다는 이유가 아니라 실제 컴파일된 HTML로 결과를 검증합니다.

작업 가이드

출시 전 마지막 응답 보안 헤더 점검하기

curl -I 또는 DevTools 캡처를 반복 가능한 출시 증거로 바꾸는 절차입니다. 마지막 응답을 로컬에서 검사하고 시행 CSP와 Report-Only 관찰을 구분하며, 배포 문맥을 기록한 뒤 헤더만으로 확인할 수 없는 애플리케이션 테스트까지 이어갑니다.

관련 도구

관리 중인 다른 작업 흐름을 이어서 사용해 보세요

CSP 헤더 분석기 | Content Security Policy 검토

CSP 정책, 첫 유효 directive, source expression과 시행 문맥을 로컬에서 검토합니다.

보안

요청·응답 디버깅용 HTTP 헤더 파서

HTTP 헤더 블록을 로컬에서 분석하고 민감값 마스킹과 프로토콜 진단을 제공합니다.

인코딩

IDN 변환기: 유니코드와 퓨니코드 도메인 변환

IDN 하나를 엄격하게 검증하며 유니코드와 퓨니코드 사이에서 변환합니다.

인코딩

JWT 디코더: 클레임과 만료 시간 확인

서명을 검증하지 않고 JWT 구조와 시간 클레임을 엄격하게 로컬 디코딩합니다.

보안

URL 파서 및 분석기 | Query Parameter와 상대 URL

절대 URL 또는 상대 참조를 파싱해 raw, decoded, 정규화, 중복 query 보기를 제공합니다.

변환
모든 도구 둘러보기