👨🏻‍💻 破解 Dioxus：Vibe 编码如何摧毁软件工程

TL;DR

如果你正在招聘氛围型程序员，请三思，以免为时已晚。这篇文章并非要贬低 Dioxus；而是要提高人们对现代软件工程脆弱性的认识，尤其是在缺乏经验的开发人员使用强大工具的情况下。务必聘请拥有足够经验的工程师，尤其是在全栈开发等关键领域工作时。氛围型编程本身并不坏，但如果交给不合适的人，就会变成一种危险的做法。

介绍

大家好👋！

今天，我想和大家分享一种深深的挫败感，一种在两个不眠之夜积累起来的强烈不满，我试图报告并解释 Rust 生态系统中一个知名且公开的开源项目Dioxus的多个安全漏洞。对于那些不熟悉 Dioxus 的人来说，它是一款现代化的 Rust 全栈 UI 框架，并且它的承诺非常宏大。它旨在提供我们期望从 JavaScript 生态系统中获得的那种无缝开发体验，但由 Rust 的内存安全和类型系统提供支持。虽然它的目标令人钦佩，它的开发人员也显然充满热情，但我所遇到的情况暴露了现代“快速行动，打破常规”思维模式的阴暗面，这种思维模式甚至已经渗透到我们最稳健、理论上最安全的生态系统中。

这篇博文不仅反思了 Dioxus 本身，也反思了由我所谓的“氛围编码”所导致的软件工程实践的整体退化。这并非针对 Dioxus 本身或其开发者，而是呼吁业界认真对待安全问题。Dioxus 只是一个案例研究，一个具体的例子，说明了优先考虑开发人员体验和炒作而忽视安全工程原则的危险性。在任何人为自己辩护之前，请理解：如果以不眠之夜、编写的数百万行代码和实际使用过的真实系统来衡量经验，那么我已经在这个领域工作多年了，并且处理过真正的安全威胁。这并非我第一次这样做。

这个标题确实很煽情，但它也直指现实。Vibe 编码正在摧毁软件工程过去所代表的根本含义：精确、责任、可靠、安全。我完全理解产品经理和投资者对快速交付的迫切需求。我曾在压力下交付代码，也曾被“为什么还没完成？”这样的问题困扰。但这些都不能成为忽视基本原则的理由。我们构建的不是 TikTok 滤镜，而是处理真实数据、影响真实用户，甚至在某些情况下控制真实世界基础设施的软件。不惜一切代价、极力追求最低限度审查的交付文化，不仅是不负责任的，更是危险的。

这篇文章将带您了解过去两周在 Dioxus 中发现的多个安全漏洞。它将解释如何通过适当的工程实践来避免这些问题，以及为什么氛围编码（开发人员更注重编写代码的美观性或“感觉”，而不是理解底层系统）会导致系统故障。没错，虽然一些 Dioxus 维护人员可能声称这些并非“安全问题”，但安全软件设计的原则要求我们将其视为安全问题。

什么是软件工程师/开发人员？

在深入探讨复杂问题之前，我们先来澄清一些业界经常混用但实际上不应该混用的术语。软件工程师与开发人员有着本质区别。虽然两者都是代码编写者，但两者的职责和思维模式却截然不同。软件工程师能够从基本原理出发进行系统设计。他们了解内存模型、设计约束、威胁面、性能瓶颈以及可扩展性的权衡。他们不仅仅是编写代码，他们还能构建健壮、可维护且安全的系统，以优化的方式解决实际问题。

另一方面，软件开发人员通常专注于在这些系统范围内进行构建。他们可能负责添加功能、修复错误、调整性能，甚至只是在前端界面中连接 API。成为一名开发人员本身并没有错。但将两者混为一谈会导致期望不匹配，尤其是在招聘流程或开源社区中，因为贡献会影响成千上万的用户。

为什么在一篇关于 Dioxus 和氛围编码的文章中，这种区分如此重要？因为 Dioxus 与许多现代框架一样，抽象出了许多复杂性，这使得它对新手或可能不了解其行为后果的开发人员非常有吸引力。这种抽象本身并不邪恶。事实上，精心设计的抽象是优秀工程的基石之一。但是，当这些抽象被交给那些不完全理解他们所编写代码含义的人时，尤其是在像 Rust 这样的系统语言中，我们得到的软件就不安全了。

软件工程师不仅要对自己编写的代码负责，还要对这些代码在生产环境中的后果负责。当类型系统被绕过，当不可信的输入未经验证就被处理，当不安全的代码未经适当的论证和边界检查就被引入，这些都不是一时的判断失误，而是系统性的设计责任缺失。而这正是氛围编码所带来的后果。

归根结底，应用程序的安全性和完整性掌握在其背后的工程师手中。如果出现问题，仅仅指责“框架”或“社区”是不够的。工程师必须承担责任。因此，如果一个工具鼓励不安全的模式或未能强制执行良好的实践，这不仅仅是开发人员的问题，而是工程文化、文档和设计的失败。Dioxus 的案例研究就很能说明这一点。

什么是 Vibe 编码？

现在让我们花点时间定义一下这个核心概念：氛围编码 (vibecoding)。氛围编码是一种基于“感觉”而非理解的编程行为。它指的是开发人员将他们在文档、StackOverflow 或 AI 生成的输出中看到的代码片段拼凑在一起，而不理解系统的内部原理。它把你的框架或语言当作一个神奇的黑匣子，输入它，期望得到正确的输出，并假设“如果它能编译通过，那很可能没问题”。

Vibe 编码在系统编程中尤其危险。像 Rust 这样的语言旨在通过严格的编译时保证来增强安全性。但即使是 Rust，如果你故意（或无意地）绕过这些保证，也无法保护你的系统。不安全的块、动态插件系统、字符串类型的 API，所有这些都可能在不了解的情况下连接起来，从而产生微妙而危险的错误。

当有人用 React 写 UI 代码时，最糟糕的情况可能是按钮损坏或 div 对齐错误。当有人用 Dioxus 写服务器函数时，使用了不安全的函数指针、易受 CSRF 攻击的 API 或易受 SSRF 攻击的静态站点生成代码，后果会迅速恶化。然而，由于现代框架会考虑开发人员的人体工程学，它们并不总是会引导开发人员选择安全或合理的模式。它们优先考虑速度、简洁性和乐趣。但编程的乐趣不应该以牺牲纪律性为代价。

这就引出了一个重要的问题：当软件出现故障时，谁该负责？是编写代码的开发人员？是鼓励出现故障的框架？还是未能检测到故障的运行时？事实上，每个人都应承担一部分责任。但最大的责任在于编写代码的人。因为机器并没有编写你的软件，它只是执行它而已。无论 LLM 变得多么先进，或者我们的开发工具感觉多么“神奇”，人类始终是其中的一员。

这不仅仅是一场哲学讨论。它具有现实意义，正如下一节将要展示的那样。因为在过去的两个周末里，我深入研究了 Dioxus 的内部结构，并非以普通用户的身份，而是以一名软件工程师的身份，决心要破解它，看看其背后的真相。我的发现令人不安。我的报告却遭到了驳回。而我所了解到的是，我们正梦游般地进入一个由那些对自己所构建的东西一无所知的开发人员构建的不安全软件的新时代。

黑客狄奥克萨斯

我已经全职使用 Dioxus 超过 7 个月了。并非被动使用，也并非将其当作玩具。我曾在生产系统中使用它，构建过全栈应用，与 WebAssembly 集成，部署到云环境，并尝试过服务器端渲染和静态生成。我的反馈并非源于摩擦，而是源于个人的熟悉程度。我在深入审核其代码库时发现的问题，应该引起所有使用或为该项目做出贡献的人的关注。

让我们从第一个漏洞开始：组件中的 Open RedirectLink。

开放重定向漏洞

这个问题已在此处报告。听起来可能无关紧要，但其影响却不容小觑。DioxusLink组件目前接受任意字符串作为to参数。这意味着开发人员可以编写如下代码：

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

维护人员认为这没问题，开发者有权决定是内部链接还是外部链接。但问题在于：该Link组件是 Dioxus 路由器的一部分，而 Dioxus 路由器用于内部导航。它用于管理应用内路由、维护客户端历史记录，并提供无需重新加载整个页面的无缝用户体验。允许任意外部 URL 通过此组件会破坏开发者与路由器系统之间的信任契约。它模糊了内部路由和外部重定向之间的界限，从而为网络钓鱼和重定向攻击向量提供了便利。

将此与Yew进行比较，后者是一个正确实现这一点的 Rust 框架。Yew的Link组件仅接受枚举值Routable。这强制在编译时保证路由有效且是内部路由。您不会意外传入用户控制的字符串并将其重定向到恶意网站。这就是类型安全。这是 Rust 的承诺。而这正是 Dioxus 所破坏的。

所以，当我把这个问题归类为漏洞时，我并非吹毛求疵。我主张 Dioxus 尊重 Rust 的理念：尽可能在编译时避免错误。但维护人员对此表示反对。其中一位甚至轻蔑地说：“这不是一个安全漏洞，声称它是安全漏洞简直荒谬。” 这种语气不仅不专业，而且很危险。它阻碍了负责任的漏洞披露，扼杀了开源安全文化，而且完全没有抓住要点。

我提出了一个简单的解决方案：如果用户想要链接到外部网站，请使用标准 HTMLa标签：

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

如果用户想要应用内路由，请使用：

Link { to: Route::Home }

这确保了类型安全、关注点分离和更好的 DX，同时又不损害安全性。双赢。但维护人员对此并不感兴趣。也许是因为这个修复不够“有气氛”。

服务器函数中的 CSRF

让我们首先分析一下 CSRF 在技术层面上的工作原理，以及为什么如果在服务器端 API（尤其是通过 Web 服务前端客户端的 API）中没有得到适当的缓解，它会成为一个严重的威胁。跨站请求伪造 (CSRF) 是一种众所周知且危险的攻击形式，攻击者会诱骗用户在当前已通过身份验证的 Web 应用程序上执行不必要的操作。这些操作可能包括更改帐户设置、提交数据，甚至进行金融交易。核心漏洞源于浏览器会自动将 Cookie 附加到请求中，包括身份验证令牌和会话 Cookie，如果未正确验证，受害者的身份验证状态就可能被利用。在这种情况下，Dioxus 的服务器功能旨在为开发人员提供具有自动序列化和路由功能的异步 API，但缺乏内置的 CSRF 保护，这使得开发人员处于危险的境地，无法保证默认安全。

当我提出#[with_csrf]宏时，不仅仅是为了语法糖或便利性，而是为了让 Dioxus 堆栈与安全默认值原则保持一致，这是 Rust 语言及其生态系统引以为豪的。Rust 的核心理念是围绕安全性和正确性。当我们将正确性的负担完全转移到开发人员身上时，我们就违背了这一隐含的承诺。让我们以像这样的框架Next.js为例。即使它是用 JavaScript（一种出了名的宽容和不安全的语言）编写的，它Next.js仍然不遗余力地鼓励使用CSRF令牌，并提供中间件和实用程序来减少此类疏忽的可能性。我认为，认为 Dioxus 不应该对 CSRF 负责，因为它不直接管理会话或身份验证，这种说法是不够的。提供像 CSRF 令牌这样的安全原语应该是任何现代全栈 Web 框架提供的最低限度的服务，这并不是要求一个功能；这是为了在一个网络攻击是常态而不是例外的互联世界中提供基础安全。

此外，从开发人员体验的角度来看，引入#[with_csrf]过程宏几乎不会增加任何认知开销，但却能显著提高服务器函数抵御 CSRF 攻击的可能性。建议的实现可以轻松检查请求标头中的有效值，并根据签名的会话令牌进行验证。这与Django和LaravelX-CSRF-Token等流行框架多年来的做法类似。这是一种久经考验的模式。我所要求的并非全新或革命性的模式，而是标准、成熟且安全的模式。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 十大安全漏洞列表中被广泛认可，它允许攻击者诱骗服务器向非预期目的地发出请求，例如内部系统、云元数据服务（例如AWS169.254.169.254），甚至其他信任内部流量的易受攻击的服务。

直接引用 OWASP 的话：“每当 Web 应用程序在未验证用户提供的 URL 的情况下获取远程资源时，就会出现 SSRF 漏洞。”（OWASP SSRF）Dioxus 当前的 CLI 行为恰恰符合这一描述。虽然维护人员可能会以“它只是一个开发工具”来驳斥这一点，但我质疑即使在开发模式的实用程序中也接受不安全默认设置背后的逻辑。今天使用的开发工具可能会嵌入到未来的自动化流程中。我们都知道，在现代工作流程中，“开发”和“生产”之间的界限很快就会变得模糊。

此外，攻击者可以通过环境变量或其他错误配置毒害路由列表，从而轻松利用 SSRF 向量。即使“只是开发阶段”，泄露内部系统数据或转向更敏感领域的潜在风险也应该至少需要一个最低限度的验证层。我们并非要重写工具，而只是在路由字符串传入请求循环之前对其进行清理。确保路由是相对路径，防止http://使用https://前缀路由，并在遇到绝对域名时报错。这些简单的补丁可以有效阻止一整类攻击向量的攻击。

讽刺的是，Dioxus 这个 Rust 框架旨在利用 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 是一个杰出的项目。他们致力于将桌面、移动和 Web 应用统一到一个类型安全的 Rust UI 层，这简直是富有远见卓识。我只需极少的代码改动就能在 WASM 和原生平台上运行同一个应用，这真是令人难以置信。服务器功能非常强大。SSG 的功能也领先于时代。而完全基于它构建的 OpenSASS 证明了 Dioxus 并非只是炒作，它确实可用且可扩展。

但优秀的工具也难免会受到批评。正是通过反馈，没错，有时反馈很严厉，工具才能从“足够好”进化到“行业标准”。我真诚希望大家能秉持这种精神来阅读这篇博客。

所以，感谢 Dioxus 团队。感谢你们辛勤的工作。感谢你们提供的文档、示例和错误修复，所有这些我都在积极地贡献和改进。请像重视开发者体验一样重视安全性。因为最终，没有安全性的 DX 只会快速失败。

在 Open SASS，我们不懈努力，让每个人都能极其轻松地进行 Rust Web 开发。

如果您已经读到这里，那么加入我们的 Discord就太好了。

直到下一次，继续建造，但要负责任地建造👋！