Defaults.Exposed › 報告

錯誤配置名人堂：Web 上最離奇的安全記錄（2026）

發布於 2026-06-29

數據截至 2026-06-29 · 方法論 v7。 涵蓋 261 百萬個已評級域名的彙總普查數據。下方每個數字都是真實、反覆出現的模式——並非一次性個案。參見我們如何評級。

大多數安全失誤都很無聊：某個設置沒有開啟。少數則確實令人發笑——相當於把樓交付出去時窗戶上還掛著「在此插入租戶名稱」的牌子的數字化版本。 我們評級了 261 百萬個域名；以下是讓我們看了兩遍的紀錄。

1. 沒人改名的證書

當你使用 OpenSSL 的默認提示生成 TLS 證書並直接按回車時，組織名稱會變成一個佔位符。這些佔位符本應在上線前被替換。但它們沒有：

「Internet Widgits Pty Ltd」 是 OpenSSL 示例配置中字面意義上的默認值——而 244,468 個公開站點正在提供蓋著這個名字的證書。在所有明顯的佔位符和默認名稱中，685,732 個站點從未更換那塊牌子。它們每一個還都是自簽名的，因此訪問者會收到瀏覽器警告——它們同時提供了佔位符和錯誤。

2. DMARC，迷失在翻譯中

DMARC 策略只有在它準確寫為 p=none、p=quarantine 或 p=reject 時才有效。48,648 個域名發佈了其他內容——策略詞拼寫錯誤，或者完全用另一種語言書寫（實時數據中包含「none」的西班牙語、法語和葡萄牙語寫法）。意圖是對的；確切拼寫卻不對——而 DMARC 只接受英文關鍵詞，所以它們全都提供零保護。（包含計數的完整最新列表：互聯網上最常見的 DMARC 拼寫錯誤。）

3. SPF 的歡迎門墊

SPF 的全部職責就是說明哪些服務器可以代表你發送郵件。36,014 個域名以 +all 結束其記錄——這意味著恰恰相反：「互聯網上的任何服務器都被授權以我的名義發送。」 這相當於把鑰匙用膠帶粘在門上的安全做法。另有 7,958 個域名因超出 10 次 DNS 查詢的限制而悄悄破壞了它們的 SPF，使其完全失效。（更多：SPF 錯誤配置報告。）

4. 榮譽提名：數百萬的自簽名

除了那些好笑的名字之外，3,378,080 個站點提供自簽名證書——一種它們頒發給自己、而瀏覽器拒絕接受的證書。通常是一臺路由器、一臺測試機，或一個意外被指向公共互聯網、卻從未獲得真正證書的內部工具。

這些好笑的案例有什麼共同點

這裡的每一條都與那些無聊的失誤有著相同的根本原因：一個未觸碰的默認值、一個被跳過的步驟、一次未完成的複製粘貼。網絡不會戲劇性地失敗——它因慣性而失敗，一次一個未改名的佔位符。好的一面是：其中每一個都是五分鐘就能搞定的修復。

常見問題

為什麼這麼多證書寫著「Internet Widgits Pty Ltd」？ 這是 OpenSSL 示例配置中的默認組織名稱。當某人生成證書並接受默認值時，那個佔位符就會出現在在線證書上。244,468 個公開站點從未更改它。

用另一種語言寫的 DMARC 策略有任何作用嗎？ 沒有。DMARC 只識別確切的關鍵詞 none、quarantine 和 reject。策略詞拼寫錯誤或用另一種語言書寫的記錄是無效的，會被忽略——該域名仍然可被冒充。

SPF +all 有什麼作用？ 它授權互聯網上的每一臺服務器以你的域名發送郵件——比根本沒有 SPF 還糟糕。36,014 個域名有這個設置，幾乎總是出於失誤。

這些是罕見的邊緣情況嗎？ 不是——每一個都涉及數十萬到數百萬個域名，在 261 百萬個域名的普查中被一致地發現。它們是常見的默認值，而非離奇的意外。

確保你的域名不會出現在下一期中

其中大多數都是一行就能搞定的修復。私密且免費地檢查你的域名——以互聯網看到它們的方式查看你的證書、DMARC 和 SPF。

檢查你的域名 → · DMARC 拼寫錯誤 → · SPF 錯誤配置報告 → · 證書錯誤報告 → · 僅限彙總數據。數據存儲和處理在歐盟境內進行。