"기능은 다 되는데 왜 취약할까"
AI 코딩 도구로 만든 서비스는 화면도 예쁘고 기능도 잘 돕니다. 그런데 정작 브라우저로 내려가는 HTTP 응답 헤더는 기본값 그대로 두는 경우가 대부분입니다. 눈에 보이는 버튼과 폼은 완성했지만, 눈에 안 보이는 헤더 한 줄이 빠져 있으면 클릭재킹, XSS, 중간자(MITM) 공격에 그대로 문이 열립니다.
문제는 이 누락이 외부에서 접속만 해도 그대로 드러난다는 점입니다. 공격자는 서버에 접속해 응답 헤더부터 훑습니다. 헤더가 비어 있으면 "여기는 방어 설정이 안 된 곳"이라는 신호로 읽고 정찰 1순위에 올립니다.
왜 중요한가 — 코드를 안 고치고도 세우는 방어선
보안 헤더의 강점은 애플리케이션 코드 로직을 수정하지 않고 서버/프레임워크 설정만으로 적용된다는 데 있습니다. 브라우저에게 "이건 막아라"라고 지시하는 마지막 방어선입니다. 헤더 하나로 막을 수 있는 공격을 방치하면, 정상 기능이 그대로 공격 표면이 됩니다.
꼭 필요한 웹 보안 헤더 7가지
- Content-Security-Policy(CSP): 로드 가능한 스크립트·리소스 출처를 화이트리스트로 제한 → XSS·데이터 인젝션의 영향을 완화.
frame-ancestors지시어로 iframe 삽입까지 통제. - Strict-Transport-Security(HSTS): 브라우저가 이후 접속을 HTTPS로만 강제 → 프로토콜 다운그레이드·중간자(MITM) 위험 감소.
- X-Frame-Options(또는 CSP frame-ancestors): 페이지의 iframe 삽입 제한 → 클릭재킹 방어.
- X-Content-Type-Options: nosniff: 브라우저 MIME 스니핑 차단 → 콘텐츠 오해석으로 인한 스크립트 실행 방지.
- Referrer-Policy: 리퍼러를 통한 내부 URL·토큰 유출 통제(
no-referrer계열 권장). - Permissions-Policy: 카메라·마이크·위치 등 브라우저 기능 권한을 최소화.
- Set-Cookie 보안 속성: 세션 쿠키에
HttpOnly(스크립트 접근 차단)·Secure(HTTPS 전송 강제)·SameSite(크로스사이트 전송 제한)로 탈취/오용 위험 감소.
자가점검 체크리스트
- ☐ HTTPS로 접속했을 때 응답 헤더에 HSTS가 있는가
- ☐ CSP가 설정돼 있고
unsafe-inline을 남발하지 않는가 - ☐ X-Frame-Options 또는
frame-ancestors로 iframe이 막혀 있는가 - ☐ X-Content-Type-Options: nosniff가 있는가
- ☐ Referrer-Policy가
no-referrer계열인가 - ☐ 세션 쿠키에 HttpOnly·Secure·SameSite가 붙어 있는가
- ☐ Server / X-Powered-By로 프레임워크·버전이 노출되지 않는가
수동 확인은 되지만, 판단이 애매합니다
위 7가지는 브라우저 개발자도구(F12)의 Network 탭에서 응답 헤더를 열어 하나씩 확인할 수 있습니다. 다만 항목이 많고, "CSP가 있긴 한데 이게 제대로 된 설정인가"처럼 판단이 애매한 지점이 많습니다.
보안 전문 기업 SENTRIX의 CodeScan은 접속 한 번으로 누락된 보안 헤더를 자동 검출하고 등급화해, 약 30초 만에 리포트로 보여줍니다. F12로 일일이 뒤질 필요 없이 어떤 헤더가 빠졌는지, 어디가 위험한지 한눈에 확인할 수 있습니다.
지금 점검하세요
내 사이트에 어떤 보안 헤더가 빠졌는지, 지금 30초 무료로 점검하세요 → codescan.kr. 무료 스캔으로 누락 항목을 먼저 확인하고, 항목별 조치 방법이 담긴 상세 리포트가 필요하면 유료 리포트로 이어서 받아보실 수 있습니다.