Overview of the Feature Request
Create a dedicated session-auth hardening track to protect session-cookie API usage without breaking existing token-based clients.
Scope of this hardening track:
- Add request-level auth-mechanism tagging in API auth flow (api key, bearer, signed URL, session cookie).
- Add a dedicated hardening feature flag (off by default).
- Add anti-CSRF protections for session-cookie requests, including CSRF nonce/token checks for state-changing calls and strict Origin/Referer validation.
- Harden session-cookie usage guidance/enforcement (
Secure, HttpOnly, and SameSite guidance with compatibility notes).
- Add session-cookie-specific gating for
/api/access/* behind the hardening flag.
- Add narrow transition guardrails for the two identified mutating
GET endpoints, scoped to session-cookie mode under the hardening flag:
GET /api/datasets/{id}/uploadurls
GET /api/datasets/{id}/cleanStorage
- Keep default behavior unchanged when hardening is off.
Reason this is needed now:
- Session-cookie auth is required by many JSF/SAML deployments.
- Mutating
GET endpoints increase CSRF exposure when cookies are automatically sent by browsers.
- We need a safe, incremental migration pattern (similar to compatibility/legacy-flag approaches used in API response-format work), but scoped narrowly to hardening concerns.
What kind of user is the feature intended for?
Sysadmin, Depositor, Curator, API User
What inspired the request?
SessionID-based API support is needed for JSF/SAML-oriented integrations, but enabling session-auth should come with explicit, modern hardening controls.
What existing behavior do you want changed?
Current session-auth behavior is broad and lacks an explicit, opt-in hardening profile.
We want auth-mechanism-aware controls and CSRF defenses for session-cookie requests, while preserving existing behavior for apiKey/bearer/signed-url flows.
Any brand new behavior do you want to add to Dataverse?
Yes:
- Auth-mechanism-aware request handling.
- Dedicated hardening feature flag for session-auth.
- CSRF nonce/token validation for session-cookie state-changing requests.
- Origin/Referer checks for session-cookie requests.
- Session-cookie-specific
/api/access/* hardening gate.
- Session-cookie-scoped guardrails for the two mutating
GET endpoints listed above (without broad API method rewrites in this issue).
Any open or closed issues related to this feature request?
Are you thinking about creating a pull request for this feature?
Yes. Planned as a separate PR track. Important for security/completeness, but lower priority than immediate feature rollout.
Overview of the Feature Request
Create a dedicated session-auth hardening track to protect session-cookie API usage without breaking existing token-based clients.
Scope of this hardening track:
Secure,HttpOnly, andSameSiteguidance with compatibility notes)./api/access/*behind the hardening flag.GETendpoints, scoped to session-cookie mode under the hardening flag:GET /api/datasets/{id}/uploadurlsGET /api/datasets/{id}/cleanStorageReason this is needed now:
GETendpoints increase CSRF exposure when cookies are automatically sent by browsers.What kind of user is the feature intended for?
Sysadmin, Depositor, Curator, API User
What inspired the request?
SessionID-based API support is needed for JSF/SAML-oriented integrations, but enabling session-auth should come with explicit, modern hardening controls.
What existing behavior do you want changed?
Current session-auth behavior is broad and lacks an explicit, opt-in hardening profile.
We want auth-mechanism-aware controls and CSRF defenses for session-cookie requests, while preserving existing behavior for apiKey/bearer/signed-url flows.
Any brand new behavior do you want to add to Dataverse?
Yes:
/api/access/*hardening gate.GETendpoints listed above (without broad API method rewrites in this issue).Any open or closed issues related to this feature request?
Are you thinking about creating a pull request for this feature?
Yes. Planned as a separate PR track. Important for security/completeness, but lower priority than immediate feature rollout.