Security Advisory — CORS in Older Scaffolds

Status

• Affected component: applications generated by older versions of cargo-rullst make:cors or by blueprints that copied a permissive or reflected CORS policy.
• Current framework: corrected. New scaffolds use an explicit allowlist and fail when CORS_ALLOWED_ORIGINS is missing, empty, contains *, or contains an invalid origin.
• Previously generated applications: not modified automatically by a CLI update. Each repository must review the middleware already copied into its source tree.
• Severity: application-dependent. Risk is higher when an untrusted origin can read responses authenticated by a cookie or bearer token.

This is a scaffold migration advisory. It is not a CVE, penetration test, or claim that every final CORS configuration is secure.

Find a potentially affected application

Review the generated CORS middleware and search for these patterns. The snippet below is deliberately incomplete and unsafe; use it only as a search pattern.

AllowOrigin::mirror_request()
.allow_origin(Any)
.allow_credentials(true)

Copying the Origin request header into Access-Control-Allow-Origin without comparing it against a server-managed allowlist is also unsafe. Reflected origins or wildcards combined with credentials require immediate review.

Run an initial search from the application root:

rg -n 'mirror_request|allow_origin\(Any\)|allow_credentials\(true\)|Access-Control-Allow-Origin' src

Review every match. allow_credentials(true) is not inherently vulnerable when it is combined with a correct closed origin allowlist.

Recommended migration

1. Back up or review the existing middleware and generate the current version on a separate branch with cargo rullst make:cors.

2. Replace reflection or wildcards with exact origins including scheme, host, and port:

   CORS_ALLOWED_ORIGINS=https://app.example.com,https://admin.example.com
   

3. Keep credentials disabled unless the application genuinely needs cookies or cross-origin authentication. If required, enable them only after validating the exact allowlist.

4. Restrict methods and headers to the API’s actual contract. The current scaffold provides a baseline; it cannot infer every application endpoint.

5. Test at least one allowed origin and negative cases covering a similar host, unauthorized subdomain, different port, null, and no Origin header.

Example manual check: an unauthorized origin must not receive an Access-Control-Allow-Origin response header.

curl -i -X OPTIONS https://api.example.com/resource \
  -H 'Origin: https://evil.example' \
  -H 'Access-Control-Request-Method: POST'

Completion criteria

The migration is complete when:

• no origin is reflected or accepted by wildcard;
• the process fails explicitly when required configuration is missing or invalid;
• credentials are accepted only for exact authorized origins;
• negative tests prove that deceptively similar origins receive no authorization;
• caches and proxies receive Vary: Origin when the response depends on the request origin.

The current template is cargo-rullst/src/generators/cors_middleware.rs.template.