WordPress 又被駭客入侵？遷移至 Next.js + Supabase 才是根本解決方案

您的客戶來電：他們的 WooCommerce 商店又被駭客入侵了。您上個月才清理過——移除了後門、修補了二十三個外掛、輪換了憑證。但今早他們的支付處理商標記了可疑的卡片活動。您透過 SSH 連線發現了它：一個信用卡竊取程式隱藏在一個看起來合法的分析外掛內，該外掛在週二晚上進行了自動更新。同樣的故事，不同的外掛。這個攻擊面不是 WordPress 核心的漏洞——而是他們的網站依賴的三十七個第三方外掛中的每一個都是一道門。大多數外掛更新速度很慢。有些根本不會被修補。遷移至 Next.js + Supabase 不僅僅清除感染——它移除了整個 90% 的 WordPress 漏洞源頭的外掛層。

本文並不是為了貶低 WordPress。它為網際網路的大部分提供了動力，而且有充分的理由。但是 2005 年讓它易於使用的架構，正是 2026 年讓它成為自動化攻擊磁鐵的同一個架構。如果您曾被駭客入侵——或者您厭倦了花錢購買本身就是攻擊載體的安全外掛——這是您遷移至更根本上安全的東西的遊戲計劃。

目錄

• WordPress 安全問題是架構性的
• 2026 年常見的 WordPress 攻擊載體
• 無頭架構如何消除整個攻擊類別
• Next.js + Supabase：安全第一的堆棧
• 攻擊面比較：WordPress vs 無頭
• 遷移遊戲計劃：WordPress 至 Next.js + Supabase
• 遷移後的安全強化
• WordPress 安全的真實成本 vs 遷移
• 常見問題

WordPress 安全問題是架構性的

讓我對此明確表態：WordPress 核心團隊做著紮實的安全工作。WordPress 核心，保持最新狀態，相當安全。但沒有人只運行 WordPress 核心。平均 WordPress 網站安裝了 20-30 個外掛。每一個都是您沒有編寫、由您不認識的人維護的依賴項，可以存取您的資料庫、檔案系統和您使用者的資料。

以下是在「WordPress 安全最佳實踐」文章中持續被忽視的事情：問題不在於 WordPress 網站所有者疏忽。問題在於 WordPress 的架構要求您從第三方直接在您的伺服器上安裝可執行的 PHP 程式碼以獲得基本功能。這相當於給在您房子上工作的每個承包商一份您房子鑰匙的永久複本。

WPScan 的漏洞資料庫在 2024 年追蹤了超過 7,900 個新的 WordPress 漏洞，其中外掛約佔 96%。Sucuri 的 2024 年威脅報告發現，WordPress 佔了他們清理的所有 CMS 感染的約 95%。Patchstack 報告稱，2024 年 33% 的關鍵 WordPress 漏洞在披露時沒有可用的修補程式。

這些不是可以透過更好的編碼實踐來修復的漏洞。它們是架構本身的突現特性。

2026 年常見的 WordPress 攻擊載體

在我們談論修復之前，讓我們列舉您實際上在防禦什麼。我個人已經分類了數十個被入侵的 WordPress 網站，這些攻擊落入可預測的模式。

透過外掛的 SQL 注入

WordPress 使用一個具有文檔完善的架構的 MySQL 資料庫。每個接受使用者輸入並接觸資料庫的外掛都是潛在的 SQL 注入點。$wpdb->prepare() 函數存在，但它是可選的。外掛開發者會忘記它、誤用它，或完全跳過「簡單」查詢。

我曾經追蹤過一個注入，它來自一個已被棄置 18 個月但仍然安裝在 200,000 多個網站上的聯絡表單外掛。攻擊者正在使用基於 UNION 的注入來轉儲 wp_users 表、獲取管理員密碼雜湊，並離線破解弱密碼。

-- 典型的 WordPress SQL 注入在日誌中的樣子
GET /wp-content/plugins/vulnerable-plugin/ajax.php?id=1%20UNION%20SELECT%201,user_login,user_pass,4,5%20FROM%20wp_users--

PHP 物件注入和遠端程式碼執行

WordPress 對 serialize() 和 unserialize() 的大量使用為 PHP 物件注入創造了機會。當外掛對使用者控制的資料進行反序列化（許多都這樣做）時，攻擊者可以精心製作在反序列化過程中執行任意程式碼的有效負載。

在 2024 年，一個流行備份外掛（安裝在 500 萬多個網站上）中的關鍵 RCE 漏洞允許未經認證的攻擊者執行任意 PHP 程式碼。修復花了 11 天才發布。11 天內，每個運行該外掛的網站都是一個活的靶子。

外掛供應鏈攻擊

這個最讓我害怕。攻擊者購買已棄置的具有大量安裝基礎的外掛，推送包含後門的「安全更新」，WordPress 自動更新機制將惡意軟體分發給運行該外掛的每個網站。這發生在 Display Widgets（300,000 個安裝）和 Social Warfare（70,000 個安裝）上，而這些只是被發現的。

對 wp-login.php 的暴力攻擊

每個 WordPress 網站預設都會暴露 /wp-login.php 和 /xmlrpc.php。自動機器人持續轟擊這些端點。Wordfence 報告稱在 2024 年在其網路上平均每月封鎖 30 億個惡意請求。即使有速率限制和雙因素身分驗證，您也在花費伺服器資源處理這些攻擊。

透過主題和外掛的跨網站腳本編寫 (XSS)

WordPress 中的儲存型 XSS 特別危險，因為管理員儀表板和面向公眾的網站共用相同的工作階段上下文。透過評論、表單提交或易受攻擊的外掛設定注入的 XSS 有效負載可以升級為完整的管理員存取權限。

無頭架構如何消除整個攻擊類別

這就是事情變得有趣的地方。無頭架構不僅僅減少您的攻擊面——它透過移除使它們可能的條件來消除整個攻擊類別。

在傳統的 WordPress 設定中，渲染 HTML 的伺服器也：

• 運行來自 20 多個第三方外掛的 PHP 程式碼
• 管理使用者身份驗證
• 連接到資料庫
• 提供管理介面
• 處理檔案上傳
• 處理表單提交

這對單個應用程式來說是很多責任。在具有 Next.js 和 Supabase 的無頭設定中，這些責任跨隔離的服務分散：

• 前端 (Next.js on Vercel/Netlify)： 從 CDN 提供的靜態 HTML/JS。在大多數情況下，沒有伺服器端執行時暴露給公網。
• 資料庫 + 身份驗證 (Supabase)： 託管 Postgres，具有列級安全性，永遠不會直接暴露給終端使用者。
• API 層： 無伺服器函數，具有明確的最小端點。
• CMS（如果需要）： 無頭 CMS 在自己的隔離基礎設施上運行。

沒有 PHP 可注入。沒有具有寫入權限的外掛目錄。管理員和公共網站之間沒有共用工作階段。沒有 wp-login.php 供機器人轟擊。

您不需要 WAF 來保護一個不存在的攻擊面。

Next.js + Supabase：安全第一的堆棧

讓我們具體瞭解為什麼從安全角度來看這個特定的組合效果如此好。

Next.js：不運行程式碼的前端

當您使用靜態生成 (SSG) 或增量靜態再生成 (ISR) 構建 Next.js 網站時，部署的是 CDN 上的 HTML、CSS 和 JavaScript 檔案。沒有應用程式伺服器即時處理請求。您無法對 CDN 進行 SQL 注入。

對於動態功能，Next.js 伺服器動作和路由處理程式作為無伺服器函數運行。每個函數：

• 隔離在自己的執行上下文中
• 無狀態（請求之間沒有共用記憶體）
• 短暫（冷啟動、執行、終止）
• 明確定義（沒有端點的自動發現）

// Next.js 路由處理程式 -- 明確、有型別、最小化
import { createClient } from '@/lib/supabase/server'
import { NextRequest, NextResponse } from 'next/server'
import { z } from 'zod'

const ContactSchema = z.object({
  name: z.string().min(1).max(100),
  email: z.string().email(),
  message: z.string().min(10).max(5000),
})

export async function POST(request: NextRequest) {
  const body = await request.json()
  const parsed = ContactSchema.safeParse(body)
  
  if (!parsed.success) {
    return NextResponse.json({ error: '輸入無效' }, { status: 400 })
  }
  
  const supabase = await createClient()
  const { error } = await supabase
    .from('contact_submissions')
    .insert(parsed.data)
  
  if (error) {
    return NextResponse.json({ error: '提交失敗' }, { status: 500 })
  }
  
  return NextResponse.json({ success: true })
}

將其與必須掛接到 WordPress 動作系統的 WordPress 聯絡表單外掛進行比較、包含自己的 AJAX 處理程式、管理自己的 nonce 驗證，並為「簡單」查詢構建自己的 SQL 查詢。Next.js 版本的移動部分較少、透過 Zod 驗證的輸入以及透過 Supabase 客戶端的參數化查詢。

Supabase：具有列級安全性的 Postgres

Supabase 為您提供一個託管 PostgreSQL 資料庫，具有一項殺手級安全功能：列級安全性 (RLS)。與其信任您的應用程式程式碼來強制存取控制（WordPress 模型），您在資料庫級別定義安全原則。

-- 只有經過身份驗證的使用者可以讀取自己的資料
CREATE POLICY "使用者可以查看自己的設定檔"
  ON profiles
  FOR SELECT
  USING (auth.uid() = user_id);

-- 公眾可以插入聯絡表單提交但不能讀取
CREATE POLICY "任何人都可以提交聯絡表單"
  ON contact_submissions
  FOR INSERT
  WITH CHECK (true);

CREATE POLICY "只有管理員可以讀取提交"
  ON contact_submissions
  FOR SELECT
  USING (auth.jwt() ->> 'role' = 'admin');

即使攻擊者找到了進行任意 Supabase 查詢的方式（沒有 PHP 執行上下文已經更難），RLS 原則也會阻止他們存取他們不應該看到的資料。這是 WordPress 無法根本上提供的深度防禦，因為其權限系統在 PHP 程式碼中實現，而不是在資料庫層。

Supabase 還透過對電子郵件/密碼、魔法連結、OAuth 提供者和多因素身份驗證的內建支持來處理身份驗證。不需要外掛。沒有在您的伺服器上運行的第三方程式碼。

攻擊面比較：WordPress vs 無頭

讓我們並排比較。

攻擊載體	WordPress	Next.js + Supabase
SQL 注入	高風險 -- 外掛構建原始查詢	幾乎為零 -- 透過 Supabase 客戶端的參數化查詢，RLS 作為備份
PHP/遠端程式碼執行	高風險 -- 外掛執行伺服器端 PHP	不適用 -- 沒有 PHP 執行時
外掛供應鏈	關鍵風險 -- 自動更新分發惡意軟體	不適用 -- 沒有外掛生態系統
暴力破解（登入）	始終暴露 (wp-login.php、xmlrpc.php)	透過 Supabase Auth 或單獨儀表板的管理員存取，不需要公共登入端點
XSS（儲存型）	高風險 -- 共用管理員/公共上下文	低風險 -- React 預設轉義輸出，管理員和公共是單獨的應用程式
檔案上傳利用	高風險 -- 上傳的 PHP 檔案可以執行	低風險 -- 上傳到物件儲存 (Supabase Storage/S3)，永遠不會作為程式碼執行
資料庫暴露	如果伺服器被入侵，直接 MySQL 存取	資料庫在 Supabase 的基礎設施後，RLS 原則作為最後防線
原點上的 DDoS	伺服器必須處理每個請求	CDN 上的靜態資產，原點很少被擊中
已知路徑列舉	wp-admin、wp-content、wp-includes 都可掃描	沒有可預測的路徑，沒有暴露的管理路由

遷移遊戲計劃：WordPress 至 Next.js + Supabase

好吧，您被說服了（或者您被駭客的網站說服了）。以下是您實際如何進行的方式。我們已經完成了足夠多次的遷移，以至於有了一個可重複的過程。

第 1 階段：分類和內容審計（第 1 週）

在您接觸任何程式碼之前，您需要瞭解您實際擁有什麼。

1. 使用 WP-CLI 或 REST API 匯出所有 WordPress 內容。 不要依賴 XML 匯出——它們會遺漏後設資料欄位和自訂文章類型。
2. 列舉所有由外掛提供的功能。 製作一個試算表：外掛名稱、它的功能、您是否實際需要它，以及什麼取代它。
3. 對應 URL 結構以保留 SEO。 每個現有 URL 都需要在 Next.js 中進行重新導向或匹配的路由。
4. 識別動態功能 -- 表單、搜尋、使用者帳戶、電子商務 -- 需要 API 端點。

# 透過 REST API 匯出 WordPress 內容
curl -s "https://yoursite.com/wp-json/wp/v2/posts?per_page=100&page=1" | jq '.' > posts_page1.json
curl -s "https://yoursite.com/wp-json/wp/v2/pages?per_page=100" | jq '.' > pages.json
curl -s "https://yoursite.com/wp-json/wp/v2/media?per_page=100" | jq '.' > media.json

第 2 階段：Supabase 架構和資料遷移（第 2 週）

根據內容審計設計您的 Supabase 資料庫架構。不要只是複製 WordPress 架構——它對後設資料表和序列化資料 blob 非常臃腫。

-- 乾淨、專用的架構
CREATE TABLE posts (
  id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
  title TEXT NOT NULL,
  slug TEXT UNIQUE NOT NULL,
  content TEXT,
  excerpt TEXT,
  featured_image TEXT,
  status TEXT DEFAULT 'draft' CHECK (status IN ('draft', 'published', 'archived')),
  published_at TIMESTAMPTZ,
  created_at TIMESTAMPTZ DEFAULT NOW(),
  updated_at TIMESTAMPTZ DEFAULT NOW(),
  author_id UUID REFERENCES auth.users(id)
);

-- 立即啟用 RLS
ALTER TABLE posts ENABLE ROW LEVEL SECURITY;

CREATE POLICY "已發布的文章是公開的"
  ON posts FOR SELECT
  USING (status = 'published');

CREATE POLICY "作者可以管理自己的文章"
  ON posts FOR ALL
  USING (auth.uid() = author_id);

編寫一個遷移指令碼（Node.js 或 Python），將 WordPress JSON 匯出轉換為您的新架構，並將它們插入 Supabase。

第 3 階段：Next.js 構建（第 3-5 週）

構建您的 Next.js 前端。如果您與了解堆棧的團隊合作，這會進行得很快。如果您需要幫助，我們已經進行了足夠多次的遷移，以至於對正確的模式有強烈的意見。

關鍵的架構決策：

• 內容頁面的靜態生成 -- 部落格文章、著陸頁、關於頁面。這些變成 CDN 上的 HTML 檔案。
• 動態資料的伺服器元件 -- 使用快取在請求時從 Supabase 獲取。
• 表單提交的路由處理程式 -- 聯絡表單、電子報註冊等。
• 重新導向中介軟體 -- 處理所有舊的 WordPress URL。

// next.config.ts -- 處理 WordPress URL 重新導向
const nextConfig = {
  async redirects() {
    return [
      {
        source: '/category/:slug',
        destination: '/blog/category/:slug',
        permanent: true,
      },
      {
        source: '/:year(\\d{4})/:month(\\d{2})/:slug',
        destination: '/blog/:slug',
        permanent: true,
      },
      // wp-login.php -- 將機器人發送到 410
      {
        source: '/wp-login.php',
        destination: '/gone',
        permanent: true,
      },
      {
        source: '/wp-admin/:path*',
        destination: '/gone',
        permanent: true,
      },
    ]
  },
}

第 4 階段：測試和 SEO 驗證（第 6 週）

• 對新網站運行 Screaming Frog 以驗證每個舊 URL 要麼解析要麼重新導向。
• 驗證結構化資料 (JSON-LD) 存在於所有頁面上。
• 測試所有表單和動態功能。
• 運行 Lighthouse 和核心網際網路活動指標檢查——您幾乎肯定會看到改進，因為您現在從 CDN 提供。
• 使用 Vercel Analytics 或您喜歡的工具設定監控。

第 5 階段：啟動和 DNS 轉換（第 6-7 週）

部署到 Vercel 或 Netlify，更新 DNS，並設定監控。使舊 WordPress 實例離線但在 30 天內可訪問，以防您需要參考任何內容。

如果您的網站有重大流量或電子商務功能，請考慮無頭 CMS 整合以進行內容管理，並與我們聊天Astro 作為替代前端對於內容繁重的網站，其中構建效能很重要。

遷移後的安全強化

一旦您進入新堆棧，以下是您的安全檢查清單：

1. 在每個表上啟用 Supabase RLS。 沒有例外。如果一個表沒有原則，要麼它無法訪問（好的預設），要麼完全開放（不好）。
2. 對所有機密使用環境變數。 Vercel 和 Netlify 都很好地處理這個。永遠不要提交 API 密鑰。
3. 設定 Supabase 資料庫備份。 時間點恢復在 Pro 計劃上可用（$25/月）。
4. 在 Next.js 中介軟體中配置內容安全原則標頭。
5. 啟用 Vercel 的 DDoS 保護（包含在所有計劃中）。
6. 設定正常運作時間監控 -- 我們使用 Better Uptime，但 Checkly 和 Vercel 的內建監控也可以。
7. 每季度審計您的 Supabase RLS 原則。 使用 Supabase 的 SQL 編輯器以不同的使用者上下文測試原則。

// middleware.ts -- 安全標頭
import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'

export function middleware(request: NextRequest) {
  const response = NextResponse.next()
  
  response.headers.set('X-Frame-Options', 'DENY')
  response.headers.set('X-Content-Type-Options', 'nosniff')
  response.headers.set('Referrer-Policy', 'strict-origin-when-cross-origin')
  response.headers.set(
    'Content-Security-Policy',
    "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline';"
  )
  response.headers.set(
    'Permissions-Policy',
    'camera=(), microphone=(), geolocation=()'
  )
  
  return response
}

WordPress 安全的真實成本 vs 遷移

讓我們談論金錢，因為那是實際推動決策的因素。

成本類別	WordPress（年度）	Next.js + Supabase（年度）
託管	$300-1,200（託管 WP）	$0-240（Vercel Pro）
安全外掛 (Wordfence/Sucuri)	$200-500	$0（不需要）
SSL/CDN	$0-200	$0（包括）
惡意軟體清理（如果被駭客入侵）	$500-2,500 每個事件	不適用
開發人員在安全修補上的時間	$2,000-5,000	$500-1,000
資料庫 (Supabase)	包含在託管中	$0-300（免費層至 Pro）
合計	$3,000-9,400	$500-1,540

而且這還沒有考慮停機成本、失去客戶信任，以及如果客戶資料被入侵可能的監管處罰。單一個 GDPR 可報告的漏洞可能會導致數萬元的法律和合規費用。

遷移本身通常耗資 $10,000-40,000，具體取決於網站複雜性。對於大多數業務來說，這在 1-2 年內透過減少的安全開支收回——而且您會獲得一個更快、更易於維護的網站。查看我們的定價頁面以了解遷移項目的詳細資訊。

常見問題

WordPress 真的那麼不安全，還是這被誇大了？ WordPress 核心得到很好的維護。問題是實際上沒有人只運行核心。外掛生態系統是 96% 漏洞的所在地，您無法在沒有外掛的情況下運行有用的 WordPress 網站。這沒有被誇大——Sucuri 在 2024 年清理了來自 60,000 多個 WordPress 網站的惡意軟體。該架構要求您信任您伺服器上的第三方 PHP 程式碼，而這種信任被不斷利用。

我不能只使用更好的安全外掛而不是遷移嗎？ 安全外掛本身是在您的伺服器上運行的 PHP 程式碼，具有深度系統存取。Wordfence 和 Sucuri 得到很好的維護，但它們是架構問題的創可貼。它們還增加了伺服器負載、可能與其他外掛衝突，並且多年來有過自己的漏洞。您正在添加複雜性來解決複雜性問題。

WordPress 到 Next.js 遷移通常需要多長時間？ 對於標準業務網站（10-50 頁、部落格、聯絡表單），我們通常在 5-7 週內完成遷移。具有 WooCommerce 的電子商務網站更複雜，根據產品目錄大小和自訂功能，可能需要 8-14 週。如果您有更簡單的網站，與我們聯繫，我們可以給您更具體的時間表。

從 WordPress 遷移時，我會失去 SEO 排名嗎？ 如果您正確進行，就不會。關鍵步驟是：保留所有 URL 結構或設定適當的 301 重新導向、維護結構化資料標記、保留內容完整，以及向 Google Search Console 提交更新的網站地圖。我們的大多數遷移客戶在 2-3 個月內看到排名改進，因為當您遷移到由 CDN 提供的靜態網站時，核心網際網路活動指標分數會大幅改進。

內容編輯怎麼樣？WordPress 對非技術使用者很簡單。 這是一個合法的關注。您有多個選項：Supabase 加上自訂管理儀表板，或無頭 CMS，例如 Sanity、Contentful 或 Payload CMS，為內容編輯提供類似於 WordPress 的視覺編輯體驗。我們定期進行無頭 CMS 整合，並可以為您的團隊的需求推薦正確的選項。

Supabase 對於生產使用足夠安全嗎？ Supabase 在 AWS 基礎設施上運行，具有 SOC 2 第二類合規性。底層資料庫是 PostgreSQL，具有強大的安全記錄。列級安全性原則在資料庫級別強制存取控制，這實際上比 WordPress 的基於 PHP 的權限系統更安全。Supabase 還提供時間點恢復、加密連接，以及付費計劃上的網路限制。

如果我的 WordPress 網站被駭客入侵，我需要立即幫助怎麼辦？ 首先，立即使網站離線以停止進一步的損害和資料洩漏。其次，保留取証證據（資料庫轉儲、存取日誌、檔案系統快照）。第三，不要只是清理它並將其放回去——您可能會在幾週內被重新感染。將這個事件用作遷移的催化劑。與我們的團隊聯繫，我們可以幫助進行即時分類和遷移計劃。

我是否需要一次性遷移所有內容，還是可以逐步進行？ 增量遷移是可能的，但增加了複雜性。您可以在保持 WordPress 作為無頭 CMS 後端的同時運行 Next.js 作為前端，然後完全逐步淘汰 WordPress。但是，這意味著 WordPress 在過渡期間仍在運行，仍需要安全維護。對於大多數網站，乾淨的轉換更快、更便宜，並更快地消除安全風險。