홈페이지 발주 담당자도 알아 두면 좋은 점 ── IPA 「안전한 웹사이트 만드는 법」을 체크리스트로 활용하기

「우리 홈페이지, 보안은 괜찮은가요?」라는 질문을 받고, 근거를 갖고 「괜찮습니다」라고 답할 수 있는 회사는 많지 않습니다.

제작 회사에 맡겼으니 괜찮다, 회사 소개만 있는 사이트라서 노리지 않을 것이라는 생각이 퍼져 있습니다. 그러나 문의 폼이 하나라도 있으면 입력값을 처리하는 프로그램이 동작하고, WordPress 같은 CMS를 쓰고 있다면 관리 화면과 플러그인도 공격 대상입니다. 게다가 공격 대부분은 특정 회사를 겨냥하지 않습니다. 약한 사이트를 기계적으로 찾아 이뤄집니다.

그렇다면 「괜찮다」를 무엇으로 확인하면 될까요. 그 기준으로 오래 쓰여 온 공적 자료가 IPA(독립행정법인 정보처리추진기구)의 안전한 웹사이트 만드는 법입니다.

이 글에서는 이 자료가 무엇을 알려 주는지를, 웹사이트를 발주하는 쪽과 운영하는 쪽도 알아들을 수 있는 말로 정리합니다.

1. 먼저 결론

• 「안전한 웹사이트 만드는 법」은 IPA에 실제로 신고된 취약점을 바탕으로, 웹사이트의 약점 11가지와 대책을 정리한 자료. 개발자뿐 아니라 발주·검수 기준으로도 쓸 수 있음
• 대책은 「근본적 해결」(원인을 없앰)과 「보험적 대책」(피해를 줄임)으로 나뉨. 기본은 근본적 해결이며, 보험적 대책은 그 위에 더하는 것
• 부속 「보안 구현 체크리스트」는 제작 회사에 발주할 때·검수할 때의 확인 항목으로 그대로 쓸 수 있음
• 별책 「웹 건강진단 사양」은 운영 중인 사이트를 정기 점검할 때 진단 항목의 기준이 됨
• 회사 사이트 실무에서는 폼처럼 입력을 받는 부분과 CMS(WordPress 등) 운영이 두 가지 큰 위험. 「만들고 끝」이 아닌 운영 체계까지 포함해 발주 시점에 정해 둘 것

그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 23건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle

2. 「안전한 웹사이트 만드는 법」이란

「안전한 웹사이트 만드는 법」은 IPA가 접수한 취약점 관련 정보 가운데, 신고 건수가 많았던 취약점이나 공격받았을 때 영향이 큰 취약점을 골라, 웹사이트 개발자와 운영자를 위해 대책을 정리한 자료입니다. 현재 공개된 최신판은 개정 제7판이며, 전체 115페이지입니다. 배포 중인 PDF는 2021년 3월 31일에 제4쇄로 갱신된 것입니다. PDF 외에 취약점별 HTML 페이지도 공개되어 있습니다.

구성은 3개 장입니다.

본편과 별도로 다음 자료도 공개되어 있습니다.

• 보안 구현 체크리스트(Excel 형식): 본편의 대책을 구현했는지 확인하는 일람표
• 별책 「안전한 SQL 호출 방법」: 데이터베이스 쪽 취약점 대책을 깊게 다룬 자료
• 별책 「웹 건강진단 사양」: 가동 중인 사이트를 진단하기 위한 진단 항목 13가지를 정리한 사양

모두 IPA 페이지에서 무료로 내려받을 수 있습니다.

2.1. 자료의 시의성을 어떻게 볼 것인가

이 자료를 기준으로 쓰기 전에 짚어 둘 전제가 있습니다. 개정 제7판이 공개된 때는 2015년 3월이며, 그 뒤에는 증쇄할 때마다 수정이 들어가, 지금 배포되는 PDF는 2021년 3월 31일 갱신의 제7판 제4쇄입니다. 이 글을 쓰는 시점(2026년 7월)에 제8판은 공개되어 있지 않습니다.

그래도 기준으로 쓸 수 있는 이유는, 이 자료가 다루는 대상이 웹 애플리케이션을 만드는 방식 자체에서 비롯되는 약점이기 때문입니다. 입력값을 SQL문이나 HTML에 넣고, 세션으로 본인을 식별하고, 폼 입력으로 메일을 보내는 구조는 지금도 같습니다. 11가지 취약점과 「근본적 해결/보험적 대책」이라는 생각은 지금도 구현 확인 기준으로 통합니다.

반대로 말하면, 근래의 위협 동향은 이 자료로 커버할 수 없습니다. 랜섬 공격, 거래처나 위탁처를 통한 침입, 생성형 AI 이용에 따른 위험 같은 주제는 원래 이 자료의 범위가 아닙니다. 그 부분은 매년 갱신되는 자료로 보완하게 됩니다.

세 가지를 따로따로 읽을 필요는 없습니다. 「구현 기준은 이 자료, 위협의 최신 동향은 10대 위협, 회사 체제는 가이드라인」으로 역할을 나누고, 필요해진 곳만 보면 충분합니다. 10대 위협 2026년판의 내용은 정보보안 10대 위협 2026 해설 글에서, 가이드라인 제4.0판은 가이드라인 제4.0판 해설 글에서 다룹니다.

3. 11가지 취약점을 「무슨 일이 일어나는가」로 읽기

제1장이 다루는 11가지 취약점은 개발자용 용어로 늘어서 있습니다. 다만 「방치하면 자사 사이트에서 무슨 일이 일어나는가」로 바꿔 읽으면, 발주 담당자에게도 남의 일이 아니라는 점이 드러납니다.

맨 오른쪽 열은 회사 사이트에서 이 취약점이 문제가 되기 쉬운 위치의 예입니다. 자사 사이트에 같은 기능이 있는지로, 어느 행이 자기 일인지 가릴 수 있습니다.

예를 들어 「메일 헤더 인젝션」은 회사 소개 사이트의 문의 폼이 그대로 해당합니다. 대책이 허술한 폼은 스팸 메일 발신 출처로 악용되고, 회사 도메인의 신뢰(메일이 상대에게 도착하는지)까지 훼손합니다. 폼에서 보낸 메일이 도착하지 않는 문제는 문의 폼 메일이 도착하지 않는 원인에서 다룬 대로, 비즈니스 기회 손실로 직결됩니다.

4. 「근본적 해결」과 「보험적 대책」 ── 대책을 보는 관점

이 자료의 강점은 대책을 두 종류로 나눠 보여 준다는 점입니다.

• 근본적 해결: 취약점의 원인 자체를 없애는 구현. 예를 들어 SQL 인젝션이라면, SQL문 조립을 문자열 연결이 아니라 플레이스홀더로 수행함
• 보험적 대책: 취약점이 남았을 때 공격 성공률이나 피해를 낮추는 대책. 예를 들어 오류 메시지를 그대로 브라우저에 표시하지 않음

이 분류는 발주 담당자가 보안 설명을 들을 때의 척도가 됩니다. 「WAF(공격을 탐지·차단하는 메커니즘)를 넣으니 안심입니다」라는 설명은 보험적 대책 이야기이며, 애플리케이션 자체의 근본적 해결을 대신하지 못합니다. 반대로 근본적 해결을 구현한 위에 WAF를 겹치는 구성은 이치에 맞습니다. 어느 층의 이야기인지만 구분해 들어도, 제안이 타당한지가 상당히 보입니다.

5. 발주·검수에서 어떻게 쓰는가

「안전한 웹사이트 만드는 법」은 개발자용 자료이지만, 발주 담당자에게 쓸모가 있는 지점은 요구와 확인의 기준으로 쓸 수 있다는 점입니다.

• 견적·요건 단계: 사양서나 RFP에 「IPA 『안전한 웹사이트 만드는 법』이 제시하는 취약점에 대한 대책을 구현할 것」이라는 한 문장을 넣음. 기준을 이름으로 지정하면, 「보안을 고려한다」는 모호한 표현보다 요구가 분명해짐
• 검수 단계: 보안 구현 체크리스트의 해당 항목에 대해 확인 결과 제출을 요구함
• 계약 단계: 공개 후 CMS·플러그인·서버 업데이트를 누가 수행하는지, 취약점이 발견됐을 때의 대응이 유지보수 계약 범위인지 별도 견적인지를 문서로 선을 그음

세 번째가 특히 중요합니다. 웹사이트 보안은 만든 시점에 끝나지 않습니다. 공개 뒤에 새로 발견되는 취약점을 따라가며 유지됩니다. 이 「누가 계속 돌볼 것인가」는 수탁 개발·운영 유지보수 계약 글에서 정리한 유지보수 범위 이야기와 같은 구도입니다.

5.1. 사양서·RFP에 넣는 문장 예시

「보안을 고려할 것」만으로는, 무엇을 충족했다고 볼지가 정해지지 않습니다. 자료 이름과 제출물을 지정하면 요구가 검증 가능한 형태가 됩니다. 예를 들어 다음과 같이 씁니다.

보안 요건

1. 본건의 웹 애플리케이션은, IPA 「안전한 웹사이트 만드는 법 개정 제7판」 제1장이 제시하는 각 취약점에 대해, 같은 자료의 「근본적 해결」로 분류되는 대책을 구현할 것.
2. 납품 시, 같은 자료 부속 「보안 구현 체크리스트」의 전 항목에 대해 자체 점검 결과를 제출할 것. 「대응 불필요」로 판단한 항목은 그 이유(해당 기능이 없음 등)를 함께 적을 것.
3. 동적 처리가 있는 화면(문의 폼, 검색, 로그인, 파일 다운로드 등)에 대해, 입력값 취급과 출력 시 이스케이프 처리 방침을 설계서에 적을 것.
4. 공개 후 CMS 본체·테마·플러그인·실행 환경의 업데이트를 수행하는 주체와 빈도, 긴급 취약점이 공표된 경우의 대응 시간과 비용 부담을, 유지보수 계약에 명시할 것.

네 항목을 처음부터 모두 넣을 필요는 없습니다. 회사 소개 중심 사이트라면 1과 2만으로도, 「보안은 맡기겠습니다」로 발주하는 것과는 검수 때의 대화가 완전히 달라집니다.

5.2. 체크리스트의 내용

체크리스트는 Excel 파일 한 장이며, 「안전한 웹사이트 만드는 법 개정 제7판」 제1장에 대응하는 실시 항목 47개가 취약점 11가지별로 늘어서 있습니다. 각 행은 취약점 종류, 대책의 성격(근본적 해결/보험적 대책), 체크란(대응 완료/미대응/대응 불필요), 실시 항목 문장, 본편 해설 번호로 이루어집니다.

실제 항목은 예를 들어 다음과 같은 문장입니다.

(실시 항목 문장은 IPA 「안전한 웹사이트 만드는 법 개정 제7판」 부속 보안 구현 체크리스트에서 인용)

발주 담당자에게 쓰기 좋은 점은, 체크란에 「대응 불필요」가 있다는 점입니다. 로그인 기능이 없는 사이트에서 세션 관리 항목이 비어 있는 것은 정상이지만, 그것이 「해당하지 않으므로 대응 불필요」인지 「빠뜨림」인지는 적혀 있지 않으면 구별할 수 없습니다. 이유를 붙여 「대응 불필요」라고 적어 달라고 하는 것만으로, 검수 대화가 구체적이 됩니다.

6. 운영 중인 사이트는 「건강진단」한다

이미 공개한 사이트에는 별책 「웹 건강진단 사양」이 도움이 됩니다. 가동 중인 웹사이트의 안전성을 점검하기 위한 진단 항목(13항목)을 정리한 사양이며, 취약점 진단 서비스를 이용할 때 내용의 기준으로도 쓸 수 있습니다.

중소기업 회사 사이트에서, 실무상 위험이 특히 몰리기 쉬운 곳은 다음 두 곳입니다.

• 입력을 받는 부분: 문의 폼, 검색창, 회원 로그인 등. 제1장 취약점의 상당수가 여기와 관련됨
• CMS 운영: WordPress 등의 본체·테마·플러그인 업데이트가 멈춘 사이트는, 이미 알려진 약점을 찔려 변조되는 전형적 패턴. 업데이트가 누구 일인지 정해지지 않은 채 방치되는 경우가 매우 많음

CMS 업데이트 부담을 운영 체계째 다시 보고 싶다면, WordPress에서의 이전을 다룬 글도 참고가 됩니다. 또한 애초에 동적 처리를 줄인 정적 사이트 구성으로, 공격면 자체를 줄인다는 설계 판단도 있습니다. 당사가 사이트 제작에서 디지털청 디자인 시스템을 바탕으로 한 정적 구성을 채택하는 것도, 이 생각의 연장입니다.

덧붙여 웹사이트의 안전한 운영은, IPA 「중소기업 정보보안 대책 가이드라인」 제4.0판의 자사 진단에서도 확인 항목으로 나와 있습니다. 회사 전체 보안 대책 안에서의 위치는 가이드라인 제4.0판 해설 글을 봐 주십시오.

7. 용어 미니 사전

제작 회사와의 미팅에서 나오는 말 가운데, 이 글에서 쓴 것을 정리합니다. 뜻을 한 줄로 말할 수 있으면, 설명을 들을 때 「그것은 근본적 해결 이야기인가, 보험적 대책 이야기인가」를 스스로 판단할 수 있습니다.

정리

IPA 「안전한 웹사이트 만드는 법」의 요점을 정리합니다.

• 실제로 IPA에 신고된 취약점에 근거한, 웹사이트 약점 11가지와 대책의 정석 자료(개정 제7판·전체 115페이지)
• 대책은 근본적 해결과 보험적 대책의 두 층. WAF 같은 보험적 대책은 근본적 해결을 대신하지 못함
• 발주 담당자는 요건에 자료 이름을 명시하고, 체크리스트로 검수하고, 공개 후 업데이트 체제를 계약으로 정하는 식으로 쓸 수 있음
• 운영 중인 사이트는 「웹 건강진단 사양」을 기준으로 정기 점검함
• 회사 사이트의 현실적 위험은 폼 등 입력 처리와 CMS 방치에 몰리기 쉬움

보안은 「전문가가 시키는 대로 비용을 쓴다」거나 「아무것도 하지 않는다」의 양자택일이 되기 쉽습니다. 다만 공적 기준을 알고 있는 것만으로도, 요구도 확인도 자기 말로 할 수 있게 됩니다.

홈페이지 제작·리뉴얼을 검토하시는 분께

합동회사 코무라소프트에서는 홈페이지 제작·리뉴얼 때, 이 글에서 소개한 생각에 따라 폼 구현, CMS에 지나치게 기대지 않는 정적 구성, 공개 후 업데이트 체제까지 포함해 제안합니다. 「지금 사이트가 어떤 상태인지 모르겠다」는 단계의 현황 확인부터 상담하실 수 있습니다.

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

「안전한 웹사이트 만드는 법」은 어떤 자료인가요?

IPA(독립행정법인 정보처리추진기구)가 공개하는, 웹사이트 개발자·운영자를 위한 보안 자료입니다. IPA에 신고된 취약점 관련 정보 가운데 신고 건수가 많았거나 영향이 큰 항목을 골라 위협과 대책을 설명합니다. 최신 개정 제7판은 2021년 3월 공개이며, 전체 115페이지입니다. 본편 외에 보안 구현 체크리스트, 별책 「안전한 SQL 호출 방법」, 「웹 건강진단 사양」이 무료로 공개되어 있습니다.

회사 소개 수준의 홈페이지라도 보안 대책이 필요합니까?

필요합니다. 문의 폼이 하나라도 있으면 입력값을 처리하는 프로그램이 동작하고, WordPress 같은 CMS를 쓰고 있다면 관리 화면과 플러그인도 공격 대상이 됩니다. 공격자는 회사 규모를 가려 공격하지 않는 경우가 많고, 취약한 사이트를 기계적으로 찾아 변조, 바이러스 배포 경유지, 스팸 메일 발신 출처로 악용합니다. 피해자인 동시에 거래처나 방문자를 해치는 쪽이 될 수 있다는 점이 웹사이트의 무서운 점입니다.

근본적 해결과 보험적 대책의 차이는 무엇입니까?

「안전한 웹사이트 만드는 법」에서는 대책을 두 종류로 나눠 제시합니다. 근본적 해결은 취약점의 원인 자체를 없애는 구현 방법입니다(예: SQL문 조립에 플레이스홀더를 사용). 보험적 대책은 취약점이 남았을 때 공격 성공률이나 피해를 낮추는 대책입니다(예: 오류 메시지를 그대로 표시하지 않음). 보험적 대책만으로는 원인이 남으므로, 근본적 해결을 기본으로 두고 보험적 대책을 그 위에 더하는 것이 올바른 순서입니다.

제작 회사에 발주할 때 보안에 대해 무엇을 확인하면 됩니까?

적어도 ①「안전한 웹사이트 만드는 법」이 제시하는 취약점에 대한 대책을 구현하고 있는지, ②부속 보안 구현 체크리스트 등으로 확인 결과를 제시할 수 있는지, ③공개 후 CMS나 플러그인 업데이트를 누가 수행하는지(운영·유지보수 계약 범위)의 세 가지를 견적 단계에서 확인하기를 권합니다. 보안 요건은 나중에 추가하면 재작업이 커지므로, 계약 전에 문서로 확인해 두는 것이 중요합니다.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.