해킹 없이 할 수 있는 웹사이트 보안 점검 가이드

온라인 쇼핑몰을 위한 패시브 보안 점검: TLS 인증서 만료, HSTS, CSP, nosniff, 쿠키 속성, 혼합 콘텐츠, 오래된 jQuery, security.txt, DMARC.

FixReports 편집팀9분 분량

온라인 쇼핑몰의 보안 설정 상당 부분은 사이트가 이미 모든 방문자에게 보내는 정보를 읽는 것만으로 외부에서 점검할 수 있습니다. TLS 인증서, 리디렉션, HTTP 응답 헤더, 쿠키, 페이지가 불러오는 스크립트, 공개 DNS 레코드가 그 대상입니다. 이러한 패시브(수동적) 점검은 공격 트래픽을 보내지 않고 로그인도 필요 없으므로, 쇼핑몰에 일반적인 방문 이상의 부하를 주지 않습니다. 만료가 임박한 인증서, 누락된 HSTS, 안전하지 않은 쿠키, 혼합 콘텐츠, 알려진 결함이 있는 jQuery 버전 같은 설정상의 허점을 찾아냅니다. 다만 침투 테스트(모의 해킹)가 아니므로 쇼핑몰이 안전하다는 것을 증명할 수는 없습니다.

핵심 요약

  • 2026년 3월 15일 이후 발급된 공개 신뢰 TLS 인증서의 유효 기간은 최대 200일이며, 2027년 3월에는 100일, 2029년 3월에는 47일로 줄어듭니다 (CA/Browser Forum (새 탭에서 열림)).
  • 브라우저는 일반 HTTP로 전송된 HSTS 헤더를 무시합니다 (MDN (새 탭에서 열림)).
  • CSP의 frame-ancestors 지시어는 <meta> 태그에서는 작동하지 않으며, 반드시 응답 헤더로 보내야 합니다 (MDN (새 탭에서 열림)).
  • 3.5.0 이전의 jQuery 버전은 두 가지 XSS 취약점의 영향을 받으며, 미국 CISA는 그중 하나인 CVE-2020-11023을 2025년 1월 23일 알려진 악용 취약점(KEV) 목록에 추가했습니다 (NVD (새 탭에서 열림)).
  • security.txt 파일에는 Contact와 Expires 필드가 있어야 하며, 파일은 /.well-known/security.txt에 있어야 합니다 (RFC 9116 (새 탭에서 열림)).

패시브 보안 점검이란 무엇인가요?

패시브 점검은 사이트나 DNS가 일반적인 요청에 반환하는 내용만 읽습니다.

즉 공개 페이지를 불러오고, 인증서와 응답 헤더를 읽고, 페이지가 설정하는 쿠키와 불러오는 스크립트를 나열하고, 공개 DNS 레코드를 조회하는 것입니다. 패시브 점검은 비밀번호를 추측하거나, 인젝션 페이로드를 보내거나, 관리자 URL을 탐색하거나, 포트를 스캔하지 않습니다. 아래의 모든 점검은 브라우저, curl, openssl, dig만으로 수행할 수 있습니다.

TLS 인증서와 만료일은 어떻게 확인하나요?

인증서의 날짜와 도메인 이름을 직접 확인하고, 갱신이 자동화되어 있는지 확인합니다.

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

notAfter가 충분히 먼 미래인지, example.com과 www.example.com을 모두 사용한다면 인증서가 두 도메인을 모두 포함하는지(브라우저의 인증서 뷰어에서 이름 목록을 볼 수 있습니다), 브라우저에 경고가 표시되지 않는지 확인합니다. 2025년 4월 11일 채택된 Ballot SC-081v3 (새 탭에서 열림)에 따라 CA/Browser Forum Baseline Requirements(6.3.2절, 2026년 10월 기준 버전 2.3.1)에서 인증서 유효 기간이 단계적으로 짧아지고 있습니다.

인증서 발급 시점최대 유효 기간
2026년 3월 15일 이전398일
2026년 3월 15일부터 2027년 3월 14일까지200일
2027년 3월 15일부터 2029년 3월 14일까지100일
2029년 3월 15일부터47일

유효 기간이 짧으면 수동 갱신은 위험하므로, 호스팅 업체나 인증서 도구가 자동으로 갱신하는지 확인해야 합니다. 또한 일반 HTTP 요청이 HTTPS로 리디렉션되는지도 확인합니다.

curl -sI http://example.com/ | grep -i -E "^HTTP|^location"

location 헤더가 https://로 시작하는 301(또는 308) 응답이 나와야 합니다.

온라인 쇼핑몰은 어떤 보안 헤더를 보내야 하나요?

몇 가지 응답 헤더만으로 흔한 브라우저 측 공격을 거의 비용 없이 막을 수 있습니다.

헤더역할일반적인 값출처
Strict-Transport-Security브라우저가 HTTPS만 사용하도록 지시하고, 사용자가 인증서 오류를 무시하고 접속하지 못하게 함max-age=31536000; includeSubDomainsMDN (새 탭에서 열림)
Content-Security-Policy: frame-ancestors어떤 사이트가 내 페이지를 삽입(embed)할 수 있는지 제어해 클릭재킹을 방어함frame-ancestors 'self'MDN (새 탭에서 열림)
X-Frame-Options예전 방식의 프레임 제어. OWASP에 따르면 이를 지원하는 브라우저에서는 frame-ancestors로 대체됨DENY 또는 SAMEORIGINOWASP (새 탭에서 열림)
X-Content-Type-OptionsMIME 스니핑을 막고, 잘못된 유형으로 제공된 스크립트와 스타일시트를 차단함nosniffMDN (새 탭에서 열림)
Referrer-Policy다른 사이트로 전송되는 URL 정보의 범위를 제한함strict-origin-when-cross-originOWASP
X-XSS-Protection브라우저 XSS 필터 헤더. OWASP에 따르면 원래 안전한 사이트에 오히려 XSS 취약점을 만들 수 있음설정하지 않거나 0OWASP

쇼핑몰이 어떤 헤더를 보내는지 확인합니다.

curl -sI https://example.com/

Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Security-Policy: frame-ancestors 'self'
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin

주의할 점이 두 가지 있습니다. includeSubDomains는 HTTP로만 작동하는 하위 도메인을 모두 차단하므로 먼저 하위 도메인을 확인해야 합니다. HSTS 프리로드에는 31536000 이상의 max-age와 includeSubDomains가 필요하므로, 모든 하위 도메인이 HTTPS를 사용할 준비가 되었을 때만 preload를 추가합니다. 스크립트를 제한하는 완전한 CSP는 갖출 가치가 있지만, OWASP는 CSP의 구성과 유지 관리가 복잡하다고 지적하므로 앱이 많은 쇼핑몰은 신중하게 테스트해야 합니다.

쿠키에 Secure, HttpOnly, SameSite가 설정되어 있나요?

세션 쿠키와 장바구니 쿠키에는 세 가지 속성이 모두 있어야 하며, Set-Cookie 응답 헤더에서 확인할 수 있습니다.

속성효과(MDN (새 탭에서 열림) 기준)적용해야 할 곳
SecureHTTPS로만 전송되며, 일반 HTTP 사이트는 이 속성을 설정할 수 없음HTTPS 쇼핑몰의 모든 쿠키
HttpOnlyJavaScript가 document.cookie로 읽을 수 없어 XSS 방어에 도움이 됨로그인 세션과 장바구니
SameSite=Lax 또는 Strict교차 사이트 요청에서 쿠키가 전송되는 경우를 제한함세션. Strict는 인증 쿠키와 장바구니 쿠키에 적합
SameSite=None교차 사이트 요청에도 전송되며, 반드시 Secure와 함께 사용해야 함이 설정이 꼭 필요한 삽입형 서드파티 기능에만

SameSite 속성이 설정되지 않으면 브라우저는 해당 쿠키를 Lax로 취급합니다. 자체 스크립트가 읽어야 하는 쿠키는 HttpOnly로 설정할 수 없으므로, 로그인한 고객이나 관리자를 식별하는 쿠키에 집중합니다.

curl -sI https://example.com/ | grep -i "^set-cookie"

브라우저 개발자 도구에서도 같은 정보를 볼 수 있으며, 페이지가 로드된 뒤 스크립트가 설정한 쿠키까지 확인할 수 있습니다.

혼합 콘텐츠는 어떻게 찾나요?

혼합 콘텐츠(mixed content)는 HTTPS로 제공되는 페이지에서 HTTP로 불러오는 리소스를 말하며, 브라우저 콘솔에 표시됩니다.

MDN (새 탭에서 열림)은 이를 두 그룹으로 나눕니다. 이미지, 오디오, 동영상은 “업그레이드 가능(upgradable)” 콘텐츠로, 브라우저가 자동으로 HTTPS로 요청합니다. 스크립트, 스타일시트, iframe, 글꼴, fetch() 요청은 “차단 가능(blockable)” 콘텐츠로, 브라우저가 이를 차단하므로 여기에 의존하던 기능이 작동하지 않게 됩니다. 도메인 없이 IP 주소만으로 된 주소에 대한 업그레이드 요청도 차단됩니다.

혼합 콘텐츠를 찾으려면 주요 템플릿(홈, 컬렉션, 상품, 장바구니)에서 콘솔을 열고, 테마 코드, 페이지 콘텐츠, 앱 설정에서 http://를 검색합니다. Shopify 도움말 센터에 따르면 HTTPS로 전달되지 않는 에셋이 하나라도 있는 쇼핑몰 페이지는 안전하지 않은 것으로 간주되며 (새 탭에서 열림), 에셋을 Shopify에 호스팅하거나 HTTPS로 제공할 것을 권장합니다. WooCommerce에서는 사이트가 한때 http://로 운영된 적이 있다면 예전 게시물 콘텐츠와 테마 옵션을 확인합니다.

알려진 CVE가 있는 오래된 JavaScript 라이브러리는 어떻게 찾나요?

각 페이지가 불러오는 라이브러리를 나열하고 버전을 확인한 다음, 미국 국가 취약점 데이터베이스(NVD)와 비교합니다.

jQuery부터 시작합니다. 브라우저 콘솔에서 $.fn.jquery를 실행하면 로드된 버전이 반환됩니다 (jQuery API (새 탭에서 열림)). 주의해야 할 버전은 다음과 같습니다.

CVE영향받는 버전문제NVD 점수(v3.1)
CVE-2020-11022 (새 탭에서 열림)1.12.0 이상 3.5.0 미만신뢰할 수 없는 HTML을 .html()이나 .append() 같은 메서드에 전달하면 코드가 실행될 수 있음6.1 중간(Medium)
CVE-2020-11023 (새 탭에서 열림)1.0.3 이상 3.5.0 미만같은 문제로, <option> 요소가 포함된 HTML에 해당. 2025년 1월 23일부터 CISA KEV 목록에 등재6.1 중간(Medium)
CVE-2019-11358 (새 탭에서 열림)3.4.0 미만jQuery.extend(true, ...)를 통한 프로토타입 오염6.1 중간(Medium)

2020년의 두 문제는 모두 jQuery 3.5.0에서 수정되었습니다. 취약한 버전이 있다는 것은 결함이 있는 코드가 존재한다는 뜻이며, 실제로 악용될 수 있는지는 사이트가 그 코드에 데이터를 어떻게 전달하는지에 달려 있습니다. WordPress는 버전 5.6부터 (새 탭에서 열림) jQuery 3.5.1을 기본 포함하고 있으므로, WooCommerce 쇼핑몰에 오래된 jQuery가 있다면 WordPress 자체가 오래되었거나 테마나 플러그인이 자체 사본을 불러오고 있다는 신호입니다. Shopify에서는 테마 파일과 스크립트를 삽입하는 앱을 확인합니다.

security.txt란 무엇이며, 쇼핑몰에 필요한가요?

보안 연구자에게 취약점을 신고하는 방법을 알려 주는 일반 텍스트 파일입니다.

RFC 9116 (새 탭에서 열림)(2022년 4월, 정보성(Informational) RFC이므로 준수 여부는 자율입니다)에 따르면 이 파일은 HTTPS를 통해 /.well-known/security.txt 경로에서 text/plain으로 제공되어야 합니다. Contact와 Expires는 필수이며, RFC는 Expires 날짜를 1년 이내로 설정할 것을 권장합니다.

Contact: mailto:security@example.com
Expires: 2027-09-30T23:00:00.000Z
Preferred-Languages: en
Policy: https://example.com/security-policy

WooCommerce에서는 서버에 파일을 올리면 됩니다. 호스팅형 플랫폼에서는 해당 경로에 파일을 게시할 수 있는지 확인하고, 불가능하다면 문의 페이지에 보안 연락처를 명확히 표시하는 것만으로도 도움이 됩니다.

DMARC는 이메일 스푸핑으로부터 쇼핑몰을 어떻게 보호하나요?

DMARC를 사용하면 정렬된 SPF나 DKIM을 통과하지 못한 채 From 주소에 쇼핑몰 도메인을 사용하는 메일을 격리하거나 거부하도록 메일 서비스 제공업체에 요청할 수 있습니다.

p=none 레코드는 보고서만 수집할 뿐, 위조 메일을 막지는 않습니다. 고객은 주문 확인 메일과 비밀번호 재설정 메일이 쇼핑몰 도메인에서 오기를 기대하므로, 쇼핑몰 도메인을 그대로 표시하는 피싱 메일은 차단할 가치가 있습니다. dig +short TXT _dmarc.example.com으로 정책을 확인하고, 사양은 RFC 9989 (새 탭에서 열림)를 참고합니다. DMARC는 레코드를 게시한 도메인만 보호하며, 비슷하게 생긴 유사 도메인은 다루지 않습니다.

Shopify는 무엇을 관리하고, WooCommerce에서는 무엇을 직접 관리하나요?

Shopify는 스토어프런트를 운영하는 서버를 직접 관리하지만, 자체 호스팅 WooCommerce 쇼핑몰은 서버 설정을 운영자와 호스팅 업체에 맡깁니다.

점검 항목ShopifyWooCommerce(자체 호스팅)
TLS 인증서Shopify에 추가된 모든 도메인에 무료 제공 (새 탭에서 열림). 타사 도메인은 최대 48시간이 걸릴 수 있음호스팅 업체 또는 직접 구성
HTTP에서 HTTPS로 리디렉션플랫폼웹 서버, CDN 또는 호스팅 설정
보안 헤더Shopify 서버가 전송웹 서버, CDN 또는 플러그인
쿠키 속성Shopify 자체 쿠키는 플랫폼이 설정하며, 앱과 테마 쿠키는 운영자 책임WordPress 코어, 플러그인, 서버
혼합 콘텐츠와 JS 라이브러리테마, 콘텐츠, 앱테마, 콘텐츠, 플러그인
security.txt와 DMARC운영자의 도메인과 DNS운영자의 도메인과 DNS

2026년 10월에 Shopify에서 호스팅되는 여러 스토어프런트를 확인한 결과, 응답에는 약 91일의 max-age를 가진 HSTS, X-Content-Type-Options: nosniff, upgrade-insecure-requests가 포함된 CSP가 있었으며, frame-ancestors는 쇼핑몰마다 달랐습니다. Shopify는 PCI DSS Level 1 준수 인증을 받았다 (새 탭에서 열림)고 밝히고 있습니다. 다만 테마와 설치한 앱은 여전히 운영자의 책임입니다.

WooCommerce의 경우 WordPress의 보안 강화 가이드 (새 탭에서 열림)는 WordPress와 플러그인을 최신 상태로 유지하고, 사용하지 않는 플러그인을 삭제하고, 호스팅 업체에 어떤 보안 조치를 취하고 있는지 문의할 것을 권합니다.

왜 이것이 침투 테스트가 아닌가요?

침투 테스트는 실제로 공격을 시도하지만, 패시브 점검은 관찰만 합니다.

NIST SP 800-115는 침투 테스트를 평가자가 실제 공격을 모방해 시스템의 보안 기능을 우회하는 방법을 찾는 보안 테스트로 정의합니다 (NIST 용어집 (새 탭에서 열림)). 패시브 점검으로는 플러그인의 서버 측 결함, 약하거나 재사용된 관리자 비밀번호, 2단계 인증 미설정, 접근 제어 결함, 페이지 소스에 드러나지 않는 취약한 코드를 확인할 수 없습니다. 패시브 점검은 언제든 반복할 수 있는 기준선으로 활용하는 것이 좋습니다. 더 깊은 수준의 보증이 필요하다면 소유하고 있거나 테스트 권한을 받은 시스템을 대상으로, 범위를 문서로 정한 침투 테스트를 의뢰해야 합니다.

무료 스캔으로 쇼핑몰을 1차 점검할 수 있습니다. 웹사이트 보안 리포트는 TLS와 리디렉션부터 헤더, 쿠키, 혼합 콘텐츠, 오래된 라이브러리, security.txt, DMARC까지 이 글에서 다룬 패시브 점검을 수행하고, 발견 항목마다 수정 방법을 제공합니다. 다른 모든 패시브 검토와 마찬가지로, 쇼핑몰이 안전하다고 보장할 수는 없습니다.

자주 묻는 질문

패시브 보안 점검이 쇼핑몰에 위험을 주나요?

일반적인 방문 이상의 위험은 없습니다. 브라우저나 메일 서버가 요청하는 것과 같은 공개 페이지와 DNS 레코드를 요청할 뿐이며, 로그인을 시도하거나 공격 페이로드를 보내지 않습니다.

Shopify에서 보안 헤더를 추가할 수 있나요?

스토어프런트의 응답 헤더는 Shopify 서버에서 전송되므로, 필요한 헤더가 없다면 Shopify 고객 지원팀에 문의해야 합니다. 테마에 CSP <meta> 태그를 넣어 일부 지시어를 추가할 수는 있지만, MDN에 따르면 frame-ancestors는 <meta>에서 지원되지 않습니다.

오래된 jQuery 버전이 있으면 쇼핑몰이 해킹당했다는 뜻인가요?

아니요. 알려진 취약점이 있는 코드가 로드되고 있다는 뜻이며, 사이트가 영향받는 메서드에 신뢰할 수 없는 HTML을 전달한다면 위험이 커집니다. jQuery를 업데이트하거나, 이를 불러오는 테마나 플러그인을 제거해야 합니다.

현재 TLS 인증서의 유효 기간은 최대 얼마인가요?

2026년 3월 15일부터 발급되는 공개 신뢰 인증서의 유효 기간은 최대 200일입니다. 이 한도는 2027년 3월 15일부터 100일, 2029년 3월 15일부터 47일로 줄어듭니다.

security.txt 파일은 필수인가요?

RFC 9116은 정보성(Informational) RFC이므로, 표준상 이 파일의 게시는 자율 사항입니다. 게시하는 데 비용이 거의 들지 않고, 보안 연구자에게 명확한 연락 경로를 제공합니다.

패시브 스캔에서 문제가 없으면 쇼핑몰이 안전하다는 뜻인가요?

아니요. 공개된 설정이 올바르게 보인다는 뜻일 뿐입니다. 서버 측 취약점, 계정 보안, 비즈니스 로직 결함은 별도의 테스트가 필요합니다.

출처

전체 가이드