我有一個為使用者使用子網域的網域，例如：
user1.example.com
為了區分其他官方子網域和使用者子網域，我為所有此類情況保留了「at」。例如，一些官方子域是：
api.at.example.com, releases.at.example.com, support.at.example.com
我現在已經兩次遇到由於誤報網路釣魚檢測而被阻止的情況。距離谷歌和思科還很遠。他們似乎表明我的網站正在嘗試冒充“api.at”或“releases.at”。
令人煩惱的是，服務僅根據給定的相當通用的名稱來阻止沒有其他惡意活動跡象的子網域。尤其令 Cisco 煩惱的是，他們阻止 fetch/xhr 請求，而使用者無法選擇繞過。只有當您在瀏覽器中將網域作為頁面存取時，Google 至少不會阻止 fetch/xhr。
我想知道這種情況有多常見？我正在考慮保留一些第一級子網域，而不是只是為了繞過它（例如api.example.com），但有效阻止所有巢狀子網域的服務似乎很愚蠢。如果這種情況不常見，那麼我可能會嘗試向違規服務提交支持票證。
（這是一個全新的域名，沒有以前的所有者，也沒有任何惡意內容，因為我自己編寫了整個應用程式）
答案1
是的，雖然我同意這種過度封鎖造成廣泛問題的魯莽行為，但這是不限於單一實體您可以為您單獨解決這個問題。
我在我管理的桌面系統中安裝了類似的阻止規則，並已與重要的商業實體確認，他們在其設備群中強制執行此類阻止。我的規則至少僅適用於包含或類似於擁有和相關品牌名稱的網域。其他公司聲稱使用“機器學習”來確定他們的“URL 威脅分類”，在我看來，這更有可能導致您在思科遇到的情況。
這種檢測肯定是常見於電子郵件上下文- 如果您被發現轉發未經授權的郵件，您應該會立即被歸類為垃圾郵件來源<brandname>.<tld>.<otherdomain>.<tld>。
您應該審查和監控您的客戶，以免讓類似的東西bankofamerica.com.yourdomain.example被騙子利用。如果您的網域看起來像是您忽略了選擇安全性預設值，則預期會出現特別敏感的啟發式問題。我推薦你遠離任何流行的 ccTLD（例如.at）和 uTLD（例如 .com）用於您使用的標籤在中間您的較長網域。
根據您向用戶提供的服務類型，擁有該網域甚至可能是合適的新增到公共後綴列表。即使不是，請閱讀相關文檔，它可能會幫助您首先確定將用戶內容託管在也用於其他服務的網域下是否是一個好主意（提示：現在瀏覽器是複雜的野獸）。