← Back to PRs

#23425: Gateway: require trusted-proxy allowlist unless allowAll is explicit

by bmendonca3 open 2026-02-22 09:34 View on GitHub →
docs gateway commands size: M trusted-contributor
## Summary - enforce trusted-proxy safe defaults by requiring `gateway.auth.trustedProxy.allowUsers` unless `gateway.auth.trustedProxy.allowAll=true` - reject trusted-proxy requests at auth time when neither allowlist nor explicit allow-all is configured - update security audit checks, trusted-proxy docs, and gateway configure flows so users must choose allowlist or explicit allow-all ## Validation - `pnpm test src/gateway/auth.test.ts src/gateway/server-runtime-config.test.ts src/security/audit.test.ts` - `pnpm test:e2e src/commands/configure.gateway-auth.e2e.test.ts src/commands/configure.gateway.e2e.test.ts` - `pnpm tsgo` - `pnpm check` <!-- greptile_comment --> <h3>Greptile Summary</h3> This PR strengthens trusted-proxy authentication security by requiring an explicit allowlist of users (`allowUsers`) or an explicit opt-in to allow all authenticated proxy users (`allowAll=true`). Previously, an empty `allowUsers` array would silently allow any authenticated proxy user, which could lead to unintended access. **Key changes:** - Added `allowAll` boolean field to trusted-proxy configuration as an explicit break-glass override - Modified validation in `assertGatewayAuthConfigured` (src/gateway/auth.ts:311) to reject configurations missing both `allowUsers` and `allowAll=true` - Added runtime enforcement in `authorizeTrustedProxy` (src/gateway/auth.ts:356-357) to reject requests when neither is configured - Updated security audit to flag missing configuration as `critical` severity instead of `warn` - Modified `configure gateway` interactive prompts to loop until user provides allowlist or explicitly confirms allow-all - Updated all documentation and examples to include `allowUsers` configuration - Comprehensive test coverage for new validation paths <h3>Confidence Score: 5/5</h3> - This PR is safe to merge with minimal risk - it strengthens security defaults without breaking existing functionality - The changes are well-implemented with defense-in-depth: validation at config assertion time (startup), runtime authorization checks, security audit updates, comprehensive test coverage including edge cases (missing allowlist, explicit allowAll, empty allowUsers), thorough documentation updates, and backward-compatible handling (existing configs with allowUsers continue working). The interactive configuration prevents users from accidentally creating insecure configurations. - No files require special attention <sub>Last reviewed commit: 61211ed</sub> <!-- greptile_other_comments_section --> <!-- /greptile_comment -->

Most Similar PRs