Joomla 網站安全設定步驟｜更新、備份、權限與資安防護

Joomla 網站安全設定步驟整理：核心更新、帳號權限、檔案權限、HTTPS、主機防護、備份還原、弱點掃描與 AI API 控管，掌握七大步驟降低網站被攻擊風險。

步驟 1｜Joomla 核心與外掛多久該更新一次？

版本更新是最容易被忽略、卻也是投報率最高的一件事。
Joomla 官方會針對已知漏洞釋出安全更新，攻擊者慣用的手法之一，就是掃描網路上還沒更新的舊版本站台。
核心更新可以在後台「元件＞ Joomla 更新」點擊「檢查更新」執行，熟悉命令列的團隊也可以用 php cli/joomla.php update:apply 處理。
Joomla 5.4 正式導入 Automated Core Updates 這項機制：
全新安裝的網站預設就會開啟自動核心更新，從舊版本升級上來的網站通常需要管理員自行到「系統＞全域設定＞更新設定」裡開啟，並選擇穩定版更新管道，系統不會主動幫你打開。

第三方外掛與模板不建議直接在正式站上更新。
比較穩定的做法是先在測試環境（本機、子網域或 Docker 容器）跑一次，確認相容性沒有問題再同步到正式環境。
核心與資安補丁可以維持較高頻率的檢查，第三方擴充套件則可以抓一個固定週期（例如每週）逐一檢視官方更新公告，
遇到重大漏洞公告時再提前處理，不必等到排程日。
PHP 版本的更新也常被漏掉，過舊的 PHP 版本一樣會累積安全風險，需要納入同一套檢核流程。

建議訂閱 Joomla 官方安全公告，一有新漏洞修補就能第一時間掌握，比等到擴充套件管理員跳出提示訊息更即時。

Joomla 跟 WordPress 哪個比較安全？

選 Joomla 還是 WordPress，不能只用「哪一套比較安全」一句話判斷。
兩套 CMS 近期都出現過核心層級的漏洞，真正決定網站風險的，通常是核心版本有沒有跟上、第三方擴充套件數量、更新速度、主機環境與維護制度，而不是選了哪一套系統。

2026 年 8 月 18 日，Joomla 官方一次釋出 5.4.8 與 6.1.3 版本，總共修補十項安全問題，
其中包含一項兩步驟驗證繞過（MFA Authentication Bypass）、SHTML 危險檔案上傳限制不足，以及五項與 ACL 權限檢查有關的問題，
另外還有 CORS 來源驗證與透過 schema.org 輸出觸發的 XSS。
受影響的是 5.x、6.x 系列版本，官方建議直接更新到 5.4.8 或 6.1.3。

WordPress 今年核心同樣不平靜。
2026 年 7 月 17 日，WordPress 釋出 7.0.2 緊急安全更新，
修補一項 SQL Injection，以及一項 REST API batch-route confusion 與 SQL Injection 合併後可導致遠端程式碼執行（RCE）的問題。
因為風險等級較高，WordPress 官方對受影響版本啟用了強制自動更新，接著在 8 月又陸續發布了後續的安全更新版本。

真正差異更明顯的地方在擴充套件生態。
資安廠商 Patchstack 2026 年發布、統計 2025 年資料的《State of WordPress Security in 2026》報告指出，當年新增的 WordPress 漏洞裡有 91% 出現在外掛（Plugins），核心本身只占極少數。
2026 年也出現過使用量達數十萬的外掛爆出重大漏洞：
快取外掛 Breeze Cache 被揭露一項可導致任意檔案上傳、進而遠端執行程式的漏洞，
多語系外掛 TranslatePress 則在 8 月被揭露一項可讓未登入攻擊者直接取得管理員權限的帳號接管漏洞，兩者都已釋出修補版本。

資料來源：Joomla 6.1.3 & 5.4.8 Security & Bugfix Release、WordPress 7.0.2 Security Release、Patchstack State of WordPress Security

實務上的判斷方式：
CMS 本身不是唯一風險來源。
一個只安裝少量必要擴充套件、持續更新並有完整備份的網站，通常會比裝了數十個多年沒維護外掛的網站更容易管理。
企業真正需要比較的是目前這套網站有多少攻擊面，以及有沒有人持續在維護，而不是糾結於哪一套 CMS 名稱聽起來比較安全。

Joomla 6 串接 AI 自動更新網站，會增加資安風險嗎？

Joomla 可以透過 Web Services API 與外部 AI 系統串接，讓 AI 讀取文章、建立草稿、修改內容，
或定期整理網站狀態並產生每週維運報告，API 支援文章的 GET、POST、PATCH、DELETE 並使用 Token 驗證，
另外 Joomla 也有 Scheduled Tasks，可以固定排程執行任務，從 Joomla 5.3 起還能查看排程任務的執行歷史。
但自動化程度愈高，API Token、帳號權限與操作紀錄就愈重要。

2026 年 8 月 Joomla 官方修補的十項核心安全問題裡，就包含一項 Web Services 修改端點 ACL 權限檢查不一致的漏洞（CVE-2026-71574），
影響範圍是 4.0.0 到 5.4.7、6.0.0 到 6.1.2，已在 5.4.8／6.1.3 修補。
這也說明 AI 串接網站時，不能只考慮「能不能自動做」，還要確認 Joomla 本身已完成安全更新，並依最小權限原則限制 API 可以修改的範圍。

資料來源：Joomla Security Centre：CVE-2026-71574

例如企業可以建立一套 AI 自動化流程，每週由系統讀取 Joomla 網站目前的文章、更新狀態與執行紀錄，再整理成一份網站週報，
回報近期新增了哪些內容、哪些文章被修改、網站是否有待處理項目，以及排程任務是否正常執行。

AI 每週可以回報哪些網站狀態？

實際能回報的項目取決於串接哪些資料來源。
單純串接 Joomla，就可以整理文章新增與修改狀況、排程任務執行結果及網站內容變化；
如果另外串接主機監控、Google Search Console、GA4 或弱點掃描工具，則可以再加入 SEO、流量與資安資料。

真正該控制的，是 AI 拿到多少網站權限

AI 串接本身不代表網站一定會變得不安全，真正需要控制的是 API 權限。
如果直接把最高權限的 Joomla API Token 交給自動化系統，一旦 Token 外洩、第三方服務遭入侵，
或 AI 執行了錯誤指令，攻擊者可能利用相同權限修改網站內容，甚至影響其他網站設定。

比較穩定的做法，是不要直接使用 Super User 帳號建立給 AI 使用的 API Token，
而是另外建立專用帳號，只開放真正需要的權限。
例如 AI 只需要產生文章，就只允許建立及修改指定分類的文章，不應同時取得使用者管理、系統設定或刪除網站資料的權限。

Joomla 串 AI 時建議至少做到這 8 項安全限制

哪些事情適合交給 AI 自動做？哪些最好保留人工確認？

實務上比較安全的做法，是讓 AI 可以看、可以整理、可以提出修改，但高風險操作不能直接放行。
例如 AI 每週自動產生網站健康報告沒有太大問題；
如果要修改文章，可以先建立草稿，再由人員確認。
至於 Joomla 核心升級、外掛安裝、會員權限或主機設定，仍建議保留人工審核。

步驟 2｜管理員帳號與權限要怎麼設定才安全？

管理員帳號外洩或遭暴力破解，是 Joomla 網站常見的入侵入口之一。
第一步是盤點「使用者＞管理」裡的帳號清單，把超級管理員（Super User）人數壓到最低，通常一到兩名即可，其他協作者用一般管理員或編輯權限即可完成日常工作，這是最小權限原則的具體做法。
如果網站仍沿用早期常見的「admin」管理員帳號，建議建立新的管理帳號並停用舊帳號，不要長期使用容易被猜測的帳號名稱。
密碼也不要沿用初始設定。

密碼政策可以在「使用者＞管理＞選項＞密碼選項」裡設定最小長度（建議 12 碼以上）並要求混合大小寫與數字。
更關鍵的一步是啟用內建的兩步驟驗證，在「使用者＞多重驗證」裡開啟 Google Authenticator 或 YubiKey 等方式，讓即使密碼外洩，攻擊者也無法單靠密碼登入後台。
對於已離職或不再使用的帳號，發現後應該立即停用，不要留著「之後再處理」。

「系統＞使用者操作日誌」這項內建功能經常被忽略，開啟之後可以完整記錄誰在什麼時間執行了哪些後台操作，
包含登入、擴充套件安裝、文章刪除等敏感行為。
定期匯出檢視，遇到異常登入時間或操作紀錄，能及早察覺帳號是否已經外洩。

步驟 3｜檔案與目錄權限該設成多少才對？

檔案權限設定過鬆與過嚴都會出問題。
過鬆（例如 777）代表任何取得存取權的人都能直接寫入或執行檔案，等於幫攻擊者開了後門；
過嚴則會讓 Joomla 本身或某些擴充套件因為讀寫不到必要的目錄而無法正常運作。
Linux 環境下比較穩定的做法是把檔案設為 644、目錄設為 755

設定完成後，記得確認檔案擁有者與網頁伺服器實際執行的使用者一致。
共享主機、cPanel、Plesk、PHP-FPM 各自的執行帳號可能不同，不建議套用同一組 chown -R www-data:www-data 指令了事，
正確做法是先跟主機商或系統管理員確認目前 Web Server／PHP 是用哪個帳號在跑，
再依實際情況調整檔案擁有者與群組。
像 configuration.php 這類存放資料庫連線資訊的檔案，可以視情況調得更嚴，
但要先確認網頁伺服器仍具備讀取權限，否則網站會直接打不開。
使用 Windows／IIS 主機的團隊，則需要透過 icacls 或檔案總管，確保應用程式池使用者對 logs、tmp、cache 等目錄有讀寫權限，其餘檔案則只給讀取權限即可。

權限設定不是做一次就結束，每次安裝新擴充套件或執行系統更新後，都建議重新檢查一次，
因為部分安裝流程會暫時放寬權限來完成安裝，事後如果沒有調回，就會變成長期存在的漏洞。

步驟 4｜HTTPS 與 SSL 憑證要怎麼正確設定？

沒有加密的傳輸通道，等於讓登入資訊、表單內容與 Cookie 都用明碼在網路上跑，中間人可以直接攔截竄改。
憑證可以選擇免費的 Let's Encrypt，
Linux 主機透過 Certbot 就能自動化簽發與續期，例如 sudo certbot --nginx -d example.com。
憑證安裝完成後，記得回到 Joomla 後台「系統＞全域設定＞伺服器」，把「強制使用 HTTPS」設定為「整個網站」，避免部分頁面仍以 HTTP 開啟。

Let's Encrypt 憑證效期只有 90 天，建議寫一支 cron job 定期執行 certbot renew並先用 --dry-run 測試流程是否順暢，
避免自動化流程故障導致憑證過期卻沒人發現。
啟用 HSTS（嚴格傳輸安全）可以在 .htaccess加入：

Header set Strict-Transport-Security "max-age=31536000; includeSubDomains"

第一次設定 HSTS 建議從很短的 max-age 開始（例如幾分鐘或一天），確認全站都能穩定用 HTTPS 開啟後，
再逐步拉長到數週、數月，最後才考慮拉到一年以上，
因為設定錯誤會導致瀏覽器在效期內持續拒絕連線，修正起來比較麻煩。
includeSubDomains 這個參數只能在確定所有子網域都已經有正確的 HTTPS 憑證時才加上去，
否則還沒上 HTTPS 的子網域會直接連不上。
伺服器端也建議把最低支援版本調到 TLS 1.2 以上，停用 SSLv3、TLS 1.0／1.1，可以參考 Mozilla 提供的 SSL 設定產生器取得對應的 Apache 或 Nginx 設定範例。
設定完成後，用 SSL Labs 之類的線上工具測一次評等，掌握目前的加密強度落在哪個等級。

步驟 5｜主機與伺服器層還要做哪些防護？

網站層的設定再仔細，如果主機本身對外開放過多通訊埠，一樣會被掃描與滲透。
防火牆規則應該只保留必要的連線，例如網站用的 80／443，以及限定來源 IP 的 SSH 或遠端桌面連線埠。
Linux 主機可以用 UFW 或 iptables 管理規則，Windows 主機則透過內建防火牆處理。

有預算的團隊可以再加一層 Web 應用防火牆（WAF），
無論是 Cloudflare、Sucuri 這類雲端服務，或是在 Apache／Nginx 上啟用 ModSecurity 搭配 OWASP 核心規則庫，
都能過濾掉常見的 SQL 注入、跨站攻擊請求，
但要留意誤判狀況，定期檢查阻擋紀錄。
PHP 環境設定也值得花時間調整。
exec、system<、shell_exec 這類函數不建議看到就一律關閉，部分擴充套件（例如產生 PDF、處理圖片、呼叫外部工具）可能真的有使用需求，
硬是關閉反而會讓正常功能一起壞掉。
比較好的做法是先確認網站本身與正在使用的擴充套件是否真的需要這些函數，
確認沒有使用需求的再依主機環境限制停用。
expose_php、display_errors 這兩項則建議直接關閉，避免版本資訊與錯誤訊息外洩給攻擊者當情資，
並用 open_basedir 限制 PHP 腳本只能存取指定目錄。

目錄列表功能（Apache 的 Options -Indexes）建議關閉，避免有心人直接瀏覽整個資料夾結構。
條件允許的話，把 Joomla 應用程式與資料庫用容器或不同系統使用者隔離，能降低單一站點被攻破時波及其他服務的風險。
除了應用層備份，也建議搭配主機層的快照機制，作為系統遭遇勒索軟體或硬體故障時的另一道復原路徑，快照檔案同樣要存放在與主要伺服器不同的位置。
這部分若不確定如何規劃，可以參考主機代管服務的既有防護架構作為對照。

步驟 6｜備份與還原機制要怎麼規劃？

備份是最後一道防線，卻也是最常被「先做了再說」、卻從沒驗證過是否真的能還原的一環。
資料庫建議每天備份，網站檔案至少每週做一次完整備份，重大更新（例如核心版本升級）前，
無論如何都要先手動跑一次完整備份再動手。

備份檔案不建議只存在主機本機，一旦主機遭到攻擊或硬碟損毀，本地備份也會一併遺失。
比較好的做法是把備份同步到異地或雲端空間，Joomla 擴充套件 Akeeba Backup 內建支援 Amazon S3、Dropbox 等雲端儲存，
Linux 環境也可以搭配 rclone 或 scp 自行寫排程腳本，例如：

mysqldump -u backup_user -p joomla_db > /backup/db-$(date +%F).sql
tar czf /backup/site-$(date +%F).tar.gz /var/www/joomla

密碼不建議直接寫在指令列上（像 -pPassword 這種寫法），因為它可能留在 shell history 或執行中的程序資訊裡被其他使用者看到，
改用 -p 讓系統跳出提示再輸入密碼比較安全；
backup_user 也建議是一組只有備份權限的資料庫帳號，不要直接用 root。

企業網站可以用 3-2-1 原則規劃備份：
至少保留 3 份資料、使用 2 種不同儲存媒介，其中 1 份存放在不同主機或異地環境。
比起單純規定「保留幾個版本」，這種方式更能避免主機故障、帳號遭入侵或勒索軟體同時破壞正式站與備份。
更容易被忽略的是還原測試：
備份檔案存在，不代表真的能順利還原。
建議每個月挑一次時間，在測試環境用 Akeeba Kickstart 或 phpMyAdmin 實際跑一次還原流程，確認 configuration.php 的資料庫連線設定正確、網站功能（登入、表單送出、金流測試環境等）都能正常運作，
只有真正還原成功過一次，才能確定這套備份機制在需要的時候真的派得上用場。

網站已經被駭了，第一時間要做什麼？

如果已經出現首頁被竄改、大量垃圾頁面、陌生管理員帳號、異常寄信或主機 CPU 長時間滿載，
不建議先急著逐一刪除可疑檔案，因為只處理表面症狀，真正的漏洞入口如果還在，攻擊者很快就可能再次進入。

實務上會先保存日誌與現況資料，再限制外部存取或將網站切換至維護狀態，
確認 Joomla 核心、擴充套件、管理員帳號及主機是否存在已知漏洞。
接著更換管理員、FTP／SFTP、主機、資料庫與相關 API 憑證，清除後門與惡意檔案，再從確認乾淨的備份還原。

網站恢復後還要再次進行弱點掃描、檔案比對與日誌檢查。
如果沒有查出最初的入侵原因，只把網站還原上線，通常只能算恢復畫面，不能算真正完成事件處理。

步驟 7｜弱點掃描與入侵偵測要怎麼執行？

更新、權限、備份都做好之後，還需要主動找出還沒被發現的弱點，
並在攻擊發生的當下及早察覺，而不是等到網站掛掉才知道出事。
實務上比跑掃描器更該先做的一步，是回頭查核 Joomla 官方 Security Centre 的安全公告，
以及官方維護的 Vulnerable Extensions List（VEL），
確認核心版本與目前正在使用的擴充套件是否在已知有漏洞的名單上，這一步通常比跑任何掃描器都更直接。

查核完官方名單，再用 OWASP 維護的 JoomScan 針對 Joomla 核心與常見元件掃描已知漏洞；
一般網站等級的弱點測試則可以搭配 OWASP ZAP 或 Nikto，針對 SQL 注入、跨站攻擊等常見手法測試。
掃描完成後，報告裡列出的高風險項目要優先處理，不要只是存檔備查。

日誌監控同樣重要。
Fail2Ban 可以根據重複登入失敗的紀錄自動封鎖來源 IP，對於後台登入頁面被暴力破解的情境特別有效；
Wazuh、OSSEC 這類主機型入侵偵測工具，則能監控檔案異動與系統層級的異常事件。
伺服器的 Access Log、Error Log，以及 Joomla「系統＞全域設定」中指定 Log Path 內的日誌，也值得定期抽查，大量集中出現的 404 或 500 錯誤，經常是掃描攻擊留下的痕跡。

有哪些外掛工具可以協助強化 Joomla 安全？

工具本身不會取代前面幾項設定，但能減少大量手動操作的時間，
以下整理幾個較常見的選項，實際採用前建議先閱讀官方文件確認版本相容性。

企業網站資安可以怎麼分階段執行？

不同規模的網站，需要的時間差異很大。
單純版本盤點與基礎設定，可能數小時到數天就能完成；
如果包含版本升級、主機環境調整、異地備份、WAF、弱點掃描與事件應變流程的建置，就比較適合拆成數週逐步完成，而不是急著一次到位。
以下是一套分階段參考順序，實際天數請依網站規模與現況調整。

有沒有現成的檢查清單？

大家還會問哪些問題？