Conversation
Custom domain trust portals (e.g. trust.sessionlab.com) failed with CORS errors on client-side API calls. The page loaded fine via SSR but form submissions like "Request Access" failed with "Failed to fetch". Root cause: getCustomDomains() filtered by domainVerified=true, but that flag only gets set when an admin completes our DNS check flow. Vercel can serve the domain before that, so the portal works but CORS rejects the origin. - Remove domainVerified filter from CORS domain query — an admin adding a domain is sufficient authorization - Add independent error handling for Redis/DB in getCustomDomains so a Redis failure doesn't silently drop valid DB results - Exempt /v1/trust-access from origin check middleware since those endpoints are public (no auth, no cookies, no CSRF risk) Co-authored-by: Mariano Fuentes <marfuen98@gmail.com> Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
2 Skipped Deployments
|
PR SummaryMedium Risk Overview Extends Written by Cursor Bugbot for commit 0d54899. This will update automatically on new commits. Configure here. |
|
🎉 This PR is included in version 3.11.3 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
| '/api/auth', // better-auth handles its own CSRF | ||
| '/v1/health', // health check | ||
| '/api/docs', // swagger | ||
| '/v1/trust-access', // public trust portal endpoints (no auth, no cookies) |
There was a problem hiding this comment.
CSRF exemption too broad, covers authenticated admin endpoints
Medium Severity
The /v1/trust-access prefix exemption from origin validation is too broad. While the public-facing endpoints under this path are indeed unauthenticated, there are multiple admin/* sub-paths (e.g., approve, deny, revoke) protected by HybridAuthGuard that support cookie-based session auth. Exempting them from the origin check removes the CSRF defense-in-depth for these state-changing admin actions. The comment says "no auth, no cookies" but that only applies to non-admin routes.
2 participants
This is an automated pull request to release the candidate branch into production, which will trigger a deployment.
It was created by the [Production PR] action.