Summary
Better Auth improperly validates URL paths when relying on a router that collapses multiple slashes into a single normalized path.
This can let attackers bypass disabled path protections and path-based rate limits by sending requests with extra slashes, unless an upstream proxy already normalizes URLs.
Affected context
The vulnerability appears in Better Auth setups that:
- Depend on the better-call integration using the rou3 routing library
- Enforce security controls using exact path strings for disabledPaths or rate limits
- Do not have an upstream reverse proxy, load balancer, or platform that normalizes URL paths by collapsing multiple consecutive slashes
In these contexts, different-looking URLs such as /path, //path, and ///path can be routed identically while being treated differently by authorization and throttling logic.
Exploit preconditions
- Attack surface: HTTP endpoints protected by Better Auth path-based configuration
- Required access: Ability to send crafted HTTP requests to the affected service
- Trigger point: Request routing where rou3 normalizes paths and Better Auth checks raw, unnormalized paths
- Why exploitation is possible: The router treats multiple-slash variants of a path as equivalent, but the security configuration compares paths as literal strings, enabling discrepancies that bypass disabled paths and per-route rate limiting.
Why this happens
The core issue stems from inconsistent input validation and normalization of URL paths between the routing layer and the security configuration layer.
Rou3 collapses empty path segments, effectively normalizing /path, //path, and ///path to the same route, while Better Auth relies on exact path matching for disabledPaths and rate limits without applying the same normalization.
This mismatch aligns with CWE-20: Improper Input Validation, as the system fails to canonicalize and validate inputs consistently across components, allowing logically equivalent but syntactically different paths to evade controls.
Potential impact
- Attackers may bypass disabled or blocked API routes using alternate multi-slash path representations.
- Attackers could evade or delay path-based rate limits by alternating between slash variants of the same route.
- Sensitive operations that rely on path restrictions can be exposed to unauthorized or excessive use.
- Logging, monitoring, and audit trails may underreport or misclassify malicious activity due to path inconsistencies.
General mitigation guidance
Mitigation typically focuses on consistent canonicalization and validation of URL paths before applying any authorization or throttling decisions.
Recommended patterns include:
- Canonically normalizing request paths (e.g., collapsing multiple slashes) at a single, trusted boundary and using the normalized value everywhere.
- Centralizing path comparison logic so that routing, access control, and rate limiting share the same path representation.
- Designing configuration formats to express rules in terms of normalized route identifiers rather than raw URL strings.
- Applying defense-in-depth with upstream proxies or gateways that enforce strict, predictable URL normalization and reject malformed paths.
How teams detect issues like this
Detection efforts can focus on identifying inconsistencies between routing and security checks:
- Static analysis or configuration review to flag places where raw request paths are compared directly to configuration strings without prior normalization.
- Code review checklists that ask whether all path-based access control and rate limiting logic use the same canonicalization routine as the router.
- Integration tests that exercise equivalent paths with multiple slashes and verify that disabledPaths and rate limits behave consistently.
- Automated security scanning or fuzzing tools configured to generate URL variants with extra slashes and report discrepancies in responses or logging.
