Debug mode: Marks UMB-DEBUG cookie as HttpOnly and Secure

[iOvergaard]

Summary

This PR addresses a security scanning alert about the debug profiling cookie and improves the overall cookie handling:

• Fixes security issue: The UMB-DEBUG cookie now respects the UseHttps setting instead of hardcoding Secure=false
• Adds httpOnly flag: Prevents JavaScript access to the cookie (XSS mitigation)
• Uses SameSite=Strict: Limits cookie to same-site requests only
• Converts to session cookie: No longer persists for 1 year; deleted when browser closes
• Refactors to use ICookieManager: Improves encapsulation and consistency
• Adds status verification: Frontend now verifies the cookie was actually set and warns users if it fails (e.g., cross-site scenario)

Fixes https://github.com/umbraco/Umbraco-CMS/security/code-scanning/1730

Changes

Backend:

• Replaced direct HttpContext.Response.Cookies usage with ICookieManager
• Cookie now uses secure: _globalSettings.UseHttps instead of secure: false
• Added httpOnly: true and sameSiteMode: "Strict"
• Removed 1-year expiration (now a session cookie)

Frontend:

• Added verification that the profiler status was actually changed
• Shows warning notification when toggle fails (explains same-site limitation)
• Added loading state during toggle operation
• Replaced unsafeHTML with umb-localize components

Note on SameSite=Strict

Because the cookie uses SameSite=Strict, it only works when the BackOffice and front-end share the same domain. For cross-site setups (e.g., headless), users can use ?umbDebug=true query string or X-UMB-DEBUG header instead.

Test steps

Cross-site scenario (should show warning)

1. Run the BackOffice using Vite's dev server (npm run dev in the client folder)
2. Navigate to Settings → Performance Profiling
3. Toggle the "Activate the profiler by default" switch ON
4. Expected: A warning notification appears explaining the cookie could not be set because the BackOffice and front-end are on different URLs

Same-site scenario (should work)

1. Run Umbraco normally (not using Vite's dev server)
2. Navigate to Settings → Performance Profiling
3. Toggle the "Activate the profiler by default" switch ON
4. Expected: Toggle stays ON, no warning
5. Toggle the switch OFF
6. Expected: Toggle stays OFF, no warning
7. Close and reopen the browser
8. Expected: Toggle is OFF (session cookie was deleted)

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR addresses a security vulnerability by improving the security configuration of the UMB-DEBUG cookie used for performance profiling. The changes ensure the cookie follows security best practices (HttpOnly, Secure based on settings, SameSite=Strict, session-only) and refactors the implementation to use ICookieManager for better encapsulation. The frontend is enhanced with proper verification that cookie operations succeed and provides user feedback when they fail due to cross-site restrictions.

Key Changes:

• Improved cookie security settings (HttpOnly, dynamic Secure flag, SameSite=Strict, session cookie)
• Refactored backend to use ICookieManager abstraction instead of direct cookie manipulation
• Enhanced frontend with status verification and user-friendly error notifications

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
src/Umbraco.Web.Common/Repositories/WebProfilerRepository.cs	Refactored to use ICookieManager with secure cookie settings (HttpOnly, dynamic Secure, SameSite=Strict) and removed persistent expiration
src/Umbraco.Web.UI.Client/src/packages/performance-profiling/dashboard-performance-profiling.element.ts	Added verification of profiler status changes, loading states, error notifications, and replaced unsafeHTML with umb-localize components
src/Umbraco.Web.UI.Client/src/assets/lang/en.ts	Added new error message localization strings and updated description to mention same-site limitation

[AndyButland]

Looks good @iOvergaard and all works as expected. Toggle status is retained, the cookie is set with the appropriate settings and it works to enabled debug mode when browsing the front-end of the website.

I'll cherry-pick this back for 16.5 too.

[AndyButland]

@iOvergaard - I've cherry-picked this over for 16.5 in the commit you can see linked above. I just had to rework how the context was consumed on the client. I think it's all good and have tested it out, but if you want to take a look please do.

[iOvergaard]

All good, @AndyButland !