[BUG] [v0.0.7] app-server rate_limit/timeout/security-header middlewares are defined but never attached to the router

[DDDDDGCSM]

Summary

cortex-app-server defines production middleware for rate limiting, request timeouts, security headers, and content-type validation, but create_router_with_state() never attaches those middleware layers to the Axum router. As a result, enabling rate_limit in ServerConfig does not actually protect the API routes, and the implemented timeout/security-header/content-type middleware is also dead code for normal requests.

Evidence

The relevant code paths are:

• src/cortex-app-server/src/middleware.rs:109 defines rate_limit_middleware.
• src/cortex-app-server/src/middleware.rs:186 defines timeout_middleware.
• src/cortex-app-server/src/middleware.rs:203 defines security_headers_middleware.
• src/cortex-app-server/src/middleware.rs:226 defines content_type_middleware.
• src/cortex-app-server/src/lib.rs:142-143 only attaches TraceLayer::new_for_http() and CorsLayer::permissive().

Command used to verify the mismatch:

rg -n 'rate_limit_middleware|timeout_middleware|security_headers_middleware|content_type_middleware|auth_middleware|\.layer\(' \
  src/cortex-app-server/src/lib.rs \
  src/cortex-app-server/src/middleware.rs \
  src/cortex-app-server/src/auth.rs

The output shows the middleware functions exist, but the router only applies Trace and CORS layers.

Expected behavior

When config.rate_limit.enabled is true, requests should pass through rate_limit_middleware. The timeout, security headers, and content-type validation middleware should also be attached if they are intended to protect app-server API routes.

Actual behavior

create_router_with_state() builds the router and attaches only:

.layer(TraceLayer::new_for_http())
.layer(CorsLayer::permissive())

No rate-limit, timeout, content-type, or security-header middleware is applied to /api/v1 routes.

Impact

Operators can enable rate limiting in config and believe the API is protected, but the configured limiter is never enforced. This also leaves the implemented timeout, content-type, and security-header protections inactive on normal HTTP API requests.

[694410194]

Opened upstream PR: CortexLM/cortex-code#292

The fix attaches the existing app-server rate-limit, timeout, security-header, and content-type middleware to the /api/v1 router so the protections implemented in src/cortex-app-server/src/middleware.rs are actually enforced.

Verification performed in this environment:

• git diff --check
• static review of src/cortex-app-server/src/lib.rs against the middleware definitions

I could not run cargo check / cargo test here because the Rust toolchain was not available in this environment.

[atlas-cortex]

✅ Validation Summary — Issue #53530

All validation checks passed. All 17 code rules passed. | 14 LLM instructions active

Confidence Score: 4/5

• All validation checks passed. This submission meets the bounty requirements.

Validation Checks

Check	Status	Detail
Media Evidence	✅ Pass	Evidence found and accessible
Spam Detection	✅ Pass	Score: 0% — no spam signals
Duplicate Detection	✅ Pass	No significant overlap with existing issues
Code Verification	✅ Pass	Bug confirmed in source code (confidence: 100%) — screenshots invalid — The bug report claims that the rate limit, timeout, security headers, and conten
Edit History	✅ Pass	No suspicious edits
LLM Evaluation	✅ Pass	All validation checks passed. All 17 code rules passed.

Validation Pipeline

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["Issue #53530"] --> B{"Media Check"}
    B -->|"✅ Found"| C{"Spam Check"}
    C -->|"✅ Clean"| D{"Duplicate Check"}
    D -->|"✅ Unique"| CV{"Code Verify"}
    CV -->|"✅ Confirmed"| E{"Edit History"}
    E -->|"✅ Normal"| F{"LLM Evaluation"}
    F -->|"✅ Valid"| G["✅ Approved"]
    style G fill:#51cf66,color:#fff

Loading

Raw Evidence

{
  "media": {
    "hasMedia": true,
    "accessible": true,
    "urls": [
      "https://raw.githubusercontent.com/DDDDDGCSM/solid-carnival/master/evidence/cortex-rate-limit-middleware-proof.png"
    ],
    "evidence": [
      "Found 1 media URL(s) via GitHub rendered HTML",
      "1 URL(s) accessible"
    ]
  },
  "spam": {
    "overallScore": 0,
    "details": "template=0.00 (0 recent issues compared); burst=0.00 (1 issues in 2h window); parity=0.00; overall=0.00 (threshold=0.7)"
  },
  "duplicate": {
    "isDuplicate": false,
    "similarity": 0.47837938669806984,
    "topSimilar": [
      {
        "issueNumber": 53250,
        "title": "[BUG] [v0.0.7] cortex-app-server rate_limit_middleware falls back to 'ip:unknown' for direct connections — one client hitting the rate limit blocks all other clients via shared bucket",
        "similarity": 0.47837938669806984
      },
      {
        "issueNumber": 53239,
        "title": "[BUG] [v0.0.7] cortex-app-server body_limit_middleware only checks Content-Length header — chunked transfer-encoding requests bypass body size limit entirely",
        "similarity": 0.4553281209707838
      },
      {
        "issueNumber": 53376,
        "title": "[BUG] [v0.0.7] `cortex acp --allow-tool` and `--deny-tool` flags are printed but never applied to server config",
        "similarity": 0.43858201034830635
      },
      {
        "issueNumber": 53251,
        "title": "[BUG] [v0.0.7] cortex-app-server tools/security.rs is_dangerous_command() blocklist bypass via `env` — `env python3 -c <payload>` executes arbitrary code since env is not blocked",
        "similarity": 0.4199926564548181
      },
      {
        "issueNumber": 53238,
        "title": "[BUG] [v0.0.7] cortex-app-server proxy.rs proxy_to_port_path() is an unrestricted SSRF — proxies to any localhost port including SSH (22), databases (3306, 5432, 27017) and internal admin services",
        "similarity": 0.41929456054940195
      }
    ]
  },
  "editHistory": {
    "fraudScore": 0,
    "editCount": 0,
    "details": "No edits detected"
  },
  "codeVerification": {
    "plausible": true,
    "confidence": 1,
    "reasoning": "The bug report claims that the rate limit, timeout, security headers, and content-type middlewares are defined but never attached to the router. The code in `src/cortex-app-server/src/lib.rs` confirms this, as `create_router_with_state` only attaches `TraceLayer` and `CorsLayer`. The screenshot shows the output of a `rg` command confirming the same.",
    "codeEvidence": "The code in `src/cortex-app-server/src/lib.rs` defines `create_router_with_state` which only attaches `TraceLayer` and `CorsLayer`. The middleware functions like `rate_limit_middleware`, `timeout_middleware`, etc. are defined in `src/cortex-app-server/src/middleware.rs` but are never attached to the router.",
    "screenshotValid": false,
    "screenshotReasoning": "The screenshot shows the output of a `rg` command searching for the middleware functions in the source code. This is NOT a valid user-facing screenshot, as it only shows source code and not the actual user experience of the bug."
  },
  "rules": {
    "codeResults": {
      "passed": [
        {
          "ruleId": "content.no-profanity",
          "category": "content",
          "severity": "flag",
          "passed": true,
          "message": "Issue should not contain excessive profanity or abusive language",
          "weight": 1
        },
        {
          "ruleId": "content.reasonable-length",
          "category": "content",
          "severity": "flag",
          "passed": true,
          "message": "Issue body should not exceed 15000 characters (possible spam dump)",
          "weight": 1
        },
        {
          "ruleId": "content.has-context",
          "category": "content",
          "severity": "penalize",
          "passed": true,
          "message": "Issue should mention the affected page, component, or URL",
          "weight": 0.2
        },
        {
          "ruleId": "media.require-evidence",
          "category": "media",
          "severity": "require",
          "passed": true,
          "message": "Issue must include at least one screenshot or video URL",
          "weight": 1
        },
        {
          "ruleId": "media.must-be-accessible",
          "category": "media",
          "severity": "require",
          "passed": true,
          "message": "All media URLs must be publicly accessible (HTTP 200)",
          "weight": 1
        },
        {
          "ruleId": "media.no-placeholder-urls",
          "category": "media",
          "severity": "reject",
          "passed": true,
          "message": "Media URLs should not be placeholder or example URLs",
          "weight": 1
        },
        {
          "ruleId": "scoring.duplicate-threshold",
          "category": "scoring",
          "severity": "penalize",
          "passed": true,
          "message": "Penalize issues with moderate duplicate similarity (0.5-0.75)",
          "weight": 0.3
        },
        {
          "ruleId": "scoring.suspicious-edits",
          "category": "scoring",
          "severity": "penalize",
          "passed": true,
          "message": "Penalize issues with concerning edit history (fraud score > 0.3)",
          "weight": 0.25
        },
        {
          "ruleId": "spam.high-score-reject",
          "category": "spam",
          "severity": "reject",
          "passed": true,
          "message": "Reject issues with spam score above 0.85",
          "weight": 1
        },
        {
          "ruleId": "spam.generic-title",
          "category": "spam",
          "severity": "penalize",
          "passed": true,
          "message": "Title should not be a generic/template title",
          "weight": 0.4
        },
        {
          "ruleId": "spam.body-is-title-repeat",
          "category": "spam",
          "severity": "penalize",
          "passed": true,
          "message": "Body should not be a simple repetition of the title",
          "weight": 0.5
        },
        {
          "ruleId": "spam.no-ai-filler",
          "category": "spam",
          "severity": "flag",
          "passed": true,
          "message": "Body should not contain obvious AI-generated filler phrases",
          "weight": 1
        },
        {
          "ruleId": "validity.min-body-length",
          "category": "validity",
          "severity": "reject",
          "passed": true,
          "message": "Issue body must be at least 50 characters",
          "weight": 1
        },
        {
          "ruleId": "validity.min-title-length",
          "category": "validity",
          "severity": "reject",
          "passed": true,
          "message": "Issue title must be at least 10 characters",
          "weight": 1
        },
        {
          "ruleId": "validity.no-empty-body",
          "category": "validity",
          "severity": "reject",
          "passed": true,
          "message": "Issue body must not be empty or only whitespace",
          "weight": 1
        },
        {
          "ruleId": "validity.has-steps-or-description",
          "category": "validity",
          "severity": "penalize",
          "passed": true,
          "message": "Issue body should contain structured content (steps, expected/actual behavior)",
          "weight": 0.3
        },
        {
          "ruleId": "validity.not-a-feature-request",
          "category": "validity",
          "severity": "flag",
          "passed": true,
          "message": "Issue should describe a bug, not a feature request",
          "weight": 1
        }
      ],
      "failed": []
    },
    "llmInstructions": [
      "Always prioritize concrete evidence (screenshots, videos, URLs) over the quality of the written description. A poorly written report with clear visual proof of a bug is VALID. A beautifully written report with no evidence is INVALID.",
      "A valid bug report must contain enough information for an engineer to reproduce the issue. If the steps to reproduce are missing or impossibly vague (\"it just broke\"), the issue is INVALID.",
      "You MUST call the deliver_verdict function exactly once. Do not output a JSON object manually. Do not output your verdict in plain text. Use the tool.",
      "Be highly suspicious of submissions that follow a rigid template: same structure, same phrasing, with only the page name or URL swapped. These are template-farmed and should be INVALID. Look for: identical sentence structure, placeholder-like descriptions, formulaic \"Steps to Reproduce\".",
      "When similar issues exist, the OLDER issue (lower issue number) always takes precedence. The newer submission is the duplicate, never the other way around.",
      "Confidence scores must be calibrated: use 0.9+ only when evidence is unambiguous and complete. Use 0.5-0.7 when the issue is borderline. Use below 0.5 when you are genuinely uncertain. Never default to 0.5 — commit to a direction.",
      "Do not give the benefit of the doubt. Missing evidence means INVALID. Unclear reproduction steps means INVALID. Inaccessible media means INVALID. The burden of proof is on the submitter.",
      "In the reasoning field, explain your step-by-step analysis BEFORE stating your conclusion. Cover: evidence quality, clarity, spam signals, and duplicate overlap in that order.",
      "Never mention internal scoring thresholds, rule IDs, detection heuristics, or system architecture in the recap field. The recap is public-facing. Keep reasoning technical but recap user-friendly.",
      "If the issue body reads like AI-generated boilerplate (phrases like \"It is important to note\", \"Furthermore\", \"In conclusion\", excessive politeness, no specific technical details), treat it as strong evidence of spam. AI-generated issues with no real bug details are INVALID.",
      "If the pre-computed media check says media URLs exist, verify the description matches what a screenshot would show. If the description talks about a login page but the context suggests the screenshot is of something unrelated, flag this as suspicious.",
      "Never soften a verdict out of sympathy. \"I can see you tried hard but...\" is not acceptable. If the submission does not meet criteria, it is INVALID regardless of apparent effort.",
      "Write your reasoning and recap in a professional, neutral tone. Do not be sarcastic, condescending, or emotional. State facts.",
      "The recap field must be 2-3 sentences maximum. It will be posted as a public comment. No bullet points in recap — use flowing prose."
    ],
    "totalCodeRules": 17,
    "totalLLMRules": 14,
    "hasReject": false,
    "hasFailed": false,
    "penaltyScore": 0,
    "summary": "All 17 code rules passed. | 14 LLM instructions active"
  }
}

_{Validated by Atlas • 2026-05-13}

[BLUE-STEEL3]

​Hi team, I would love to work on this issue and attach the missing middlewares (rate_limit, timeout, and security-header) to the app-server router. Could you please assign it to me?

[BLUE-STEEL3]

Based on the issue description, the missing middlewares (rate_limit_middleware, timeout_middleware, security_headers_middleware, and content_type_middleware) defined in middleware.rs just need to be registered into the router chain in src/cortex-app-server/src/lib.rs.

​Around lines 142-143, the router should be updated to chain these layers. Depending on whether they are implemented as standard Tower Layers or Axum function middlewares, the fix in lib.rs would look like this:

// In src/cortex-app-server/src/lib.rs
use crate::middleware::{
rate_limit_middleware,
timeout_middleware,
security_headers_middleware,
content_type_middleware
};

// Inside the router definition:
let app = Router::new()
// ... existing routes ...
.layer(TraceLayer::new_for_http())
.layer(CorsLayer::permissive())
// Attaching the missing middlewares:
.layer(axum::middleware::from_fn(security_headers_middleware))
.layer(axum::middleware::from_fn(content_type_middleware))
.layer(axum::middleware::from_fn(timeout_middleware))
.layer(axum::middleware::from_fn(rate_limit_middleware));

If you can assign this to me, I can open a PR in the main repository to apply this fix immediately!

[Hemasrikallam]

Hi team, I'd like to work on this issue. Here's my implementation plan:

Approach

The existing proposals (including PR #340) attach middleware unconditionally using from_fn, but the issue description specifically states:

"When config.rate_limit.enabled is true, requests should pass through rate_limit_middleware"

My fix addresses this properly:

1. Config-driven conditional middleware

Rate limiting is only attached when config.rate_limit.enabled == true. Using from_fn_with_state instead of bare from_fn so the middleware has access to the rate limiter state and timeout configuration at runtime.

2. Correct layer ordering (inside-out execution)

TraceLayer (outermost — logs everything) → CORS (config-driven, not permissive()) → Rate Limit (fail fast — reject before doing work) → Timeout (kill slow requests) → Content-Type validation → Security Headers (innermost — always decorates response) → Handler