Dashboard hardening: session cookie missing Secure/SameSite and no HSTS header

[rauldpm]

Summary

Two small HTTP hardening gaps on the Wazuh dashboard (443), grouped here because they'd likely be addressed together: the authentication session cookie is set without the Secure and SameSite attributes, and the dashboard does not send a Strict-Transport-Security header (the manager API does). Neither is exploitable on its own, but both are cheap to close and are standard expectations for an HTTPS-only console.

Affected version

Wazuh dashboard 5.0.0 (dev packages built from the 5.0.0 branch, which carries the agent–manager HTTPS changes), served over TLS on 443 (server.ssl.enabled: true).

Steps to reproduce

# 1) Session cookie flags — log in and inspect Set-Cookie
curl -sk -D - -o /dev/null -X POST -H 'Content-Type: application/json' -H 'osd-xsrf: 1' \
  -d '{"username":"<user>","password":"<pass>"}' https://<DASHBOARD_IP>/auth/login | grep -i set-cookie

# 2) HSTS — inspect response headers
curl -sk -D - -o /dev/null https://<DASHBOARD_IP>/app/login | grep -i strict-transport-security

Expected behaviour

• The security_authentication session cookie should carry Secure (HTTPS-only app) and an explicit SameSite attribute.
• The dashboard should send Strict-Transport-Security on its responses, consistent with the API.

Actual behaviour

• Session cookie is set as security_authentication=<...>; HttpOnly; Path=/ — no Secure, no SameSite.
• No Strict-Transport-Security header is returned on 443 (the manager API on 55000 does send it).

Impact

• Missing Secure: the session cookie can be transmitted over a plaintext channel if a request is ever downgraded to HTTP, exposing it to interception.
• Missing SameSite: weaker CSRF defense-in-depth (the osd-xsrf token still applies, so this is layered, not sole, protection).
• Missing HSTS: leaves a downgrade / SSL-strip window on first or subsequent visits.

Suggested fix / mitigation

• Set the security-plugin cookie flags in opensearch_dashboards.yml: opensearch_security.cookie.secure: true and opensearch_security.cookie.isSameSite: Strict (or Lax).
• Emit Strict-Transport-Security from the dashboard responses (e.g. max-age=31536000; includeSubDomains), matching the API's posture.

Notes

Positive observations: the cookie is already HttpOnly, the dashboard sets X-Frame-Options: sameorigin and a Content-Security-Policy, and failed logins return 401. The CSP does allow unsafe-eval/unsafe-inline, which appears inherent to OpenSearch Dashboards and is out of scope here.

Context

Identified as part of black-box penetration-testing tasks against a 5.0 deployment

[rauldpm]

One more small header nit from the same pentest pass, while re-checking the dashboard responses: the 443 responses also omit X-Content-Type-Options: nosniff, so a response can still be MIME-sniffed by the browser. It's an easy add alongside the HSTS and cookie Secure/SameSite changes already tracked here.

Also minor, for the same header set: the CSP allows 'unsafe-eval' (script-src) and 'unsafe-inline' (style-src) and has no frame-ancestors/object-src/base-uri. Framing is already covered by X-Frame-Options: sameorigin, so this is lower priority — but worth tightening if it's feasible without breaking the app.

[rodrigofez]

Update

Verified state

Item	Result
Strict-Transport-Security	Not sent
X-Content-Type-Options	Not sent
X-Frame-Options	Sent (sameorigin)
security_authentication	No Secure. No SameSite
wz-token, wz-user	Secure correct. No SameSite
wz-api	No Secure. No SameSite

All the reported items are confirmed. The test also found a new defect: the wz-api cookie has no Secure flag, and none of the three Wazuh API cookies has a SameSite value. The pentest did not find these cookies, because the test had no login. This issue now includes them.

---

Change A — configuration file

Repository wazuh-dashboard. File config/opensearch_dashboards.prod.yml.

# HTTP protection.
# isSameSite controls the platform cookie and the Wazuh API cookies
# (wz-token, wz-user, wz-api). Use None only for a frame on a different
# web site; None needs HTTPS.
opensearch_security.cookie.secure: true
opensearch_security.cookie.isSameSite: Lax
server.customResponseHeaders:
  Strict-Transport-Security: 'max-age=31536000'
  X-Content-Type-Options: nosniff

• Use Lax, not Strict. Strict removes the cookie when a user opens a link from an e-mail or a report. Strict also stops the SAML login.
• Do not add includeSubDomains. This part can stop other web pages on related addresses. A browser keeps the instruction for one year. You cannot cancel it from the server.
• Do not add X-Frame-Options. The system sends this header already.
• If change C is accepted, delete the line opensearch_security.cookie.secure: true.

---

Change B — Wazuh cookies

Repository wazuh-dashboard-plugins. No new setting. The value comes from the security plugin, which gives its configuration in its setup contract (wazuh-security-dashboards-plugin/server/plugin.ts:174-177).

B.1 — plugins/main/server/types.ts:24

export type PluginSetup = {
  securityDashboards?: {
    config$?: Observable<{
      cookie: { isSameSite: 'Strict' | 'Lax' | 'None' | false };
    }>;
  };
  ...
};

This also completes the TODO on line 25.

B.2 — plugins/main/server/plugin.ts:677. The function setup is asynchronous already. Put this code near serverInfo on line 680.

const securityConfig = await plugins.securityDashboards?.config$
  ?.pipe(first())
  .toPromise();
let cookieSameSite = securityConfig?.cookie?.isSameSite || 'Lax';

// A browser refuses SameSite=None without Secure.
if (cookieSameSite === 'None' && serverInfo.protocol !== 'https') {
  this.logger.error(
    'cookie.isSameSite is None but the server does not use HTTPS. The value Lax is used.',
  );
  cookieSameSite = 'Lax';
}

Add cookieSameSite to the route handler context, with info: serverInfo.

B.3 — plugins/main/server/controllers/wazuh-api.ts:113-120

const textSameSite = `;SameSite=${context.wazuh.server.cookieSameSite}`;

'set-cookie': [
  `wz-token=${token};Path=/;HttpOnly${textSecure}${textSameSite}`,
  `wz-user=${encodedUser};Path=/;HttpOnly${textSecure}${textSameSite}`,
  `wz-api=${idHost};Path=/;HttpOnly${textSecure}${textSameSite}`,
],

The cookie wz-api now gets textSecure. This corrects the new defect.

Result:

Condition	Wazuh cookies
The operator sets isSameSite	The same value
The setting is absent	Lax
The security plugin is absent	Lax

---

Change C — optional

Repository wazuh-security-dashboards-plugin.

// server/index.ts:57
- secure: schema.boolean({ defaultValue: false }),
+ secure: schema.maybe(schema.boolean()),

// server/session/security_cookie.ts:76
- isSecure: config.cookie.secure,
+ isSecure: config.cookie.secure ?? isTlsListener,

Give the protocol from core.http.getServerInfo().protocol in server/plugin.ts:116. Also correct clearOldVersionCookieValue() on line 80. It uses the same value.

Reason: an operator who puts a proxy in front of the dashboard sets server.ssl.enabled: false. If the line cookie.secure: true stays in the configuration file, the login stops. The calculated value prevents this.

This change modifies a plugin from an external project. Accept it only with that cost.

---

Documents

• docs/ref/configuration.md (plugins). Add a section "Session cookies" after "Define Wazuh server hosts". Give: the two groups of cookies; that opensearch_security.cookie.isSameSite controls both groups; a table of the three values and their effects; that the system adds Secure automatically when the server uses HTTPS. Do not add a row in the settings table at the top — that table is for the settings that Wazuh adds.
• config/opensearch_dashboards.prod.yml (dashboard). The comment is in change A.
• docs/ref/upgrade.md (plugins), section "Upgrading the Wazuh dashboard". The package does not replace the configuration file. Write a manual step: add the lines from change A to the existing file.
• CHANGELOG.md in each repository that changes. Give a link to this issue.

---

Why Lax is safe

Chrome and Edge use Lax for a cookie without a SameSite value. They do this since the year 2020. Thus Lax is the behavior today. The change makes the behavior clear. It does not stop a user. An operator who needs a frame on a different web site can set None.