网站发包方也应该了解的内容 —— 把 IPA《安全网站构建指南》当作检查清单来使用

被问到「我们公司网站的安全性真的没问题吗？」时，能够有据可依地回答「没问题」的公司并不多。

很多人会觉得「交给制作公司负责就没问题」「我们只是个公司介绍网站，不会成为攻击目标」，但只要有一个咨询表单，就意味着有程序在处理输入内容；如果使用了 WordPress 之类的 CMS，管理后台和插件也都是攻击面。而且大多数攻击并不是针对特定公司发起的，而是通过机械化扫描寻找存在漏洞的网站。

那么，究竟应该以什么为基准来确认「没问题」呢？长期以来被作为该基准使用的官方资料，正是 IPA（独立行政法人信息处理推进机构）的《安全网站构建指南》。

本文将用网站发包方、运营方也能理解的语言，梳理这份资料究竟告诉了我们什么。

1. 先说结论

• 《安全网站构建指南》是基于实际向 IPA 举报过的漏洞、整理出网站 11 类弱点及其对策的资料。它不仅面向开发者，也可以作为发包与验收的基准来使用
• 对策分为「根本性解决」（消除原因）与「辅助性对策」（减轻损害）两类。以根本性解决为基础，辅助性对策是在此之上的补充
• 配套的《安全实施检查清单》可以直接作为向制作公司发包、验收时的确认项目来使用
• 附册《网站健康诊断规格》可作为对运营中网站进行定期检查时诊断项目的基准
• 在公司网站的实务中，表单等接受输入的部分，以及 CMS（如 WordPress）的运维，是两大主要风险来源。应在发包阶段就确定好不「做完即止」的持续运维体制

2. 什么是《安全网站构建指南》

《安全网站构建指南》是 IPA 从收到的漏洞相关举报信息中，挑选出举报数量较多、或一旦遭受攻击影响较大的漏洞，面向网站开发者与运营者整理对策的资料。目前公开的最新版本是修订第 7 版，全书共 115 页。当前分发的 PDF，是 2021 年 3 月 31 日作为第 4 次印刷更新的版本。除 PDF 之外，还针对各个漏洞发布了相应的 HTML 页面。

全书由三章构成。

除正文外，还另外公开了以下资料。

• 安全实施检查清单（Excel 格式）：用于确认是否已实施正文对策的一览表
• 附册《安全调用 SQL 的方法》：深入探讨数据库相关漏洞对策的资料
• 附册《网站健康诊断规格》：整理了用于诊断运营中网站的 13 项诊断内容的规格

以上资料均可从 IPA 官网 免费下载。

2.1 如何看待这份资料的时效性

在把这份资料当作基准使用之前，有一个前提需要先了解。修订第 7 版公开于 2015 年 3 月，此后每次加印都会加入修正，目前分发的 PDF 是 2021 年 3 月 31 日更新的第 7 版第 4 次印刷本。截至本文撰写时（2026 年 7 月），第 8 版尚未公开。

即便如此仍然可以把它当作基准，是因为这份资料所讨论的，是源自 Web 应用程序构建方式本身的弱点。把输入值嵌入 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. 本项目的 Web 应用程序，须针对 IPA《安全网站构建指南 修订第 7 版》第 1 章列出的各项漏洞，实施该资料中归类为「根本性解决」的对策。
2. 交付时，须就该资料配套的《安全实施检查清单》的全部项目提交自查结果。对于判断为「无需处理」的项目，须一并写明理由（如不具备相应功能等）。
3. 对于涉及动态处理的页面（咨询表单、搜索、登录、文件下载等），须在设计文档中记载输入值的处理方式与输出时的转义处理方针。
4. 须在维保合同中写明：上线后由谁、以何种频率更新 CMS 本体、主题、插件与运行环境；以及公布紧急漏洞时的响应时限与费用如何处理。

这四项不必一开始就全部写进去。如果是以公司介绍为主的网站，哪怕只写第 1 项和第 2 项，验收时的对话也会与「安全性就交给你们了」这样发包完全不同。

5.2 检查清单的内容

检查清单是一个 Excel 文件，其中按 11 类漏洞排列着与《安全网站构建指南 修订第 7 版》第 1 章相对应的 47 个实施项目。每一行由漏洞的类别、对策的性质（根本性解决／辅助性对策）、勾选栏（已处理／未处理／无需处理）、实施项目的文字，以及正文的解说编号构成。

实际的项目，是用类似下面这样的文字写成的。

（实施项目的文字引自 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 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。