Feature Request: Session-Cookie API Hardening with CSRF Protections and Mutating-GET Guardrails

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?

• https://github.com/IQSS/dataverse/issues/6691
• https://github.com/IQSS/dataverse/issues/12179
• https://github.com/IQSS/dataverse/pull/12097

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.

Review related issues 6691 and 12179 and pull request 12097 before assessing the proposed hardening track. Map the auth flow, feature-flag configuration, session-cookie handling, /api/access/*, and the two listed dataset endpoints; done means session-cookie CSRF and Origin/Referer controls are opt-in, while existing token flows and default behavior remain unchanged.