網站發包方也該了解 ── 把 IPA《安全的網站製作方式》當作檢查清單來用

被問到「我們公司的網站,資安沒問題吧?」時,能有根據地回答「沒問題」的公司並不多。

很多人會覺得「交給製作公司負責就沒問題」「只是公司簡介網站,不會被盯上」,但只要有一個諮詢表單,就代表有程式在處理輸入值;若使用 WordPress 這類 CMS,管理畫面與外掛程式都會是攻擊目標。而且大多數攻擊並不是針對特定公司下手,而是機械式地找出脆弱的網站來進行。

那麼,究竟該以什麼為基準來確認「沒問題」呢?長期以來被當作這個基準使用的官方資料,就是 IPA(獨立行政法人資訊處理推進機構)的《安全的網站製作方式》。

本文將用網站發包方、營運方也能理解的說法,整理這份資料到底告訴我們什麼。

1. 先講結論

• 《安全的網站製作方式》是根據實際向 IPA 通報過的漏洞,整理出網站 11 種弱點與對策的資料。不只開發者可用,也能作為發包與驗收的基準
• 對策分為「根本解決」(消除成因)與「保險性對策」(減輕損害)兩種。基本做法是根本解決,保險性對策則是在此之上的加強
• 附屬的「安全實作檢核表」,可以直接作為向製作公司發包、驗收時的確認項目來使用
• 別冊《網站健康檢查規格》,可作為定期檢查營運中網站時診斷項目的基準
• 在公司網站的實務上,表單等接受輸入的部分,以及 CMS(如 WordPress)的營運,是兩大風險來源。應在發包時就一併決定好不「做完就結束」的持續營運體制

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、以工作階段(session)識別使用者本人、從表單輸入內容寄送郵件,這些機制至今都沒有改變。11 種漏洞與「根本解決/保險性對策」這種思考方式,現在依然通用於作為實作的確認基準。

反過來說,近年的威脅動向這份資料無法涵蓋。勒索軟體攻擊、經由交易對象或委外廠商入侵、使用生成式 AI 伴隨的風險等議題,原本就不在這份資料的守備範圍內。這部分需要靠每年更新的資料來補足。

這 3 份資料不必分開來讀。「實作的基準看這份資料,威脅的最新動向看 10 大威脅,公司的體制看指南」,依角色分工,需要時再各自查閱即可。10 大威脅 2026 年版的內容,收錄在《資訊安全10大威脅 2026 ── 排行榜的正確解讀方式,以及中小企業真正該做的對策》中;指南第 4.0 版,則收錄在《中小企業的資安對策,該從何開始 ── IPA「中小企業資訊安全對策指南」第4.0版導覽》中。

3. 用「會發生什麼事」解讀 11 種漏洞

第 1 章列出的 11 種漏洞,雖然是以開發者慣用的術語呈現,但若換成「放著不管,自家網站會發生什麼事」來理解,發包方也會發現這絕非事不關己。

最右欄是這項漏洞在公司網站上容易造成問題的位置範例。只要看自家網站有沒有同樣的功能,就能判斷哪一列與自己有關。

舉例來說,「郵件標頭注入」正好對應到公司簡介網站的諮詢表單。防護不足的表單會遭濫用為垃圾郵件的發送來源,甚至傷害公司網域的信譽(郵件是否能送達對方)。表單郵件無法送達的問題,正如《聯絡表單郵件收不到的原因與解決方法》一文所述,會直接導致商機的損失。

4. 「根本解決」與「保險性對策」── 對策的思考方式

這份資料的優點,在於把對策分成兩種來呈現。

• 根本解決:消除漏洞成因本身的實作方式。舉例來說,SQL 注入的話,就是在組合 SQL 陳述式時不用字串串接,改用預留位置
• 保險性對策:在漏洞仍然殘留的情況下,用來降低攻擊成功率或損害程度的對策。舉例來說,不把錯誤訊息原封不動地顯示在瀏覽器上

這種分類方式,可以成為發包方在聽取資安說明時的一把尺。「因為會導入 WAF(偵測並阻擋攻擊的機制),所以請放心」這類說明,談的是保險性對策,並不能取代應用程式本身的根本解決。反過來說,在實作根本解決之後再疊加 WAF,則是合理的架構。只要聽的時候能分辨對方講的是哪一層,提案是否妥當就會清楚許多。

5. 在發包與驗收時如何運用

《安全的網站製作方式》雖是面向開發者的資料,但對發包方而言,它的實用之處在於可以作為提出要求與進行確認的基準。

• 報價・需求階段:在規格書或 RFP 中加入一句「須針對 IPA《安全的網站製作方式》所列漏洞實作對策」。明確指名基準,能讓要求比「注意資安」這類模糊的說法更清楚
• 驗收階段:要求對方針對安全實作檢核表中的相應項目提出確認結果
• 簽約階段:以書面明確劃分上線後由誰負責更新 CMS・外掛程式・伺服器,以及發現漏洞時的因應是屬於維護合約範圍還是要另行報價

第三點尤其重要。網站的資安並非在製作完成的當下就已完備,而是要靠持續因應上線後才發現的新漏洞來維持。這個「由誰持續負責」的問題,與《受託開發・營運維護的合約該如何簽訂 ── 從 IPA「模型交易・合約書」學習準委任與承攬的區分運用》一文整理的維護範圍議題,是同樣的結構。

5.1 寫在規格書・RFP 中的範例文字

只寫「注意資安」,無法判斷做到什麼程度才算滿足要求。指定資料名稱與應提交的成果物,要求才會變成可驗證的形式。舉例來說,可以這樣寫:

資安要求

1. 本件的網站應用程式,須針對 IPA「安全的網站製作方式 改訂第 7 版」第 1 章所列各項漏洞,實作該資料中歸類為「根本解決」的對策。
2. 交付時,須提交該資料附屬「安全實作檢核表」全部項目的自我檢查結果。判斷為「無須因應」的項目,須併記其理由(例如不具備相應功能等)。
3. 對於伴隨動態處理的畫面(諮詢表單、搜尋、登入、檔案下載等),須在設計書中記載輸入值的處理方式與輸出時跳脫處理的方針。
4. 須在維護合約中明訂上線後負責更新 CMS 本體・佈景主題・外掛程式・執行環境的主體與頻率,以及公布緊急漏洞時的因應時間與費用歸屬。

不必一開始就把 4 個項目全部放進去。若是以公司簡介為主的網站,即使只有 1 和 2 兩項,驗收時的對話也會與「資安都交給你們」這種發包方式截然不同。

5.2 檢核表的內容

檢核表是一份 Excel 檔案,依照「安全的網站製作方式 改訂第 7 版」第 1 章的內容,按 11 種漏洞分別列出對應的 47 個實施項目。每一列由漏洞種類、對策的性質(根本解決/保險性對策)、勾選欄(已對應/未對策/無須因應)、實施項目的文字、本編解說編號所構成。

實際的項目,舉例來說是以下面這樣的文字撰寫的。

(實施項目文字引用自 IPA「安全的網站製作方式 改訂第 7 版」附屬的安全實作檢核表)

對發包方來說好用的地方,在於勾選欄有「無須因應」這個選項。沒有登入功能的網站,工作階段管理的項目留空是正常的,但這究竟是「不適用所以無須因應」還是「遺漏」,如果沒有填寫就無法區分。只要請對方附上理由填寫「無須因應」,驗收時的對話就會變得具體。

6. 對營運中的網站做「健康檢查」

對於已經上線的網站,別冊《網站健康檢查規格》會很有幫助。這是一份整理了針對運作中網站進行安全性檢查的診斷項目(13 項)的規格,也可以作為使用漏洞診斷服務時判斷服務內容是否到位的參考標準。

在中小企業的公司網站中,實務上風險特別容易集中的,是以下兩個地方。

• 接受輸入的部分:諮詢表單、搜尋欄、會員登入等。第 1 章的漏洞大多與此相關
• CMS 的營運:本體・佈景主題・外掛程式更新已經停滯的 WordPress 等網站,是遭利用已知弱點竄改的典型模式。更新究竟是誰的工作一直沒有確定、就這樣被放著不管的案例非常多

若想連同營運體制一起重新檢視 CMS 的更新負擔,《從 WordPress 遷移到 Movable Type ── 正因為是「反方向」,更該整理清楚的實務步驟》一文也可供參考。此外,也有一種設計判斷是從一開始就減少動態處理、採用靜態網站架構,藉此縮小攻擊面本身。本公司在網站製作中採用的以日本數位廳設計系統為基礎的靜態架構,正是這種思路的延伸。

此外,網站的安全營運,在 IPA「中小企業資訊安全對策指南」第 4.0 版的自我診斷中,也被列為確認項目之一。關於它在公司整體資安對策中的定位,請參閱《中小企業的資安對策,該從何開始 ── IPA「中小企業資訊安全對策指南」第4.0版導覽》。

7. 用語小辭典

整理與製作公司開會時會出現、且本文用到的詞彙。只要能用一句話說出意思,聽對方說明時就能自己判斷「這是根本解決的話題,還是保險性對策的話題」。

總結

整理一下 IPA《安全的網站製作方式》的重點。

• 根據實際向 IPA 通報過的漏洞,整理出網站 11 種弱點與對策的經典資料(改訂第 7 版・全書 115 頁)
• 對策分為根本解決與保險性對策兩個層次。WAF 等保險性對策無法取代根本解決
• 發包方可以採用以下用法:在需求中明確寫出資料名稱、以檢核表進行驗收、並以合約確定上線後的更新體制
• 營運中的網站,可以《網站健康檢查規格》為基準做定期檢查
• 公司網站現實中的風險,容易集中在表單等輸入處理,以及 CMS 放著不管這兩方面

資安問題往往容易變成「完全照專家說的花錢」或「什麼都不做」這種二選一,但只要了解官方基準,無論是提出要求還是進行確認,都能用自己的話來做。

給正在考慮網站製作・改版的您

合同會社小村軟體在承接網站的製作與改版時,會依照本文介紹的思路,從表單相關的實作、不過度依賴 CMS 的靜態架構,到上線後的更新體制,提出全面的方案建議。即便您還處於「不清楚現在的網站是什麼狀態」這個階段,也歡迎從現狀確認開始諮詢。

相關文章

共用相同標籤的最新文章。能以相近的主題延伸理解。

相關主題

與本文相近的主題頁面。以本文為起點，可進一步連到相關服務與其他文章。

與本主題相關的服務

本文連結到以下服務頁面，歡迎從最接近的入口查看。

常見問題

整理諮詢這個主題時常見的問題。

《安全的網站製作方式》是什麼樣的資料？

這是 IPA(獨立行政法人資訊處理推進機構)公開的一份資安資料,對象是網站開發者與營運者。內容從 IPA 收到的漏洞相關通報中,挑選通報件數較多、或影響程度較大的項目,解說其威脅與對策。最新的改訂第 7 版於 2021 年 3 月公開,全書共 115 頁。除本編外,還免費公開了安全實作檢核表,以及別冊《安全的 SQL 呼叫方式》《網站健康檢查規格》。

只是公司簡介程度的網站,也需要做資安對策嗎？

需要。只要有一個諮詢表單,就代表有程式在處理輸入值;若使用 WordPress 這類 CMS,管理畫面與外掛程式也都會成為攻擊目標。攻擊者不見得會挑選公司規模來下手,而是機械式地找出有漏洞的網站,將其濫用為竄改網頁、散布病毒的跳板,或垃圾郵件的發送來源。網站可怕的地方在於,你在成為被害者的同時,也可能變成對交易對象與訪客加害的一方。

根本解決與保險性對策有什麼不同？

《安全的網站製作方式》把對策分成兩種來說明。根本解決,是消除漏洞成因本身的實作方式(例如:組合 SQL 陳述式時使用預留位置)。保險性對策,則是在漏洞仍然殘留的情況下,用來降低攻擊成功率或損害程度的對策(例如:不直接顯示錯誤訊息)。只靠保險性對策,成因仍會殘留,因此正確的順序是以根本解決為基礎,再疊加保險性對策。

向製作公司發包時,關於資安應該確認哪些事項？

建議至少在報價階段確認以下 3 點:①是否已針對《安全的網站製作方式》所列漏洞實作對策;②能否透過附屬的安全實作檢核表等方式提出確認結果;③上線後由誰負責更新 CMS 與外掛程式(是否屬於營運與維護的合約範圍)。資安需求若事後才追加,會造成很大的返工,因此在簽約前以書面確認清楚十分重要。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司 代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。