점검 항목 25가지
무엇이고 왜 문제인가

주소창에 http:// 로 들어가도 사이트가 그대로 열린다면, 그 요청은 암호화되지 않은 채 공유기와 통신사 장비를 지나갑니다. 로그인 폼 하나만 있어도 아이디와 비밀번호가 평문으로 흘러갑니다. 인증서를 달아 두고 http 를 https 로 넘기는 설정만 빠뜨린 경우가 의외로 많은데, 이러면 인증서 값은 다 내고 효과는 절반입니다.

TLS 1.0 과 1.1 은 2020~2021년에 주요 브라우저에서 전부 폐기됐습니다. 서버가 아직 이 버전으로 연결을 받아 준다면 공격자가 낮은 버전으로 끌어내리는 여지가 남고, 공공 · 금융 보안성 검토에서는 그 자체로 지적 항목이 됩니다. 원인은 대개 몇 년 전에 적힌 설정 파일 한 줄인데, 아무도 다시 들여다보지 않아서 그대로 남아 있습니다.

인증서는 만료되는 날 예고 없이 사이트를 통째로 막습니다. 브라우저가 빨간 경고 화면을 띄우고 방문자 대부분은 거기서 돌아갑니다. 90일마다 자동 갱신되는 무료 인증서를 쓴다면, 그 자동 갱신이 조용히 멈춰 있었다는 사실을 만료 당일에 알게 되는 일이 가장 흔한 사고입니다.

인증서에 적힌 이름이 지금 주소와 다르면, 인증서가 설치되어 있어도 없는 것과 같습니다. www 를 붙인 주소와 안 붙인 주소 중 한쪽만 넣은 경우가 가장 흔하고, 공유 호스팅에서는 우리 도메인용 설정이 빠져 아예 남의 인증서가 나가기도 합니다. 사람은 경고를 한 번 누르고 들어올 수 있지만 기계는 그렇지 않습니다 — 검색엔진 크롤러와 AI 답변엔진은 이름이 맞지 않으면 연결 자체를 끊습니다. 그 사이트는 색인에도, 답변에도 등장하지 않습니다. 만료와는 고치는 방법도 다릅니다. 만료는 갱신이지만 이것은 재발급이고, 재발급할 때 도메인 목록에 www 를 붙인 주소와 안 붙인 주소를 둘 다 넣어야 합니다.

CSP 는 "이 페이지는 어디서 온 스크립트만 실행한다"를 브라우저에 미리 알려 두는 헤더입니다. 없으면 게시판 글이나 댓글에 스크립트가 한 줄 끼어들었을 때 브라우저가 그것을 그대로 실행합니다. XSS 를 막는 마지막 그물이고, OWASP 2025 판에서 보안 설정 오류가 2위까지 올라온 배경이기도 합니다. 다만 처음부터 강제하면 멀쩡하던 기능이 조용히 죽으므로, 위반만 수집하는 Report-Only 로 며칠 관찰한 뒤 켜는 것이 순서입니다.

https 로 넘기는 리다이렉트를 걸어 두어도 첫 요청 한 번은 http 로 나갑니다. 그 한 번을 가로채는 것이 SSL 스트립 공격이고, HSTS 는 "이 도메인은 앞으로 https 로만 접속하라"를 브라우저에 기억시켜 그 틈을 없앱니다. 한 번 선언하면 지정한 기간 동안 되돌리기가 까다로우니, 모든 하위 경로가 https 에서 정상인지 확인하고 짧은 기간부터 올립니다.

공격자가 자기 페이지에 우리 사이트를 투명한 iframe 으로 얹고 그 위에 가짜 버튼을 겹칩니다. 방문자는 자기가 무엇을 누르는지 모른 채, 로그인된 상태로 우리 사이트에서 어떤 동작을 실행하게 됩니다. 이것이 클릭재킹입니다. X-Frame-Options 한 줄이면 막히고, 요즘은 CSP 의 frame-ancestors 로 어느 도메인까지 허용할지 더 정밀하게 정합니다.

브라우저는 서버가 알려준 파일 형식이 미덥지 않으면 내용을 들여다보고 스스로 판단합니다. 이 추측이 업로드된 이미지 파일을 스크립트로 해석해 실행해 버리는 사고로 이어집니다. nosniff 는 그 추측 자체를 금지합니다. 파일 업로드를 받는 사이트에서 특히 중요하고, 부작용이 사실상 없어서 보안 헤더 중 가장 먼저 켤 만한 항목입니다.

링크를 눌러 외부 사이트로 나갈 때 브라우저는 방금 보던 주소를 상대 서버에 함께 알려 줍니다. 기본 동작이면 전체 경로와 물음표 뒤 값까지 넘어가서, 비밀번호 재설정 링크나 주문번호가 들어 있던 주소가 남의 접속 로그에 남습니다. 도메인까지만 전달하도록 정해 두면 유입 분석은 그대로 되면서 이 유출만 사라집니다. 위험도는 낮지만 분류상 개인정보 노출입니다.

세션 쿠키에 HttpOnly 가 없으면 자바스크립트로 읽힙니다. XSS 한 번에 계정이 그대로 넘어간다는 뜻입니다. Secure 가 없으면 http 요청에도 쿠키가 실려 나가고, SameSite 가 없으면 다른 사이트가 우리 쪽으로 보내는 요청에도 쿠키가 따라붙습니다(CSRF). 세 속성은 각각 다른 사고를 막기 때문에, 하나가 빠지면 정확히 그 구멍만 열려 있습니다.

응답 헤더에 서버와 언어의 정확한 버전이 찍혀 있으면, 공격자는 그 버전에 알려진 취약점 목록을 그대로 대조합니다. 버전을 감춘다고 취약점이 없어지지는 않지만, 버전으로 대상을 골라내는 자동화 스캐너의 표적 목록에서 빠지는 효과는 실제로 있습니다. 설정 한 줄이라 남겨 둘 이유가 없는 항목입니다.

TTFB 는 브라우저가 요청을 보내고 첫 바이트를 받기까지의 시간입니다. 이 구간이 길면 이미지를 아무리 줄여도 체감 속도가 좋아지지 않습니다. 화면이 그려지기 시작하는 시점 자체가 뒤로 밀리기 때문입니다. 원인은 대개 느린 쿼리, 외부 API 응답 대기, 캐시 없음 셋 중 하나이고 프런트엔드 최적화로는 손댈 수 없는 자리입니다.

첫 화면을 그리는 데 필요한 전송량이 몇 MB 를 넘어가면, 이동 중 접속에서는 그것만으로 몇 초가 사라집니다. 대개 원본 그대로 올린 사진 몇 장이 전체의 대부분을 차지합니다. 사진을 최신 포맷으로 바꾸고 실제 표시되는 크기로 줄이는 것만으로 절반 이하가 되는 경우가 많고, 이 작업은 디자인을 한 픽셀도 건드리지 않습니다.

HTML · CSS · 자바스크립트는 결국 텍스트라서 압축하면 보통 4분의 1 이하로 줄어듭니다. 서버 설정 몇 줄이면 되고 코드는 한 줄도 고치지 않습니다. 그런데 실제로 재 보면 압축이 아예 꺼져 있는 사이트가 흔합니다. 저희도 오픈 전 자체 점검에서 이 항목에 걸려, 80KB 짜리 CSS 를 그대로 내보내고 있던 것을 그때 고쳤습니다.

로고 · CSS · 폰트처럼 몇 달 동안 바뀌지 않는 파일에 캐시 지시가 없으면, 방문자가 페이지를 옮길 때마다 같은 파일을 다시 내려받습니다. 재방문자의 체감 속도가 첫 방문과 똑같아지고 서버 트래픽도 그만큼 낭비됩니다. 파일 이름에 버전을 붙여 두면 캐시 기간을 길게 잡아도 배포한 순간 새 파일이 적용됩니다.

문서 머리에 놓인 CSS 와 자바스크립트는 다 받아 오기 전까지 브라우저가 화면을 그리지 않습니다. 이런 파일이 여러 개이고 외부 도메인에서 온다면, 그 대기 시간이 그대로 흰 화면입니다. 당장 필요하지 않은 스크립트를 나중에 실행되도록 미루고 웹폰트 로딩 방식을 바꾸는 것만으로 첫 화면이 눈에 띄게 빨라집니다.