TL;DR

如果您要雇用氛圍編碼員，請三思而後行，以免為時已晚。這篇文章並不是要貶低 Dioxus；這是為了提高人們對現代軟體工程脆弱性的認識，特別是當缺乏經驗的開發人員使用強大的工具時。始終聘請具有適當經驗的工程師，特別是在全端開發等關鍵領域工作時。氛圍編碼本身並不壞，但如果交給錯誤的人，它就會變成一種危險的做法。

介紹

大家好👋！

今天，我想與大家分享一種深深的挫敗感，一種在兩個不眠週末積累起來的強烈不滿，試圖報告和解釋 Rust 生態系統中一個知名且公開的開源專案Dioxus 的多個安全漏洞。對於那些不熟悉的人來說，Dioxus 是一個現代的 Rust 全端 UI 框架，它的承諾是巨大的。它旨在提供我們期望從 JavaScript 生態系統中獲得的那種無縫開發體驗，但由 Rust 的記憶體安全和類型系統提供支援。雖然它的目標令人欽佩，其開發人員也顯然充滿熱情，但我所遇到的情況暴露了現代「快速行動，打破常規」思維模式的陰暗面，這種思維模式甚至滲透到了我們最強大、理論上最安全的生態系統中。

這篇部落格文章不僅反映了 Dioxus 本身，也反映了我所說的「氛圍編碼」所導致的軟體工程實踐的整體退化。這並不是對 Dioxus 這項工具或其創造者個人的攻擊。相反，這是一份呼籲業界認真對待安全的請願書。 Dioxus 只是一個案例研究，一個優先考慮開發人員體驗和炒作而忽略安全工程原則的危險的具體例子。在任何人採取防禦措施之前，請先理解：如果用不眠之夜、編寫的數百萬行程式碼和實際使用的真實系統來衡量經驗，我已經在這個領域工作多年，並且我已經處理過真正的安全威脅。這不是我第一次這樣做。

這個標題確實具有挑釁性，但它也是字面上的意思。 Vibe 編碼正在摧毀軟體工程的根本基礎：精確性、責任感、可靠性、安全性。我完全理解產品經理和投資者對你快速交付的迫切要求。我在壓力下交付了程式碼。我已經處理了“為什麼還沒有完成？”光束。但這些都不能成為忽視基本面的理由。我們不是在建立 TikTok 過濾器，而是在建立處理真實資料、影響真實用戶並在某些情況下控制真實世界基礎設施的軟體。不惜一切代價進行最低限度檢查的運輸文化不僅是不負責任的，而且是危險的。

這篇文章將帶您了解過去兩週在 Dioxus 中發現的多個安全漏洞。它將解釋如何透過適當的工程實踐來避免這些問題，以及為什麼氛圍編碼（開發人員更關心編寫程式碼的美感或「感覺」而不是理解底層系統）會導致系統故障。是的，雖然一些 Dioxus 維護者可能聲稱這些不是“安全問題”，但安全軟體設計原則要求我們這樣對待它們。

什麼是軟體工程師/開發人員？

在我們討論複雜的內容之前，讓我們先澄清一些業界經常互換使用但不應該互換的術語。軟體工程師與開發人員有著根本的不同。雖然兩者都編寫程式碼，但兩人的責任和思考方式卻截然不同。軟體工程師是能夠根據第一原理設計系統的人。他們了解記憶體模型、設計限制、威脅面、效能瓶頸和可擴展性權衡。他們不僅編寫程式碼，還建立強大、可維護且安全的系統，以優化的方式解決現實世界的問題。

另一方面，軟體開發人員通常專注於在這些系統範圍內進行建置。他們可能負責加入功能、修復錯誤、調整效能，甚至只是在前端介面中連接 API。身為開發人員本身並沒有什麼錯。但混淆兩者會導致期望不匹配，尤其是在招募流程或開源社群中，貢獻會影響成千上萬的用戶。

為什麼在有關 Dioxus 和氛圍編碼的帖子中這種區別很重要？因為 Dioxus 與許多現代框架一樣，抽象化了許多複雜性，這使得它對新手或可能不了解其行為後果的開發人員非常有吸引力。這種抽象本身並不是邪惡的。事實上，精心設計的抽像是優秀工程的基石之一。但是，當這些抽象概念被交給那些不完全理解他們所編寫程式碼的含義的人時，特別是像 Rust 這樣的系統語言，我們就會得到不安全的軟體。

軟體工程師不僅要對他們編寫的程式碼負責，還要對該程式碼在生產中產生的後果負責。當類型系統被繞過時，當不受信任的輸入未經驗證就被處理時，當不安全的程式碼在沒有適當的理由和邊界檢查的情況下被引入時，這並不是判斷上的一時失誤。這是設計責任的系統性失敗。這就是氛圍編碼所能實現的功能。

最終，應用程式的安全性和完整性掌握在其背後的工程師手中。如果出現問題，僅僅指責「框架」或「社群」是不夠的。工程師必須承擔責任。因此，如果一個工具鼓勵不安全的模式或未能強制執行良好的實踐，這不僅僅是開發人員的問題，而是工程文化、文件和設計的失敗。這就是 Dioxus 作為案例研究具有說明意義的地方。

什麼是 Vibe 編碼？

現在讓我們花一點時間來定義這個核心概念：氛圍編碼。氛圍編碼是一種基於「感覺」而非理解的程式行為。開發人員將他們在文件、StackOverflow 或 AI 產生的輸出中看到的程式碼片段組合在一起，而不了解系統的內部結構。它將你的框架或語言視為一個神奇的黑盒子，向其提供輸入，希望得到正確的輸出，並假設「如果它編譯成功，那麼它可能就沒問題」。

氛圍編碼在系統程式設計中尤其危險。 Rust 等語言旨在透過嚴格的編譯時保證來確保安全性。但是，如果您故意（或無知地）繞過這些保證，即使是 Rust 也無法保護您的系統。不安全的區塊、動態插件系統、字串類型的 API，所有這些都是在沒有理解的情況下連接時出現微妙、危險的錯誤的機會。

當有人在 React 中編寫 UI 程式碼時，最糟糕的情況可能是按鈕損壞或 div 未對齊。當有人使用不安全的函數指標、易受 CSRF 攻擊的 API 或易受 SSRF 攻擊的靜態網站產生對 Dioxus 中的伺服器功能進行氛圍編碼時，後果會迅速加劇。然而，由於現代框架適應開發人員的人體工學，它們並不總是促使開發人員採用安全或合理的模式。他們優先考慮速度、簡單和快樂。但程式設計的樂趣不應該以犧牲紀律為代價。

這引出了一個重要的問題：當軟體故障時，誰負責？編寫該程式碼的開發人員是誰？鼓勵它的框架是什麼？執行時檢測失敗？事實上，所有人都應承擔部分責任。但最大的責任還是落在了寫程式的人身上。因為機器不會寫你的軟體。它僅僅執行它。無論 LLM 變得多麼先進，或者我們的開發工具感覺多麼“神奇”，人類仍然處於循環之中。

這不僅僅是一個哲學討論。它具有現實世界的意義，正如下一節將要展示的。因為在兩個週末的時間裡，我深入研究了 Dioxus 的內部結構，不是以普通用戶的身份，而是以軟體工程師的身份，致力於打開它並看看其內部隱藏著什麼。我發現的情況令人不安。我的舉報遭到了駁回。我了解到，我們正夢遊般地進入一個由不知道自己在建構什麼的開發人員所建構的不安全軟體的新時代。

駭客狄奧克薩斯

我已經全職使用 Dioxus 超過 7 個月了。不是被動的。不是玩具。我已經在生產系統中使用它，建立了全端應用程式，與 WebAssembly 集成，部署到雲端環境，並嘗試了伺服器端渲染和靜態生成。我的回饋不是來自摩擦，而是來自個人熟悉。我在對其程式碼庫進行深入審核時發現的問題應該引起任何使用或為該專案做出貢獻的人的注意。

讓我們從第一個漏洞開始： Link元件中的 Open Redirect 。

開放重定向漏洞

此問題已在此報告。這聽起來可能微不足道，但影響卻不容小覷。 Dioxus Link元件目前接受任意字串作為to參數。這意味著開發人員可以編寫如下內容：

Link { to: "https://some-malicious-website.com" }

維護人員認為這很好，由開發人員決定是否進行內部連結或外部連結。但這裡有一個問題： Link元件是 Dioxus 路由器的一部分，用於內部導航。它用於管理應用程式內路由、維護客戶端歷史記錄並提供無需重新載入整個頁面的無縫使用者體驗。透過此元件允許任意外部 URL 會破壞開發人員和路由器系統之間的信任契約。它模糊了內部路由和外部重定向之間的界限，從而導致網路釣魚和重定向攻擊媒介。

將其與Yew進行比較，後者是一個可以正確執行此操作的 Rust 框架。 Yew 的Link元件僅接受來自Routable枚舉的值。這強制編譯時保證路由有效且內部。您不能意外傳遞使用者控制的字串並將其重定向到惡意網站。這就是類型安全。這是 Rust 的承諾。而這正是 Dioxus 所打破的。

因此，當我將此歸類為漏洞時，我並不是吹毛求疵。我主張 Dioxus 尊重 Rust 的理念：盡可能在編譯時防止錯誤。但維護人員不同意。其中一人甚至輕蔑地表示，「這不是一個安全漏洞，聲稱它是安全漏洞簡直荒謬。」這種語氣不僅不專業，而且很危險。它不鼓勵負責任的披露。它打擊了開源安全文化。但這種說法完全沒有抓到重點。

我提出了一個簡單的解決方案：如果使用者想要連結到外部網站，請使用標準 HTML a ：

a { href: "https://google.com" }

如果使用者想要應用程式內路由，請使用：

Link { to: Route::Home }

這確保了類型安全、關注點分離和更好的 DX ，同時又不損害安全性。雙贏。但維護人員不感興趣。也許是因為這個修復不夠「有氣氛」。

伺服器函數中的 CSRF

讓我們先分析一下 CSRF 在技術層面上的工作原理，以及為什麼當它在伺服器端 API（尤其是透過 Web 為前端客戶端提供服務的 API）中沒有得到適當緩解時，它會成為一個嚴重的威脅。跨站請求偽造是一種眾所周知且危險的攻擊形式，攻擊者誘騙使用者在目前已驗證身分的 Web 應用程式上執行不必要的操作。這些操作可以包括更改帳戶設定、提交資料，甚至進行金融交易。核心漏洞源自於瀏覽器會自動將 cookie 附加到請求中，包括身份驗證令牌和會話 cookie，如果驗證不正確，受害者的身份驗證狀態就會被利用。在這種情況下，Dioxus 的伺服器功能旨在為開發人員提供友善的非同步 API，具有自動序列化和路由功能，但缺乏內建的 CSRF 保護，這使開發人員處於無法保證預設安全的危險境地。

當我提出#[with_csrf]巨集時，它不僅僅是為了語法糖或便利性，而是為了讓 Dioxus 堆疊與安全預設原則保持一致，這是 Rust 語言及其生態系統引以為傲的。 Rust 的核心理念是圍繞著安全性和正確性。當我們將正確性的負擔完全轉移到開發人員身上時，我們就違背了那個隱含的承諾。我們以Next.js之類的框架為例。儘管Next.js是用 JavaScript（一種出了名的寬鬆且不安全的語言）編寫的，但它仍然不遺餘力地鼓勵使用CSRF令牌，並提供中間件和實用程式來減少此類疏忽的可能性。在我看來，由於 Dioxus 不直接管理會話或身份驗證，因此它不應該對 CSRF 負責，這種說法是不夠的。提供像 CSRF 令牌這樣的安全原語應該是任何現代全端 Web 框架提供的最低限度的功能，這並不是要求一個功能；這是關於互聯世界中的基礎安全，在這個世界中，網絡利用是常態，而不是例外。

此外，從開發人員體驗的角度來看，引入#[with_csrf]程式巨集幾乎不會增加額外的認知開銷，但卻大大提高了伺服器功能免受 CSRF 攻擊的可能性。所提出的實作可以輕鬆檢查請求標頭中的有效X-CSRF-Token ，並根據簽署的會話令牌對其進行驗證。這與Django和Laravel等流行框架多年來所做的類似。這是一個經過實戰檢驗的模式。我所要求的不是新的或革命性的，而是標準的、成熟的和安全的。 Rust 的獨特之處在於它允許我們在編譯時透過強型別檢查完成所有這些操作，最大限度地減少人為錯誤的空間。

現在，當我提出這個問題時，我遇到的反駁是，普遍強制使用 CSRF 令牌會限制有效的用例，例如從未經身份驗證的 API 或外部用戶端呼叫伺服器功能。是的，從技術上來說確實如此，但這正是我建議將其變成選擇加入系統的原因。這不是要在全球範圍內強制執行行為，而是要讓開發人員選擇具有最小摩擦的安全路徑。如果您正在建立一個不需要擔心 CSRF 的應用程式，那麼您只需不加入巨集即可。如果您正在建立處理表單、使用者輸入、帳戶管理或任何遠端敏感內容的應用程式，您可以將#[with_csrf]放在伺服器功能之上，然後放心地繼續。這怎麼會是個糟糕的權衡呢？

Dioxus 團隊似乎也致力於保持框架的輕盈性和開發人員友善性，對此我非常尊重。事實上，我很欽佩在路由器、伺服器功能和 CLI 工具方面所付出的努力。然而，友好不應該以犧牲安全為代價。即使我們假設大多數開發人員都很聰明並且具有安全意識，我們也不能假設每個開發人員都是如此。安全性必須是萬無一失的，這並不是因為我們認為開發人員是白痴，而是因為風險太高了。忘記 CSRF 令牌不是一個學術問題；這可能是一次公關災難或資料外洩。在當今高度互聯的世界中，一次資料外洩就足以失去用戶信任、投資人信心，有時甚至會失去GDPR或CCPA的法律依據。

如果 Dioxus 維護者擔心保持宏系統的清晰度，那麼有幾種方法可以改進這一點。如果使用不當，巨集可能會發出編譯時警告。我們甚至可以產生伺服器日誌，解釋 CSRF 系統在偵錯模式下執行時所做的事情。更好的是，我們可以允許使用者在更高層級配置 CSRF 策略，例如ServerConfig::enable_csrf_protection(true)這使得每個伺服器功能預設都具有 CSRF 感知能力，除非明確選擇退出。我們可以遵循十幾種合理、符合人體工學的設計路徑來實現這一目標，而這些路徑都不會降低開發人員的體驗。

我想再次強調，這不僅僅與 Dioxus 有關。 Rust 生態系統需要就安全人體工學進行更廣泛的討論。我們在零成本抽象、安全並發和資料競爭預防方面已經取得了出色的成績，但在全端領域，網路安全仍然感覺像是二等公民。諸如axum 、 actix和warp之類的庫具有由第三方維護的 CSRF 中間件。這種分裂對生態系統不利，並使新開發人員更難遵循最佳實踐。像 Dioxus 這樣的現代全端 Web 框架是展示領導力和建立開箱即用的安全預設設定的最佳場所。它為其他圖書館樹立了良好的先例。

我見過太多開發人員將 CSRF 視為“不是他們的問題”，最終卻在他們的應用程式受到攻擊後才進行損害控制。十年前，這是可以原諒的。但今天，情況並非如此。因此，讓我向所有讀到這篇文章的人大聲而清楚地說出來：如果您的應用程式處理用戶輸入、身份驗證或敏感資料，而您沒有保護您的伺服器功能免受 CSRF 攻擊，那麼您就交付了一個易受攻擊的應用程式。無論您使用的是 Rust、Brainfuck 還是 Haskell 都沒關係。安全性與語言無關。我們早就應該停止為不安全的預設設定找藉口，只因為它們使得入職變得更容易。

任意函數指標 Transmute 導致的 DoS 攻擊

下一個問題可能是我在探索 Dioxus 全端伺服器執行時內部時遇到的最突出、技術上最令人震驚的漏洞之一。具體來說，它涉及在開發模式下的熱重載操作期間使用不安全的 Rust 程式碼來轉換原始函數指標。相關程式碼位於熱重載路徑中，涉及以下行：

let new_root = unsafe {
    std::mem::transmute::<*const (), fn() -> Element>(new_root_addr)
};

乍一看，普通觀察者可能看不出這為什麼是個問題，特別是因為這段程式碼被明確標記為開發熱重載基礎設施的一部分。但是任何具有系統程式設計經驗的人，或任何曾經被 C 或 C++ 中的未定義行為所困擾的人，都應該立即看到這裡的危險信號。將原始指標轉換為函數指標是典型的危險舉動，除非您絕對確定指標有效且正確對齊。在這種情況下，假設熱重載系統可以盲目接受透過載入器提供的任何記憶體位址並像呼叫適當的函數一樣呼叫它。這只會導致分段錯誤，甚至更糟。

事實也確實如此。如果引入了無效或格式錯誤的函數指標（無論是有意還是無意），都會導致執行時間崩潰。您可以透過向重新載入系統發送一個虛假指標來輕鬆重現此問題，從而導致整個 Dioxus 全端伺服器出現段錯誤。這不僅僅是一個錯誤。它是一種可武器化的 DoS 載體，尤其是當攻擊者可以影響插件載入系統時。儘管維護人員正確地指出這只會影響開發版本，但我們不能忽視其影響：執行熱重載工具的開發人員現在面臨著因格式錯誤的輸入而導致其開發伺服器崩潰的風險。更重要的是，這種未經檢查的不安全邏輯傳達了有關高級框架中的 Rust 安全實踐的錯誤訊息。

讓我明確一點：在 Rust 中使用unsafe有時是不可避免的。 Rust 為您提供unsafe關鍵字不是為了避免安全，而是為了隔離和明確包含在安全程式碼中不可能實現的不健全操作。但是當使用unsafe時，您正在與編譯器和執行時簽訂合約：您必須手動維護 Rust 通常為您提供的所有保證。其中包括指標有效性、生命週期正確性、記憶體對齊和類型健全性。轉換原始指針會違反所有這些規定，除非以手術精度處理。目前的 Dioxus 程式碼不進行任何驗證。它只是轉化並執行。

那麼解決方法是什麼？事實上，有好幾種。最直接的方法是在轉變之前驗證指標。如果指標為空或未對齊，系統應拒絕執行並傳回帶有診斷訊息的明確恐慌。這將防止分段錯誤並讓開發人員清楚地了解出了什麼問題。或者，系統可以要求對載入的函數進行簽署的元資料，以確保只執行受信任的程式碼路徑。這將有效地對重新加載系統進行沙盒化，並大大減少攻擊面。我們也可以採用Unity熱重載入插件中的模式，其中插件註冊是明確的並且經過編譯時檢查。這意味著熱重載目標需要明確註冊其函數導出，從而允許編譯器產生安全的入口點。這樣，對應用程式邏輯的任何更改都需要明確重新編譯插件清單，並且所有位址解析都可以根據一組已知的安全簽名進行驗證。

針對此報告，Dioxus 維護人員聲稱，由於這僅影響開發，因此修復它的優先順序較低。儘管我理解他們的理由，但我不敢苟同。開發時工具通常是新使用者和團隊評估技術的第一個接觸點。如果開發人員因為函數指標格式錯誤而在熱重載期間遇到崩潰，那麼這是否只是開發人員的問題並不重要，他們對 Dioxus 作為可靠工具鏈的看法已經變得遲鈍。更糟的是，在跨多個團隊和沙箱進行大規模開發的大型企業環境中，惡意重新載入錯誤可能會破壞暫存環境或破壞共享快取。這不僅僅是關乎安全；這是關於信任的問題。

尤其諷刺的是，Rust 最大的賣點，即其對記憶體安全和抗崩潰的承諾，卻因unsafe的不當使用而完全被抵消了。如果我們轉身寫的程式碼讓 C 編譯器都臉紅了，我們就無法吹噓「無畏的並發」和「安全的系統程式設計」。每個unsafe街區都是一把上了膛的槍。確保在沒有適當的保護措施的情況下不會發生這種事情是框架的工作，而不是開發人員的工作。

簡而言之，這種漏洞顯示了一個更深層的問題：氛圍編碼正在滲透到安全第一生態系統的核心庫。當我們為了速度而偷工減料時，特別是在unsafe環境中，我們最終會得到脆弱的基礎，背叛 Rust 所代表的一切。這不僅是工程品質差的問題。這違背了整個社會的信任。

CLI SSG 迴圈中的 SSRF

當您擁有像Dioxus CLI這樣的建置工具（其中包括伺服器端渲染（SSR）和靜態網站產生（SSG）功能）時，您已經在半特權環境中執行。即使「dx serve」被標記為開發工具，將未經驗證的輸入路由引入執行 HTTP 請求的循環中也會產生嚴重的警告，尤其是考慮到在 CI/CD 管道或本地暫存環境中使用這些工具的團隊數量越來越多。如本期所報告的，透過使用格式化的 HTTP GET 請求盲目地獲取每個路由，而不清理或驗證這些路徑，您為伺服器端請求偽造（SSRF）引入了一個清晰的向量。 SSRF 是OWASP 十大安全漏洞清單中廣泛認可的漏洞，它允許攻擊者誘騙伺服器向非預期目的地發出請求，例如內部系統、雲端元資料服務（例如AWS 的169.254.169.254 ），甚至是信任內部流量的其他易受攻擊的服務。

直接引用 OWASP 的話： “當 Web 應用程式在未驗證使用者提供的 URL 的情況下獲取遠端資源時，就會出現 SSRF 缺陷。” （ OWASP SSRF ）。 Dioxus 目前的 CLI 行為恰好符合該描述。儘管維護人員可能會以「這只是一個開發工具」來駁斥這一點，但我對接受不安全預設值背後的邏輯提出質疑，即使是在開發模式實用程式中。今天使用的開發工具可能會嵌入到明天的自動化管道中。我們都知道，在現代工作流程中，「開發」和「生產」之間的界線很快就變得模糊。

此外，攻擊者可以透過環境變數或其他錯誤配置來毒害路由列表，從而輕鬆利用 SSRF 向量。即使“只是開發”，洩露內部系統資料或轉向更敏感領域的潛在風險也應該至少需要最低限度的驗證層。我們並不是在談論重寫該工具，而只是在將路由字串傳遞到請求循環之前對其進行清理。確保路由是相對路徑，防止使用http://或https://前綴的路由，並在遇到絕對域時發生錯誤。這些簡單的補丁可以立即阻止一整類攻擊媒介。

諷刺的是，Dioxus 是一個 Rust 框架，旨在利用 Rust 的類型安全和安全性等優勢，但卻允許基本的安全衛生問題不受控制。開發人員轉向 Rust 是因為他們想要控制和可靠性。如果您的工具鏈削弱了語言建構的基礎，那麼您就不會使用 Rust。您正在運送的是 Vibe Rust™，這是對安全系統編程的一個淡化的承諾。

反射

讓我們在這裡明確一點：這與自我、爭論或任何針對專案的個人運動無關。這是一個急需的警鐘，它在整個開源 Rust 生態系統中引起了共鳴。當我報告這些問題時，我這樣做並不是為了挑剔或貶低，而是因為我真正關心我們正在使用的工具的品質。在過去的幾年裡，我編寫了無數行 Rust 程式碼，閱讀了 Rust 核心原始碼，並遵循了 Rust 自早期穩定以來的設計理念。我看到人們慶祝 Rust 的記憶體安全，卻忽略了用戶空間安全中日益嚴重的漏洞，尤其是在 Web 框架和黏合程式碼中。

安全不是事後才想到的，也永遠不該是事後才想到的。當您說「開發人員有責任安全地使用工具」時，從技術上來說您是正確的，但從道德上來說卻是疏忽的。讓我問一下：如果一家汽車公司說“哦，如果駕駛員正確使用煞車，煞車就會起作用，但有時除非你自己編寫煞車控制器，否則煞車不會做出反應”，你會相信嗎？這正是一些函式庫和框架現在向開發人員傳達的訊息。將安全責任轉移給最終用戶，特別是當此類問題可以在框架層主動緩解時，是一種不負責任的工程。

我們不是在談論外來攻擊媒介。我們正在討論開放重定向、 CSRF 、 SSRF和段錯誤。這些都是第一天的錯誤。這些類型的漏洞會出現在漏洞賞金報告中，如果在生產應用程式中未修補，就會成為頭條新聞。當對這些報告的回應是直接駁回、立即關閉問題或將其標記為「垃圾郵件」而不是進行技術討論時，這令人深感擔憂。這不僅是溝通不良，也是治理不善。

我完全理解開源是一種熱愛的勞動。維護人員經常在晚上和週末工作，沒有報酬，而且得不到重視。但成為開源大師的一部分就是知道如何回應批判性的意見。即使你不同意，你至少可以做的就是不要把信差當成敵人。否則，整個開放式協作理念就會淪為一種受管控的單一文化，批評會被視為攻擊，安全則會被視為「別人的工作」。

最後的想法

讓我們重新回顧一下大局。氛圍編碼並不是一個用來侮辱人的術語。它是一種簡寫，用於描述一種無需基礎知識即可直觀使用工具的模式。當函式庫變得太容易使用而犧牲了正確性時就會發生這種情況。開發人員開始透過複製範例、瀏覽文件和依靠自動完成來編寫應用程式。雖然這對原型設計來說沒有問題，但在生產中絕對是不可接受的。

Rust 社群常常以緩慢的步伐、正確的行事方式和交付高品質的程式碼而自豪。但如果我們不以同樣的標準來要求我們的框架，我們就只是在欺騙自己。安全性不僅存在於編譯器中。它存在於 API 中。它存在於介面中。它存在於設計中的假設之中。這就是為什麼我們需要一個符合人體工學且安全的框架。這就是我寫這篇文章的原因。

如果您建立的系統鼓勵貨物崇拜，人們在使用功能時並不了解其影響，那麼您就有責任讓這些功能更安全。如果您用「您使用錯誤」來駁回每一份安全報告，那麼您就建立了一個不安全的抽象。句號。

Dioxus 具有巨大的潛力。社區正在不斷壯大。 DX 非常出色。但如果基金會充滿了可避免的陷阱，那麼這一切都不重要。我希望這篇文章能幫助其他人理解，速度快和有趣並不是粗心的藉口。 Rust 值得更好的。開發人員值得得到更好的待遇。用戶值得擁有更好的待遇。

如果您是 Dioxus 用戶，請重新檢視您如何處理路由、伺服器功能以及任何不安全的 FFI 魔法。如果您在生產部署中使用 Dioxus，即使“只是測試”，也請審核您的設定。有開放的重定向嗎？您是否向動態路由發出 GET？您的伺服器功能是否驗證輸入並防禦 CSRF？

如果您是 Dioxus 或任何 Rust 專案的維護者，請考慮以下事項：

• 不要將安全報告視為垃圾郵件。花 5-10 分鐘來驗證問題。

• 使用類型系統來防止誤用，特別是在路由和 I/O API 中。

• 為常見的安全需求提供可選的防護措施（巨集、功能、特徵）。

• 清晰地記錄安全假設。使錯誤使用變得困難。

• 如有疑問，寧可謹慎行事，確保安全。 Rust 教會了我們這一點。活下去。

儘管有批評，我還是想以積極的態度結束這一切。 Dioxus 是一個出色的專案。在型別安全的 Rust UI 層中統一桌面、行動和 Web 應用程式所做的工作無異於富有遠見。我只需進行極少的程式碼更改即可在 WASM 和本機平台上執行相同的應用程式，這真是令人難以置信。伺服器功能強大。 SSG 的能力超越了時代。而完全建立在其之上的 OpenSASS 證明了 Dioxus 不僅僅是炒作，而是可用且可擴展的。

但再好的工具也難免會被批評。是的，正是透過回饋，有時是嚴厲的回饋，工具才從「夠好」發展到「業界標準」。我真誠希望大家能以這種精神來閱讀這篇部落格。

所以，感謝 Dioxus 團隊。感謝您的辛勤工作。感謝您提供的文件、範例和錯誤修復，我正在積極地為它們做出貢獻並不斷改進。請像重視開發人員經驗一樣重視安全性。因為最終，沒有安全性的 DX 只會快速失敗。

在 Open SASS，我們不懈地努力，讓每個人都能極為輕鬆地進行 Rust Web 開發。

如果您已經讀到這裡，那麼加入我們的 Discord就太好了。

直到下一次，繼續建造，但要負責任地建造👋！

原文出處：https://dev.to/wiseai/hacking-dioxus-how-vibe-coding-is-destroying-software-engineering-3ggm