網站資安怎麼做？企業網站 10 大安全防護、弱點掃描與資安檢測指南

網站資安是什麼？

網站資安（Website Security）指保護網站、伺服器、資料庫、程式、帳號與使用者資料，避免遭到未授權存取、竄改、刪除、植入惡意程式或資料外洩。

企業網站常見的攻擊入口不只有網站首頁。
網站管理員使用弱密碼，攻擊者可能直接登入後台；
CMS 外掛沒有更新，可能被利用漏洞上傳惡意程式；
程式沒有正確處理輸入資料，可能產生 SQL Injection 或 XSS；
主機權限設定錯誤，也可能讓攻擊者取得不該取得的檔案。

網站資安其實是一整套管理問題，可以拆成五層：

只處理其中一層，都不算完整。

為什麼企業網站現在更需要做資安？

公開網站最大的特性是任何人都可以連線。
正常客戶可以連，Google 可以爬，攻擊者的 Bot 當然也可以。

大量網站攻擊已經不需要人工一個一個網站檢查，而是透過自動化工具掃描
「哪些網站用了某個 CMS」
「哪些網站安裝特定版本的外掛」
「哪些網址存在已公開 CVE」，
找到目標後再大量測試。

一個每天只有幾十人瀏覽的中小企業網站，也可能被攻擊。
攻擊者不一定認識這間公司，有時只是網站剛好出現在自動掃描結果裡。

目前搜尋環境也正受到 AI 搜尋摘要與 AI 工具影響，部分使用者會直接在搜尋結果取得答案，
不一定再進入網站，自然流量與點擊率都可能受到影響。
同一時間，自動化漏洞掃描、Bot 與攻擊工具也越來越普及，
攻擊者可以用更低成本、大量掃描公開網站。
AI 工具的普及，也讓部分自動化分析與攻擊腳本產生變得更容易，企業網站需要面對更快變動的資安環境。

網站最常見的資安風險有哪些？

檢查企業網站，可以先從以下幾類問題著手。

1. CMS、外掛與套件沒有更新

WordPress、Joomla、PHP 套件、JavaScript Library 或第三方 Plugin 都可能出現安全漏洞。
漏洞公開之後，如果網站仍停留在有問題的版本，攻擊者就可能依照已知攻擊方式測試。
CMS 更新屬於資安管理的一部分，需要固定排入維護排程，不能等有空再做。

2. 弱密碼與帳號遭暴力破解

admin123、公司電話、生日或同一組密碼到處使用，都會增加帳號遭破解的風險。
比單純要求密碼複雜更實際的方式，
是使用足夠長且不重複的密碼、密碼管理工具，並對管理員帳號啟用 MFA。

3. SQL Injection

SQL Injection 是利用網站沒有正確處理輸入資料的漏洞，讓攻擊者干擾原本應該執行的資料庫查詢，
可能造成未授權讀取資料、修改資料、刪除資料、繞過登入驗證，
在特定條件下進一步取得系統權限。
防護核心是在程式端使用參數化查詢、輸入驗證以及正確的權限設計，單純封鎖特殊符號並不足夠。

4. XSS 跨網站指令碼攻擊

XSS 是網站把未經正確處理的內容輸出到網頁，導致惡意 JavaScript 在使用者瀏覽器執行，
常見風險包括偽造頁面內容、操作使用者 Session、
竄改網站顯示、引導使用者進入惡意網站。
程式端需要依輸出位置進行適當編碼，必要時搭配 Content Security Policy（CSP）。

5. 惡意檔案上傳

具有圖片、附件、履歷、檔案上傳功能的網站都應該特別留意。
如果只看副檔名，沒有驗證 MIME Type、檔案內容、儲存位置及執行權限，
攻擊者可能嘗試上傳可執行程式或 Webshell。

6. 權限控制失效

有登入不代表有權限。
一般會員修改網址中的 ID，可能就看到別人的訂單；
一般後台帳號直接輸入某個網址，可能就開啟管理員功能。
這些都屬於 Access Control 問題。

7. 主機或 Web Server 設定錯誤

例如開啟不需要的服務、Debug 模式沒有關閉、目錄可以直接瀏覽、
權限設定過度寬鬆、洩露版本資訊、SSH 管理方式不安全，
都會增加攻擊面。

不同主機環境在備份、SSL、PHP 版本與維護方式上也會有差異，可參考：網站主機方案與規格說明。

8. 第三方供應鏈風險

網站安全不只看自己寫的程式。
網站可能同時使用 npm 套件、Composer 套件、WordPress Plugin、
Joomla Extension、JavaScript Library、
API、CDN、GitHub Actions、第三方支付或會員服務，
任何一個依賴元件出現漏洞，都可能影響網站。
新版網站資安管理開始更重視 SBOM、第三方元件盤點與供應鏈安全。

9. 缺少日誌與監控

如果網站被登入、檔案遭修改或短時間出現大量錯誤，
卻完全沒有 Log 與警告，問題可能過了幾個星期甚至幾個月才被發現。
網站資安不是只有阻擋，還必須具備看得到異常的能力。

10. 備份存在，但從來沒有測過還原

每天都有備份不等於發生事情一定救得回來，
需要確認備份是否真的成功、是否完整、是否保留多個版本、
是否與正式主機分離、是否做過還原測試。
等到發生勒索軟體、主機故障或網站被竄改時，
才發現備份也不能用，處理起來會非常麻煩。

社交工程攻擊：網站沒有漏洞，帳號也可能被騙走

企業網站的資安風險不一定來自程式漏洞。
另一種很常見的方式是社交工程（Social Engineering），
攻擊者不直接破解網站，而是利用人員的信任、緊張或時間壓力，
誘導使用者主動提供帳號密碼、點擊惡意連結、開啟附件，甚至授權攻擊者登入系統。

實務上曾遇過企業收到看起來很像正常系統通知的信件，
例如假冒網站主機商、網域註冊商、Microsoft 365、
Google、Cloudflare、公司主管或資訊人員，
信件內容可能寫著「帳號即將停用」
「網域即將到期」
「網站偵測到異常」
「信箱容量已滿」
「請立即重新驗證帳號」等訊息，
並附上一個看起來很像官方網站的登入連結。

這類信件真正的目的，通常是把使用者帶到仿冒登入頁面。
使用者如果輸入 Email、CMS、Microsoft、Google 或其他管理帳號密碼，
帳密就可能直接送到攻擊者手上。
更進一步的攻擊還可能竊取 Session、要求使用者下載檔案，或誘導執行惡意程式。

常見的社交工程與釣魚信件特徵

• 要求立即登入、驗證或修改密碼
• 聲稱帳號、網域、主機或 Email 即將停用
• 使用「24 小時內處理」「最後通知」等急迫文字
• 寄件者名稱看起來正常，但實際 Email 網域不正確
• 連結文字像官方網址，實際點擊網址卻是其他網域
• 要求開啟不明附件或下載程式
• 要求提供密碼、驗證碼、API Key 或其他敏感資訊
• 信件內容與平常服務商通知方式不同

收到疑似詐騙信件，最重要的是不要點連結、不要下載附件

社交工程攻擊不一定只靠假的登入頁面。
攻擊者也可能利用 Word、Excel、PDF、ZIP、RAR 或其他附件，
誘導使用者下載、解壓縮或執行檔案。
這些附件可能夾帶木馬、資訊竊取型惡意程式、勒索軟體或其他惡意程式。

一旦執行惡意檔案，可能造成帳號密碼、
瀏覽器 Cookie、Session 或其他敏感資料遭竊，
也可能讓攻擊者取得電腦控制權，甚至將電腦中的檔案加密。
如果使用者另外在仿冒網站輸入信用卡或付款資料，也可能進一步造成金融資訊外洩或未授權交易。

因此，收到自稱來自主機商、網域註冊商、銀行、
政府機關、客戶、供應商或知名企業的信件時，
就算寄件者名稱與 Logo 看起來正常，也不要只憑信件外觀判斷真偽。

詐騙信件常用哪些理由騙你下載檔案？

攻擊者經常利用日常工作中「看起來很合理」的事情降低收件人的警覺，例如：

• 假訂單或退款通知：
  聲稱有異常扣款、訂單取消或退款文件，要求下載 Word、Excel、PDF 或其他附件。


• 商務合作或產品提案：
  假冒客戶、品牌或合作廠商，寄送「產品目錄」「詢價資料」「合作企劃」「品牌拓展說明」等 ZIP／RAR 壓縮檔。


• 政府或公家機關通知：
  偽裝成罰單、法院通知、稅務文件、繳費通知或其他公文，引導開啟附件或外部連結。


• 主機、網域或 Email 異常：
  聲稱網站即將停用、網域到期、信箱容量不足或帳號偵測到異常，要求立即登入驗證。


• 帳號安全通知：
  假冒 Google、Microsoft、Cloudflare 或其他服務平台，要求重新登入或修改密碼。

這類攻擊最有效的地方，就是內容通常跟日常工作很像。
看到「客戶詢價」「訂單」「公文」「帳號異常」時，人很容易因為急著處理工作而直接打開附件。

如果只是收到可疑信件，應該怎麼處理？

1. 不要點擊連結。
   需要確認帳號狀態時，自行開啟官方網站或原本收藏的管理網址。


2. 不要下載或開啟不明附件。
   尤其是不明 ZIP、RAR、EXE、ISO、Office 文件或要求另外輸入密碼解壓縮的檔案。


3. 檢查實際寄件 Email。
   寄件者顯示名稱可以偽造，要看 @ 後方真正的網域。


4. 檢查連結實際網址。
   顯示文字寫 Google、Microsoft 或公司名稱，不代表實際網址就是官方網站。


5. 用其他管道確認。
   如果信件自稱客戶、供應商或公司同仁，可用既有電話、LINE 或原本的 Email 聯絡方式再次確認。

如果已經下載並執行可疑檔案，應該立即做什麼？

如果檔案已經下載，而且已經開啟、執行程式、啟用巨集或解壓縮後執行其中檔案，
就不要只把原始 Email 刪掉，此時應把它當成可能的端點資安事件處理。

1. 立即中斷網路

   關閉 Wi-Fi 或拔除網路線，降低惡意程式持續向外傳送資料、
   下載其他程式或向內部網路擴散的機會。

2. 不要再用這台電腦登入重要帳號

   如果設備可能已經感染惡意程式，
   在同一台電腦重新修改密碼，新的密碼仍可能再次被竊取。

3. 使用其他確認安全的設備修改重要密碼

   優先處理 Email、Google、Microsoft、CMS 後台、主機、Cloudflare、
   社群帳號及其他高權限帳號，並撤銷既有登入 Session。

4. 啟用或重新確認 MFA

   確認多因素驗證沒有被攻擊者修改，
   並檢查帳號中是否出現陌生裝置、異常登入或新增的驗證方式。

5. 檢查金融帳戶

   如果曾在可疑網站輸入信用卡、網路銀行或付款資料，應立即確認交易紀錄，
   必要時聯絡銀行處理卡片停用、掛失或其他安全措施。

6. 執行完整端點安全檢查

   使用 Windows Defender 或企業使用的端點防護軟體進行完整掃描。
   如果已發現資訊竊取型惡意程式、木馬、勒索軟體，或無法確認設備是否乾淨，
   應交由專業人員進一步檢查；必要時重新安裝作業系統。

企業要怎麼防範社交工程攻擊？

第一個原則是：
不要從可疑 Email 裡的連結直接登入重要系統。
如果收到主機、網域、Google、Microsoft、Cloudflare 或網站後台的異常通知，
應自行開啟官方網站或原本收藏的管理網址確認，而不是直接點信件中的登入按鈕。

管理員帳號也應啟用 MFA，多一道驗證可以降低單純帳密外洩後直接遭登入的風險。
同時建議定期進行員工資安教育，讓會接觸網站後台、Email、主機、FTP、Cloudflare 或其他高權限系統的人員，
都知道如何檢查寄件者、網域、連結與附件。

如果已經在可疑頁面輸入帳號密碼，不要只把信件刪掉。
應立即使用確認乾淨的設備修改密碼、撤銷既有登入 Session、
確認 MFA 設定、檢查近期登入紀錄，並確認同一組密碼是否曾使用在其他系統。
如果曾下載或執行不明檔案，還需要進一步檢查使用端電腦是否遭到惡意程式感染。

網站資安最容易被忽略的一點，就是「人也是攻擊面」。
WAF、SSL、弱點掃描可以降低技術漏洞風險，
但沒有辦法阻止管理員自己把帳密輸入到假的登入頁面，
因此技術防護、帳號管理與人員資安意識必須一起做。

OWASP Top 10 2025：現在網站最需要注意哪些風險？

OWASP Top 10 是 Web 應用程式安全常用的風險參考標準。
2025 年版本反映的重點已經不只是 SQL Injection 或 XSS 等傳統程式漏洞，
也更加重視存取控制、供應鏈、設定與架構問題。

企業不需要把 OWASP Top 10 當成考試題目背下來，
比較實際的用途是拿它當網站開發、驗收與弱點檢查的基本清單。
現代網站大量依賴外掛、套件與雲端服務，供應鏈安全也不能只看程式是不是自己寫的。

存取控制失效連續蟬聯第一名，安全設定錯誤上升至第二名，
軟體供應鏈失效與異常狀況處理不當則是這次新增的類別，
反映出現代網站的風險已經從單純的程式漏洞，擴大到設定、
依賴套件與錯誤處理機制。

企業網站資安怎麼做？10 大安全防護

知道有哪些問題之後，下一步是實際防護

第一項：CMS、外掛與套件定期更新

這是成本最低，卻經常被忽略的一項。
需要盤點 CMS 版本、PHP／Runtime 版本、Plugin／Extension、Template／Theme、
JavaScript 套件、Composer／npm Dependency、Web Server、作業系統。
某個元件已經停止維護，就不應該只因為現在還能跑而繼續使用。

第二項：管理員帳號啟用 MFA

網站後台、Cloudflare、主機控制台、
Google Workspace、GitHub 等高權限帳號，都建議啟用多因素驗證。
即使密碼外洩，多一道驗證仍可以降低帳號直接遭登入的機率。

第三項：導入最小權限管理

不要所有工作人員都使用 Super User。
編輯只需要文章管理權限，就不要提供網站設定權限；
行銷人員只管理內容，就不應該具有安裝 Extension 的權限。
人員離職或工作內容改變時，也要同步移除帳號或權限。

第四項：全站 HTTPS 與安全設定

網站至少應該強制使用 HTTPS
還需要確認 TLS 設定、憑證是否正常續期、HTTP 是否自動轉 HTTPS、
HSTS 是否適合啟用、Cookie Secure／HttpOnly／SameSite 設定、
CSP 等 Security Headers。
SSL 是基本配備，只有 SSL 並不等於網站安全，
SSL 主要解決傳輸加密問題，並不能修好 CMS 漏洞或 SQL Injection。

第五項：部署 WAF 與登入防護

WAF（Web Application Firewall）可以在網站前面協助攔截部分惡意請求，
例如 SQL Injection 特徵、XSS 嘗試、惡意 Bot、異常流量、
特定 CVE 攻擊模式、暴力破解。
Cloudflare、AWS WAF 或 ModSecurity 都屬於常見做法，
但 WAF 是額外防線，不應該取代程式更新。

第六項：定期執行弱點掃描

弱點掃描的主要用途是主動找出已知問題，而不是等到被駭才回頭找原因。
至少應針對公開網站、Web Server、CMS、套件、
API、SSL/TLS、開放 Port 進行檢查。
重大程式更新或新功能上線之後，也適合重新執行掃描。

第七項：做好備份與還原

建議採用多版本與異地備份，常見做法可以參考 3-2-1 原則：
3 份資料、2 種儲存媒體、至少 1 份異地保存。
網站備份至少包括網站程式、圖片與上傳檔案、
資料庫、必要設定檔，並應定期做還原測試。

如果想進一步了解網站主機、備份與主機環境的差異，可參考：網站主機常見問題與主機環境說明。

第八項：記錄 Log 並建立異常告警

至少應保留管理員登入、登入失敗、權限異動、程式錯誤、Apache／Nginx Access Log、
WAF Log、SSH 登入、重要設定修改等紀錄。
較大型網站則可以整合 SIEM。
留 Log 的重點在於發生事情時能夠知道誰、什麼時間、從哪裡、做了什麼，數量多寡不是關鍵。

第九項：把資安放進開發流程

企業如果有客製化系統，不應該等網站做完才第一次檢查資安。
比較好的做法是需求、開發、Code Review、SAST、Dependency Scan、
測試環境、DAST、修復、上線、持續監控，
這就是 Secure SDLC 的概念。

第十項：建立事件應變流程

企業至少要先想好，如果明天網站被駭，誰負責處理。
需要知道誰可以關閉網站、誰有主機權限、備份在哪裡、誰負責程式、
誰負責對外聯絡、是否涉及個資、Log 保存在哪裡、如何確認環境已經乾淨。
平常先訂好，比事件發生後臨時找帳號密碼有效得多。

網站弱點掃描是什麼？

弱點掃描是使用工具，針對網站、主機、應用程式或元件尋找已知安全漏洞與錯誤設定，
比較像網站的定期健康檢查。
掃描可能發現舊版 CMS、已知 CVE、SSL/TLS 問題、
Security Header 缺失、XSS、SQL Injection、錯誤設定、
過期套件、開放 Port、敏感資訊外洩。

弱點掃描結果仍需要人工判讀。
掃描工具顯示 High Risk，不一定代表真的已經可以被攻擊；
掃描顯示沒有問題，也不能證明網站百分之百安全。

弱點掃描、原始碼檢測、滲透測試有什麼不同？

這三項經常被混在一起討論。

弱點掃描的範圍可以比 DAST 更廣，主機、網路、TLS、開放 Port、
套件版本等都可能屬於弱點掃描的檢查對象；
DAST 則專指針對執行中的 Web Application 進行動態測試，
屬於弱點掃描其中一種常見做法，下一節會另外說明。

三者不會互相取代，網站要求越高，越適合搭配使用。

SAST、DAST、SCA 是什麼？

SAST：靜態應用程式安全測試

直接檢查原始碼，不需要讓網站真正執行，
適合找不安全函式、SQL Injection 風險、硬編碼密碼、
不安全資料流、程式設計缺陷，通常適合放在開發與 CI/CD 階段。

DAST：動態應用程式安全測試

從網站外部對運作中的網站進行測試，看到的角度比較接近真正使用者或攻擊者看到的網站。
常見工具例如 OWASP ZAP、Burp Suite。

SCA：軟體組成分析

SCA 的重點放在檢查用了哪些第三方元件，
以及這些元件是否存在已知漏洞，跟自己程式寫錯什麼是不同的檢查方向
。現代網站大量使用 Composer、npm 與開源套件，這一項的重要性越來越高。

網站多久要做一次弱點掃描？

沒有一個頻率適合所有公司。
一般形象官網可以依網站重要程度、變更頻率與風險安排週期性檢查。
電商、會員網站、API 平台、有個資的系統、金流網站、
大型企業系統、高流量服務，掃描頻率通常需要更高。

除了固定週期，遇到 CMS 大版本升級、重要 Plugin 更新、新功能上線、主機搬遷、
程式大量修改、發現重大 CVE、發生疑似資安事件，
也應該重新檢查。
比起死守一定三個月一次，依風險與變更觸發檢查通常更實際。

網站資安檢測有哪些項目？

企業網站可以依需求分成以下幾層。

Web 網站檢測

SQL Injection、XSS、CSRF、SSRF、File Inclusion、
Directory Traversal、Access Control、Authentication、Session、File Upload、Security Header

主機檢測

OS 漏洞、Web Server、開放 Port、
SSH、TLS、權限設定、不必要服務

程式檢測

SAST、Dependency Scan、
Secret Scan、Code Review、API Security Test。

管理制度檢查

管理員權限、MFA、備份、Log、
更新制度、事件應變程序、第三方供應商管理。

做過一次弱掃，跟整個網站資安都沒問題，是兩件不同的事。

網站資安檢查表

企業可以先用下面這張表快速檢查。

如果這張表有一半以上回答不知道，
網站的第一步通常應該先做資產盤點，再考慮加購資安產品。

網站已經被駭，只更新 Joomla 或 WordPress 就好了嗎？

不夠。

這是企業網站被入侵之後最容易犯的錯。
假設網站是利用某個 Joomla Extension 或 WordPress Plugin 漏洞入侵，
把 Extension 更新到安全版本，只代表原本的入口可能被封住。

攻擊者先前如果已經上傳 Webshell、新增管理員、修改 index.php、
修改核心檔案、寫入排程、修改資料庫、塞入 iframe、
上傳惡意 JavaScript、取得 FTP／SSH 帳密，
這些東西不會因為 CMS 更新而自動消失。

WordPress 近期的安全更新與網站遭入侵後處理方式，可延伸閱讀：WordPress 2026 安全更新：SQL Injection、RCE 與網站被駭後怎麼處理。

網站被入侵後應該怎麼處理？

可以依序處理：

1. 先限制攻擊持續發生

視事件程度暫停網站、限制管理後台或啟用維護頁，不要急著先刪所有東西。

2. 保存目前環境與 Log

先留下 Web Log、FTP Log、SSH Log、WAF Log、可疑檔案、
資料庫、系統狀態，否則清完之後可能再也不知道攻擊怎麼進來。

3. 找出可能的入侵入口

例如 CMS CVE、Plugin 漏洞、弱密碼、
FTP 帳號、惡意檔案上傳、主機漏洞。

4. 檢查網站檔案

比對官方 Core，找出最近修改檔案、不明 PHP、
Webshell、混淆程式碼、異常 JavaScript、不合理 iframe。

5. 檢查資料庫與帳號

確認是否有不明管理員、文章是否被植入惡意內容、
設定是否遭修改、User Permission 是否異常。

6. 重設重要帳號

包括 CMS、主機、FTP、SSH、Database、
API Key、Cloudflare、GitHub。

7. 完成修補後重新掃描

確認漏洞已經不存在，再恢復網站。
如果無法確認環境是否乾淨，而且手上有可信任的被攻擊前備份，
重新建立乾淨環境往往比一直在舊環境找後門更可靠。

8. 保留事件紀錄，作為下一次改善的依據

事件處理完成後，應保留事件時間軸、可能入侵入口、
受影響範圍、採取的修補措施及後續改善項目，
作為下一次更新與事件應變的依據，
讓資安工作能持續累積經驗值，而不是修好就結束。

WAF 有裝，網站就不會被駭嗎？

不會。
WAF 很有用，但不能代替程式更新、權限管理、安全程式開發、弱點掃描、備份、監控。

可以把 WAF 想成大樓門口的警衛，能擋掉很多奇怪的人。
但如果後門沒鎖、員工把鑰匙給別人、辦公室裡本來就藏了一個人，光靠門口警衛還是不夠。

HTTPS 有綠色鎖頭，代表網站安全嗎？

也不是。
HTTPS 代表瀏覽器與網站之間的傳輸經過加密，可以降低資料傳輸途中被竊聽或竄改的風險，
但無法避免 SQL Injection、XSS、CMS 漏洞、弱密碼、惡意 Plugin、主機漏洞。
HTTPS 是網站安全的基本條件，不是完整答案。

WordPress、Joomla 哪一個比較安全？

沒有哪個 CMS 可以用一句比較安全概括。
真正影響資安的通常是是否持續更新、Extension／Plugin 是否可信、
是否安裝過多元件、主機管理、權限、備份、
MFA、維護制度。

一個持續更新、元件精簡且有人維護的 Joomla，
通常會比一個五年沒更新、裝了 40 個 Plugin 的 WordPress 安全，反過來也是一樣。
誰在維護，以及怎麼維護，通常比 CMS 的名字更能決定安全程度。

小型企業沒有資安人員，至少先做哪幾件事？

如果預算有限，可以先做六件事：

1. CMS 與外掛更新到安全版本
2. 管理員啟用 MFA
3. 關閉不用的帳號與功能
4. 做可還原的異地備份
5. 部署基本 WAF
6. 定期弱點掃描

這六項通常比一開始直接導入昂貴 SIEM 或 SOC 更適合中小企業，
先把基本漏洞補起來，再依公司規模增加資安投入。

一般網站維護與資安維護，差在哪裡？

企業在評估網站維護方案時，經常把一般維護跟資安維護當成同一件事，
這也是後續容易產生認知落差的地方。
業界標準做法通常會把這兩種層級分開看待。

一般年度維護，通常包含什麼

一般網站年度維護，多半以固定週期為核心，
內容通常包括例行的 CMS 安全更新、擴充套件更新、備份狀態檢查，
以及一般性的網站異常檢查。
這類維護的節奏是週期性的，例如每季或每月處理一次，適合處理已知、常規性的風險。

資安維護，跟一般維護不一樣的地方

一般年度維護通常不會承諾固定時數內完成評估或修補，
實際處理時間會依漏洞影響範圍、第三方套件相容性、測試需求以及當時的工作排程來安排。

如果企業對時效性有更高要求，
例如希望在 24 小時或 48 小時內完成影響評估、提出處理方式，
或在指定時限內完成修補，這已經屬於另一種等級的服務。
這類服務需要事先預留緊急應變人力並調整排程優先順序，
跟固定週期的一般維護是不同的服務模式。

資安鑑識、入侵處理、惡意程式或後門清除，通常是在發生疑似資安事件之後才會啟動。
弱點掃描則屬於主動式安全檢查，應該在事件發生之前就定期執行，
跟事件應變是不同性質的工作。
這幾項工作因執行方式、工具與工時不同，
通常不會直接包含在一般年度網站維護中，需要依範圍另行評估。

為什麼系統商無法保證網站不存在任何未知漏洞或未來不再受到攻擊

任何 CMS，不論是 Joomla、WordPress 或其他系統，都無法保證百分之百不再遭受攻擊。
新的 CVE、新的攻擊手法、新的供應鏈風險每天都可能出現，
還沒被公開發現的漏洞，沒有廠商能夠事先預測。

系統商能做的是持續透過系統更新、備份、權限管理及主機防護把風險降低，而不是把風險完全消除。
這也是為什麼網站資安需要被當成一個持續循環來經營，而不是完成一次專案就結束。

企業網站資安 30／90／180 天改善方式

如果公司目前幾乎沒有網站資安制度，可以分階段做。

前 30 天：先知道自己有什麼

完成網站盤點、CMS／Extension 版本盤點、管理員帳號整理、
HTTPS、MFA、備份、一次基礎弱點掃描、修補已知高風險問題。

90 天：建立固定制度

開始導入固定更新週期、弱掃排程、WAF、Log 管理、
Dependency Scan、權限定期審核、事件應變流程。

180 天：把資安變成開發的一部分

較成熟的團隊可以進一步加入 SAST、DAST、SCA、
CI/CD Security Gate、SBOM、滲透測試、SIEM、資安演練。

最終目標是每個漏洞都有人發現、有人負責、有人修，
修完還有人驗證，工具數量不是重點。

資訊安全政策還需要嗎？

需要，但它與網站程式安全是不同層級。
資訊安全政策通常用來規範整個公司的資訊資產管理、帳號與權限、個資、員工責任、
外包廠商、事件通報、教育訓練、備份、營運持續。

企業可以建立自己的資訊安全政策，例如：

目的：
為保護公司資料、資訊系統、設備及網路的機密性、完整性與可用性，
降低內部及外部蓄意或非蓄意事件造成的資安風險，制定資訊安全管理政策。

基本目標：

• 維持資訊系統正常營運
• 保護資訊資產機密性、完整性與可用性
• 保護客戶與使用者資料
• 落實帳號與權限管理
• 建立資安事件通報及處理程序
• 定期進行資安教育與系統檢查

實際政策仍應依企業規模、產業及法規要求調整。

從實際資安事件看到的教訓

以下兩個案例已去除可識別身分之細節，僅保留具參考價值的處理邏輯，供企業在規劃網站資安時參考。

案例一：舊備份不能直接拿來還原

某企業網站遭遇異常之後，第一個直覺反應通常是：
有備份的話，直接把網站還原不就好了？
實務上並沒有這麼簡單。

該企業網站曾在發生異常後進行檔案、資料庫與歷史備份檢查，
原本計畫直接使用較早的資料庫備份，把遺失的文章與網站資料恢復回來。
進一步檢查後，發現部分舊備份中存在可疑惡意程式或後門相關內容，
不適合直接恢復至正式環境。
這時如果只因為備份日期比較早就直接恢復，很可能發生另一個問題：
網站恢復了，後門也一起恢復。

最後並沒有直接使用該份備份，
改以確認過的乾淨資料重新整理缺少的內容。
這個案例有一個重要觀念：

備份時間早，不代表備份一定乾淨。
假設某網站在月初已經遭到入侵，之後仍持續每日備份，
直到數週後才發現異常，那麼這段期間產生的多份備份，都可能已經包含惡意內容。
所以網站發生資安事件時，不能只問「最近一次備份是哪一天」，
還要問「大概從什麼時間開始被入侵」，
以及「哪一份備份可以確認是在入侵之前」。

這類事件還有另一個常見問題：
網站前台可能打得開、商品正常、表單正常、
首頁沒有被改掉、Google 看起來也正常，
但實際檢查可能仍發現不明 PHP、Webshell、異常管理員帳號、被修改的核心程式、
資料庫異常內容、惡意 iframe、可疑 JavaScript、不明排程或後門。
網站可以正常瀏覽，跟網站是否安全，是兩件不同的事。
這也是為什麼網站遭入侵後，不能只做前台測試。

案例二：真正的攻擊入口，不一定在網站本身

網站資安還有一個容易被忽略的問題：
網站可能沒有先出漏洞，而是管理網站的電腦先出事。

某網站曾出現異常登入與帳號安全問題，後續從登入紀錄發現，
出現異常的登入地點與頻率，且登入行為不符合管理員平時的使用習慣。
網站管理人員確認自己並沒有從那些地點或時段登入，進一步排查後，懷疑問題並不是單純來自網站 CMS，
而可能與管理端使用的網路環境或其中一台電腦遭感染有關。

處理範圍需要延伸到網站程式以外：
先暫時關閉或限制網站後台、停用可能受影響的管理員帳號、重設帳號密碼、
檢查登入紀錄、檢查可疑來源，
並要求相關電腦進行完整掃毒與安全檢查，
確認網站程式與資料庫沒有其他異常後，再重新開放後台。

這個案例說明了一個很實際的問題：
網站本身做得再安全，管理者電腦中毒仍然可能造成帳密外洩。
管理人員的電腦如果中了 Keylogger、資訊竊取型惡意程式、Remote Access Trojan、
瀏覽器 Cookie Stealer、密碼竊取工具，
攻擊者可能直接取得 CMS 帳號密碼、FTP、Email、主機帳號、
Cloudflare、Google 帳號。
這時候網站的密碼本身再複雜，也可能被直接偷走。

假設感染的電腦還沒有處理，今天改密碼、再登入一次，惡意程式可能再把新密碼偷一次。
所以帳密疑似外洩時，比較合理的順序是：
隔離設備、清除惡意程式、從乾淨設備修改密碼、撤銷舊 Session、
啟用 MFA、再恢復登入，而不是一直在可能中毒的電腦上改密碼。

從這兩個案例可以看到：企業需要的是整套處理流程

兩個案例看起來不同，一個是網站與備份可能受到污染，
一個是管理端設備與帳號可能發生問題，但最後都反映一件事：
網站資安不能只看網站程式。

完整的企業網站資安至少涉及以下範圍：

資安事件發生後，把網站更新到最新版，通常只完成其中一格。

網站資安是一個持續循環，需要長期經營

網站今天掃描沒有高風險漏洞，不代表半年後依然安全，
網站沒有改，外面的環境還是會改。
新的 CVE、CMS 漏洞、Plugin 漏洞、攻擊方式、供應鏈事件、帳密外洩，
每天都可能出現。

比較完整的網站資安循環應該是：
盤點、檢測、修補、驗證、監控、更新、再檢測。

企業真正要建立的是這個循環，
而不是買完一次弱點掃描報告就放進抽屜。

網站資安常見問題 FAQ

企業網站資安檢測與維護

企業網站資安真正困難的地方，通常在於不知道哪些元件需要更新、
不確定更新後會不會壞、掃描完不知道問題要怎麼修，
或者網站被入侵後無法判斷是否已經清乾淨，而不是單純不知道要更新。

網站維護應同時考慮程式更新、主機、備份、弱點掃描、權限、監控與事件應變。
如果企業內部沒有專職網站工程或資安人員，可以先進行網站與資安健檢，
盤點 CMS、版本、外掛、主機環境、HTTPS、
Security Header、公開服務與已知漏洞，再依風險決定優先修復順序。

如果網站核心版本已停止支援、外掛無法更新，或既有網站已經難以維護，也可以評估重新建置。可參考：企業官網與 RWD 網頁設計。

相關服務

網站建置與企業官網：品牌電商網站建置｜買斷、租用與客製整合

SEO排名及廣告投放：SEO排名及廣告投放

如需進一步進行網站資安、網站維護、弱點檢查或既有 Joomla／WordPress 網站安全評估，
可先由目前網站環境與使用版本開始盤點。