Describe the bug

After enabling Django CSRF protection, Django sets a csrftoken cookie on responses. However, the CSRF_COOKIE_SECURE Django setting is not configured, so it defaults to False. This means the CSRF cookie is not marked as Secure, even when needs_tls = yes is configured in webfront.conf.

The session cookie correctly gets the Secure flag via SESSION_COOKIE_SECURE = _needs_tls in settings.py, but the CSRF cookie was overlooked.

Without the Secure flag, the browser may be tricked into sending the CSRF token over an unencrypted connection (e.g. via a malicious link to the HTTP version of the site), potentially exposing it to interception.

To Reproduce

1. Set needs_tls = yes in webfront/webfront.conf under the [security] section
2. Load any NAV page in a browser
3. Inspect the cookies set by the response (e.g. via browser DevTools → Application → Cookies)
4. Observe that nav_sessionid has the Secure flag, but csrftoken does not

Expected behavior

When needs_tls = yes, both the session cookie (nav_sessionid) and the CSRF cookie (csrftoken) should have the Secure flag set.

Additional context

The fix is to add CSRF_COOKIE_SECURE = _needs_tls alongside the existing SESSION_COOKIE_SECURE = _needs_tls in python/nav/django/settings.py.