홈페이지를 발주하는 쪽도 알아두어야 할 ── IPA 「안전한 웹사이트 만드는 법」을 체크리스트로 활용하기

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

제작 회사에 맡기고 있으니 괜찮다, 회사 소개만 있는 사이트라서 노려지지 않는다고 생각하기 쉽지만, 문의 양식이 하나라도 있으면 입력값을 처리하는 프로그램이 동작하고 있고, WordPress 같은 CMS를 사용하고 있다면 관리 화면도 플러그인도 공격 대상입니다. 게다가 공격의 대부분은 특정 회사를 노리는 것이 아니라 약점이 있는 사이트를 기계적으로 찾아내어 이루어집니다.

그렇다면 무엇을 기준으로 “괜찮다”를 확인하면 좋을까요. 그 기준으로 오랫동안 사용되어 온 공적 자료가 IPA(독립행정법인 정보처리추진기구)의 안전한 웹사이트 만드는 법입니다.

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

1. 먼저 결론

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

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 본체・테마・플러그인・실행 환경의 업데이트를 수행하는 주체와 빈도, 긴급 취약점이 공표된 경우의 대응 시간과 비용 처리를 유지보수 계약에 명시할 것.

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

5.2. 체크리스트의 내용

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

실제 항목은 예를 들어 다음과 같은 문구로 작성되어 있습니다.

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

발주하는 쪽에서 사용하기 편리한 점은 체크란에 “대응 불필요”가 있다는 것입니다. 로그인 기능이 없는 사이트에서 세션 관리 항목이 비어 있는 것은 정상이지만, 그것이 “해당하지 않으므로 대응 불필요”인지 “누락”인지는 기재되어 있지 않으면 구분할 수 없습니다. 이유를 붙여 “대응 불필요”라고 써 달라고 하는 것만으로도 검수 대화가 구체적으로 변합니다.

6. 운영 중인 사이트는 “건강진단”을 한다

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

중소기업의 회사 사이트에서 실무상 특히 리스크가 집중되기 쉬운 곳은 다음 2곳입니다.

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

CMS 업데이트 부담을 운영 체제 전체에서 재검토하고 싶다면 WordPress로부터의 이전을 다룬 글도 참고가 됩니다. 또한 애초에 동적 처리를 줄인 정적 사이트 구성으로 함으로써 공격 대상 면적 자체를 줄인다는 설계 판단도 있습니다. 저희가 사이트 제작에서 디지털청 디자인 시스템을 기반으로 한 정적 구성을 채택하고 있는 것도 이러한 사고방식의 연장선입니다.

또한 웹사이트의 안전한 운영은 IPA의 「중소기업 정보보안 대책 가이드라인」 제4.0판의 자사 진단에서도 확인 항목으로 제시되어 있습니다. 회사 전체 보안 대책 안에서의 위치는 가이드라인 제4.0판 해설 글을 참고하시기 바랍니다.

7. 용어 미니 사전

제작 회사와의 미팅에서 등장하는 용어 중, 이 글에서 사용한 것을 정리합니다. 의미를 한 줄로 말할 수 있게 되면, 설명을 들을 때 “그것은 근본적 해결에 관한 이야기인가, 보험적 대책에 관한 이야기인가”를 스스로 판단할 수 있습니다.

정리

IPA 「안전한 웹사이트 만드는 법」의 포인트를 정리합니다.

• 실제로 IPA에 접수된 취약점을 바탕으로 한, 웹사이트 약점 11가지와 대책의 정석 자료(개정 제7판・전체 115페이지)
• 대책은 근본적 해결과 보험적 대책의 2단계. WAF 등의 보험적 대책은 근본적 해결을 대신할 수 없음
• 발주하는 쪽은 요건에 자료명을 명기하고, 체크리스트로 검수하고, 공개 후 업데이트 체제를 계약으로 정한다는 방식으로 활용할 수 있음
• 운영 중인 사이트는 「웹 건강진단 사양」을 기준으로 정기 점검
• 회사 사이트의 현실적인 리스크는 폼 등의 입력 처리와 CMS 방치에 집중되기 쉬움

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

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

합동회사 코무라소프트에서는 홈페이지의 제작・리뉴얼 시, 이 글에서 소개한 사고방식에 따라 폼 주변의 구현, CMS에 지나치게 의존하지 않는 정적 구성, 공개 후 업데이트 체제까지 포함하여 제안하고 있습니다. “지금 사이트가 어떤 상태인지 모르겠다”는 단계의 현황 확인부터 상담하실 수 있습니다.

관련 기사

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

관련 토픽

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

이 주제와 연결되는 서비스

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

자주 묻는 질문

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

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

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

회사 소개 정도의 홈페이지라도 보안 대책이 필요한가요?

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

근본적 해결과 보험적 대책의 차이는 무엇인가요?

「안전한 웹사이트 만드는 법」에서는 대책을 두 가지로 나누어 제시하고 있습니다. 근본적 해결은 취약점의 원인 자체를 제거하는 구현 방법입니다(예: SQL문 작성에 플레이스홀더를 사용). 보험적 대책은 취약점이 남아 있는 경우에 공격의 성공률이나 피해를 줄이는 대책입니다(예: 오류 메시지를 그대로 표시하지 않음). 보험적 대책만으로는 원인이 남기 때문에, 근본적 해결을 기본으로 하고 보험적 대책을 더하는 것이 올바른 순서입니다.

제작 회사에 발주할 때 보안에 관해 무엇을 확인하면 좋을까요?

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

저자 프로필

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

Go Komura

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

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