fix(security): enforce API key auth on saved views router [#2035]#2037
Conversation
The saved_views_router was registered in main.py without the require_api_key dependency, allowing unauthenticated access to all CRUD endpoints for saved views. This is an authentication bypass that exposes filter configurations and enables data tampering. Add Depends(require_api_key) to the router definition, matching the pattern used by the main API router in routes.py.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b91001d029
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| saved_views_router = APIRouter( | ||
| prefix="/api/v1/saved-views", | ||
| tags=["saved-views"], | ||
| dependencies=[Depends(require_api_key)], |
There was a problem hiding this comment.
Route saved-view calls through the authenticated client
After this dependency is added, the existing saved-views frontend client still uses a private fetch helper that only passes signal (frontend/src/hooks/useSavedViews.ts:129-132) instead of the shared authenticated request path that adds credentials: 'include' and X-Api-Key (frontend/src/api.ts:404-415). In deployments where API_BASE is absolute, including the local preview/static path in frontend/src/api.ts:5-9, those saved-view requests no longer send the session cookie or API key, so every backend sync is treated as unavailable and the feature silently falls back to localStorage even after login.
Useful? React with 👍 / 👎.
Export getApiKey from api.ts and update useSavedViews apiFetch to include X-Api-Key header and credentials:'include', matching the authenticated request pattern used by the rest of the API client. Without this, saved-view requests silently fail with 401 in deployments where API_BASE is absolute, causing the feature to fall back to localStorage even after login.
utksh1
left a comment
There was a problem hiding this comment.
Critical security fix addressing authentication bypass vulnerability (#2035).
The saved views router was missing require_api_key dependency, allowing unauthenticated access to:
- GET /api/v1/saved-views (enumerate all views)
- POST /api/v1/saved-views (create views)
- PUT /api/v1/saved-views/{view_id} (modify views)
- DELETE /api/v1/saved-views/{view_id} (delete views)
Fix adds dependencies=[Depends(require_api_key)] to the router definition, matching the pattern used by other protected routes.
Rebased with main. Approving for merge.
Summary
Enforce API key authentication on the saved views router, closing an authentication bypass vulnerability.
Closes #2035
Problem
The
saved_views_routerinbackend/secuscan/saved_views.pywas registered inmain.pywithout therequire_api_keydependency. This allowed unauthenticated access to all CRUD endpoints:GET /api/v1/saved-views— enumerate all saved viewsPOST /api/v1/saved-views— create viewsPUT /api/v1/saved-views/{view_id}— modify viewsDELETE /api/v1/saved-views/{view_id}— delete viewsCompare with the protected main router in
routes.py:133:Fix
Added
dependencies=[Depends(require_api_key)]to thesaved_views_routerdefinition, matching the pattern used by the main API router:Impact
Authorization: Bearer <key>,X-Api-Key: <key>, or a valid session cookieTesting
curl http://localhost:8000/api/v1/saved-views→ returns 401curl -H "X-Api-Key: <valid-key>" http://localhost:8000/api/v1/saved-views→ returns 200Labels
type:security,level:critical,priority:high,area:backend