← 返回
未分类

Axum Code Review

Reviews axum web framework code for routing patterns, extractor usage, middleware, state management, and error handling. Use when reviewing Rust code that us...
对使用 axum Web 框架的 Rust 代码进行审查,关注路由模式、提取器使用、中间件、状态管理和错误处理。
anderskev anderskev 来源
未分类 clawhub v1.0.3 2 版本 100000 Key: 无需
★ 0
Stars
📥 508
下载
💾 1
安装
2
版本
#latest

概述

Axum Code Review

Review Workflow

  1. Check Cargo.toml — Note axum version (0.6 vs 0.7+ have different patterns), Rust edition (2021 vs 2024), tower, tower-http features. Edition 2024 changes RPIT lifetime capture in handler return types and removes the need for async-trait in custom extractors.
  2. Check routing — Route organization, method routing, nested routers
  3. Check extractors — Order matters (body extractors must be last), correct types
  4. Check state — Shared state via State, not global mutable state
  5. Check error handlingIntoResponse implementations, error types

Gates (before reporting findings)

Run in order. Do not write a finding until the step that applies has passed.

  1. Version and edition on diskPass when: You have read the relevant Cargo.toml (crate or workspace root) and can state axum (and related tower/tower-http) versions and Rust edition. Then apply 0.6 vs 0.7+ or Edition 2024–specific checklist items only when that file supports them.
  1. Per-finding evidencePass when: Each issue cites [FILE:LINE] from the current tree for the handler, router, layer, or type under review (not from memory, docs-only, or another branch).
  1. Category check vs protocolPass when: For the finding type (routing conflict, extractor order, error leak, middleware order, etc.), you ran the matching checks from the review-verification-protocol skill (e.g. full handler signature for extractor order; surrounding error mapping before “raw error to client”). Then add the finding.
  1. Output shapePass when: The report lines match Output Format below (severity + description).

Output Format

Report findings as:

[FILE:LINE] ISSUE_TITLE
Severity: Critical | Major | Minor | Informational
Description of the issue and why it matters.

Quick Reference

Issue TypeReference
-----------------------
Route definitions, nesting, method routingreferences/routing.md
State, Path, Query, Json, body extractorsreferences/extractors.md
Tower middleware, layers, error handlingreferences/middleware.md

Review Checklist

Routing

  • [ ] Routes organized by domain (nested routers for /api/users, /api/orders)
  • [ ] Fallback handlers defined for 404s
  • [ ] Method routing explicit (.get(), .post(), not .route() with manual method matching)
  • [ ] No route conflicts (overlapping paths with different extractors)

Extractors

  • [ ] Body-consuming extractors (Json, Form, Bytes) are the LAST parameter
  • [ ] State requires T: Clone — typically Arc or direct Clone derive
  • [ ] Path parameter types match the route definition
  • [ ] Query fields are Option for optional query params with #[serde(default)]
  • [ ] Custom extractors implement FromRequestParts (not body) or FromRequest (body)
  • [ ] Edition 2024: Custom extractors use native async fn in trait impls (no #[async_trait] needed for FromRequest/FromRequestParts)

State Management

  • [ ] Application state shared via State, not global mutable statics
  • [ ] Database pool in state (not created per-request)
  • [ ] State contains only shared resources (pool, config, channels), not request-specific data
  • [ ] Clone derived or manually implemented on state type
  • [ ] Edition 2024: Shared static state uses LazyLock from std (not once_cell::sync::Lazy or lazy_static!)

Error Handling

  • [ ] Handler errors implement IntoResponse for proper HTTP error codes
  • [ ] Internal errors don't leak to clients (no raw error messages in 500 responses)
  • [ ] Error responses use consistent format (JSON error body with code/message)
  • [ ] Result pattern used for handlers
  • [ ] Edition 2024: Handler return types -> impl IntoResponse capture all in-scope lifetimes by default; use + use<> to opt out of capturing request lifetimes when returning owned data

Middleware

  • [ ] Tower layers applied in correct order (outer runs first on request, last on response)
  • [ ] tower-http used for common concerns (CORS, compression, tracing, timeout)
  • [ ] Request-scoped data passed via extensions, not global state
  • [ ] Middleware errors don't panic — they return error responses
  • [ ] Edition 2024: Middleware using #[async_trait] can migrate to native async fn in trait impls

Severity Calibration

Critical

  • Body extractor not last in handler parameters (silently consumes body, later extractors fail)
  • SQL injection via path/query parameters passed directly to queries
  • Internal error details leaked to clients (stack traces, database errors)
  • Missing authentication middleware on protected routes

Major

  • Global mutable state instead of State (race conditions)
  • Missing error type conversion (raw sqlx::Error returned to client)
  • Missing request timeout (handlers can hang indefinitely)
  • Route conflicts causing unexpected 405s
  • Edition 2024: async-trait still used for FromRequest/FromRequestParts when native async fn works

Minor

  • Manual route method matching instead of .get(), .post()
  • Missing fallback handler (default 404 is plain text, not JSON)
  • Middleware applied per-route when it should be global (or vice versa)
  • Missing tower-http::trace for request logging
  • Edition 2024: once_cell::sync::Lazy or lazy_static! used where std::sync::LazyLock works

Informational

  • Suggestions to use tower-http layers for common concerns
  • Router organization improvements
  • Suggestions to add OpenAPI documentation via utoipa or aide

Valid Patterns (Do NOT Flag)

  • #[axum::debug_handler] on handlers — Debugging aid that improves compile error messages
  • Extension for middleware-injected data — Valid pattern for request-scoped values
  • Returning impl IntoResponse from handlers — More flexible than concrete types
  • Router::new() per module, merged in main — Standard organization pattern
  • ServiceBuilder for layer composition — Tower pattern, not over-engineering
  • axum::serve with TcpListener — Standard axum 0.7+ server setup
  • Native async fn in FromRequest/FromRequestParts implsasync-trait crate no longer needed (stable since Rust 1.75)
  • + use<'a> on handler return types — Edition 2024 precise capture syntax for RPIT
  • std::sync::LazyLock for shared static state — Replaces once_cell/lazy_static (stable since Rust 1.80)

Before Submitting Findings

Complete Gates (before reporting findings) and load the review-verification-protocol skill for category-specific checks before any issue is final.

版本历史

共 2 个版本

  • v1.0.3 当前
    2026-06-01 20:55 安全 安全
  • v1.0.2
    2026-05-03 06:49 安全 安全

安全检测

腾讯云安全 (Keen)

安全,无风险
查看报告

腾讯云安全 (Sanbu)

安全,无风险
查看报告

🔗 相关推荐

dev-programming

Github

steipete
使用 `gh` CLI 与 GitHub 交互,通过 `gh issue`、`gh pr`、`gh run` 和 `gh api` 管理议题、PR、CI 运行及高级查询。
★ 681 📥 329,181
dev-programming

CodeConductor.ai

larsonreever
AI驱动平台,提供快速全栈开发、智能体、工作流自动化及低代码AI集成的可扩展产品创建。
★ 75 📥 182,371
ai-agent

Deepagents Implementation

anderskev
使用 Deep Agents 实现代理,适用于创建代理、配置后端、定义子代理、添加中间件或设置...
★ 0 📥 699