Fixing Wazuh API SameSite Cookie Errors

A common failure mode in Wazuh deployments is a user being able to reach the login page of the dashboard, successfully authenticate, and then immediately being redirected back to the login screen or left in a partially loaded state.

In other cases, the session appears to succeed, but API-driven components fail with intermittent 401 or 403 responses.

These symptoms are often grouped under “authentication instability,” but a frequent underlying cause is cookie policy enforcement at the browser level, specifically related to the SameSite attribute.

Where the problem typically appears (Wazuh dashboard / browser login flow)

This issue is most visible in the Wazuh Dashboard authentication flow, where the browser is responsible for maintaining session state via cookies issued by the Wazuh API layer.

It typically manifests during:

• Initial login to the Wazuh Dashboard UI
• Session persistence across page refreshes
• API-backed requests from the dashboard frontend

When cookies are not stored or are rejected by the browser, the dashboard loses session continuity, causing authentication loops or silent failures in UI components.

Why SameSite cookie policies matter in modern browsers

Modern browsers enforce stricter default cookie policies to mitigate cross-site request forgery (CSRF) and cross-origin tracking.

The SameSite attribute controls whether cookies are sent with cross-site requests:

• Strict → only same-site requests
• Lax → limited cross-site GET navigation allowed
• None → cookies sent in all contexts, but must be Secure

If a system like Wazuh does not explicitly set compatible cookie attributes, browsers may silently block or downgrade session cookies, breaking authentication flows.

Key references on modern cookie enforcement:

• MDN Web Docs – SameSite cookies: MDN SameSite Cookies
• Google Chrome cookie changes overview: Google Chrome SameSite Updates
• RFC 6265bis draft (cookie standards evolution): IETF Cookie Spec Update

Context: Wazuh authentication architecture (API ↔ dashboard session handling)

Wazuh uses a layered authentication model where the Dashboard relies on the Wazuh API for identity validation and session issuance.

The flow generally looks like:

1. User authenticates via the Wazuh Dashboard
2. Dashboard forwards credentials to the Wazuh API
3. API issues a session token or cookie
4. Browser stores the cookie and attaches it to subsequent requests
5. Dashboard UI consumes API responses using that session context

When cookie policies interfere with step 4, the API may still authenticate successfully, but the browser never retains a valid session, resulting in repeated login prompts or broken dashboard rendering.

For related authentication troubleshooting, see:

• Wazuh API Authentication Failed? Causes and Solutions
• Wazuh Dashboard Not Loading? Complete Troubleshooting Guide

Understanding the Wazuh API SameSite Cookie Error

What the SameSite cookie attribute is (Lax, Strict, None)

The SameSite attribute defines how cookies behave in cross-origin HTTP requests:

• Strict: Cookies are only sent in first-party contexts. Cross-site navigation blocks them entirely.
• Lax: Cookies are sent on top-level navigations (e.g., clicking a link), but not on most embedded requests (AJAX, iframes).
• None: Cookies are sent in all contexts, including cross-site requests, but must also include the Secure flag.

In modern browser security models, SameSite=Lax is the default if not explicitly specified, which can unintentionally break authentication flows that depend on cross-origin API interactions.

How browsers enforce SameSite rules in modern versions (Chrome, Edge, Firefox)

Modern Chromium-based browsers and Firefox enforce stricter interpretation of cookie rules:

• Cookies without explicit SameSite=None; Secure may be downgraded or rejected
• Cross-site API calls from dashboards are often treated as third-party contexts
• Secure-only cookies are required when using SameSite=None

This enforcement has become more aggressive with privacy-focused updates in recent browser releases, making previously “working by default” configurations fail silently.

How Wazuh API authentication relies on session cookies

The Wazuh API issues authentication artifacts (session cookies or tokens) that the dashboard relies on for:

• Maintaining logged-in state
• Authorizing API requests from UI components
• Preserving session continuity across refreshes

If the browser blocks or strips the cookie due to SameSite restrictions, the API may still return a successful authentication response, but the session is never persisted client-side.

Typical symptoms

When this issue occurs, you will typically observe:

• Dashboard login redirect loops (immediate return to login screen)
• API session not persisting after authentication
• 401 Unauthorized or 403 Forbidden errors after successful login
• Blank or partially loading dashboard UI components
• Intermittent API failures despite correct credentials

For related API-level authentication issues, see: Wazuh Agent Not Connecting to Manager? 12 Proven Fixes.

Root Causes of the Error

Missing or incorrect SameSite=None; Secure configuration

The most frequent root cause is that cookies are being issued without the correct combination:

SameSite=None; Secure

Without this, modern browsers may:

• Reject the cookie entirely
• Downgrade it to Lax
• Block it in cross-site contexts

This breaks Wazuh dashboard authentication flows that rely on cross-origin API interactions.

HTTP vs HTTPS mismatch in Wazuh stack

If parts of the Wazuh stack are served over HTTP while others use HTTPS:

• Browsers may reject Secure cookies entirely
• Session cookies may not be transmitted between components
• Mixed-origin behavior can trigger silent authentication failures

This is especially common in deployments where the dashboard is behind a TLS termination proxy but the API remains internal over HTTP.

Reverse proxy misconfiguration (Nginx / Apache)

Incorrect reverse proxy headers can interfere with cookie handling:

• Missing X-Forwarded-Proto
• Incorrect host header rewriting
• Stripping Set-Cookie headers
• Improper TLS termination handling

These misconfigurations often result in cookies being generated for the wrong domain or protocol context, causing them to be ignored by the browser.

Outdated Wazuh Dashboard or API version mismatch

Version mismatches between components can introduce inconsistencies in:

• Cookie generation logic
• Session handling mechanisms
• API authentication expectations

Older versions may not fully comply with modern browser cookie standards, leading to intermittent or persistent authentication failures.

Browser updates enforcing stricter cookie rules

Recent browser updates have tightened enforcement of:

• Third-party cookie blocking
• SameSite default behaviors
• Secure-only cookie policies

Even previously working Wazuh configurations may break after browser upgrades without any backend changes.

Incorrect wazuh.yml or API configuration settings

Misconfigured API or dashboard settings can result in:

• Missing cookie flags
• Incorrect session domain configuration
• Improper authentication backend settings

These issues typically originate from manual configuration overrides or incomplete deployment templates.

Load balancer stripping cookie headers

In some architectures, load balancers may:

• Drop Set-Cookie headers unintentionally
• Rewrite headers without preserving cookie attributes
• Normalize traffic in a way that breaks session affinity

This leads to inconsistent authentication behavior across requests, especially in multi-node Wazuh deployments.

How Wazuh Uses Cookies in the Dashboard Authentication Flow

Login request flow: dashboard → API → token/session response

Wazuh’s authentication model is a typical API-backed session system where the dashboard acts as a client to the Wazuh API:

1. User submits credentials via the Wazuh Dashboard UI
2. Dashboard forwards credentials to the Wazuh API endpoint
3. API validates credentials against its internal authentication backend
4. API returns a session token and/or Set-Cookie header
5. Browser stores the cookie and attaches it to subsequent requests

At this stage, authentication is not “complete” unless the browser successfully persists and returns the cookie on every API call.

Role of cookies in maintaining authenticated sessions

Cookies in Wazuh are primarily responsible for:

• Persisting session identity across page reloads
• Authorizing API requests from the dashboard frontend
• Maintaining state for the user session without re-authentication

Unlike token-only systems (e.g., pure JWT in localStorage), Wazuh’s dashboard relies heavily on cookie-based session continuity.

If cookies fail, the system effectively loses track of authentication state even if the API still considers the login valid.

Interaction between Wazuh API and web frontend session storage

The dashboard frontend does not directly “own” authentication. Instead:

• The browser stores the session cookie issued by the API
• Each frontend API request automatically includes that cookie
• The API validates the cookie and returns authorized responses

This tight coupling means any disruption in cookie handling breaks the entire UI flow, especially for dynamic components like alerts, agents, and security events.

Why SameSite restrictions break cross-origin API flows

SameSite enforcement becomes critical when:

• Dashboard and API are served from different subdomains
• Reverse proxies change request origins
• HTTPS termination occurs at a load balancer

If cookies are not explicitly set to:

SameSite=None; Secure

modern browsers will:

• Block the cookie entirely in cross-site requests
• Prevent it from being sent on AJAX/API calls
• Cause silent authentication failures (no explicit error shown)

This results in the classic Wazuh symptom: successful login followed by immediate session loss.

Step-by-Step Fix for Wazuh API SameSite Cookie Error

Verify HTTPS Configuration

Before adjusting cookie behavior, ensure the transport layer is correctly secured.

• Confirm the Wazuh dashboard is served via HTTPS only
• Install and validate a trusted SSL/TLS certificate (Let’s Encrypt or enterprise CA)
• Redirect all HTTP traffic to HTTPS using 301 redirects

This is mandatory because SameSite=None cookies require the Secure flag, which only works over HTTPS.

Update Wazuh API Cookie Settings

Next, ensure the API is explicitly issuing compliant cookies.

Steps:

• Locate Wazuh API configuration files (commonly under /var/ossec/api/configuration/ or /etc/wazuh-api/)
• Modify cookie/session settings to include:

SameSite=None
Secure=true

• Ensure session cookies are not being overwritten by defaults or legacy configs
• Restart the Wazuh API service after changes:

systemctl restart wazuh-api

This ensures updated cookie headers are applied consistently.

Fix Reverse Proxy Configuration

Reverse proxy issues are one of the most common hidden causes.

Ensure your proxy (Nginx/Apache) correctly preserves authentication headers:

• Set-Cookie must not be stripped or rewritten
• Authorization headers must be passed through unchanged
• WebSocket/API upgrade routes must be explicitly supported

Example requirements:

• Correct proxy_set_header configuration
• Proper handling of /api and /security endpoints
• Accurate X-Forwarded-Proto header propagation

Misconfigured proxies often cause cookies to be issued for the wrong domain or protocol, rendering them unusable.

Browser-Side Validation

After backend fixes, validate behavior on the client side:

• Clear all cookies for the Wazuh domain
• Test login in incognito/private mode
• Inspect cookies via DevTools:
  • Application → Cookies → domain check
  • Confirm SameSite=None and Secure are present
• Observe Network tab for Set-Cookie responses

If cookies are missing or altered in transit, the issue is still server/proxy-side.

Update Wazuh Components

Version mismatches frequently introduce inconsistent authentication behavior.

Ensure all components are aligned:

• Wazuh Manager
• Wazuh API
• Wazuh Dashboard

Upgrading ensures:

• Consistent cookie handling logic
• Compatibility with modern browser security policies
• Fixed authentication/session bugs in newer releases

If upgrading, validate compatibility matrix before deployment to avoid breaking API contracts.

Related Guides:

How to Upgrade a Wazuh Agent
Fix Authd Registration Failures: Wazuh Agent Password Mismatched Guide

Debugging the Error

Using browser DevTools (Network tab → cookie inspection)

Start with the browser:

• Open DevTools → Network tab
• Perform login action
• Inspect API responses for Set-Cookie headers
• Confirm cookies are stored under correct domain/path

Key checks:

• Is SameSite=None present?
• Is Secure present?
• Is the cookie being rejected silently?

Checking API logs for authentication failures

On the Wazuh API server:

• Review authentication logs for failed session creation
• Look for repeated login attempts without session persistence
• Check for warnings related to cookie or header generation

These logs typically reveal whether the API is issuing cookies correctly or failing before they are sent.

Reviewing dashboard logs for session rejection messages

The Wazuh dashboard may log:

• Session initialization failures
• Unauthorized API responses
• Token validation errors

These logs help distinguish between:

• Cookie not being set (server-side issue)
• Cookie being set but not returned (browser policy issue)

Verifying headers with curl

You can validate API behavior outside the browser:

curl -I https://your-wazuh-api:55000

Check for:

• Set-Cookie header presence
• Proper SameSite=None; Secure attributes
• Correct domain and path scoping

If curl shows correct headers but the browser fails, the issue is almost certainly browser policy enforcement or proxy stripping.

Common Misconfigurations That Trigger the Issue

Running dashboard over HTTP in production

One of the most frequent misconfigurations is exposing the Wazuh Dashboard over plain HTTP in production environments.

This directly conflicts with modern browser cookie rules when SameSite=None; Secure is expected.

If the dashboard is served over HTTP:

• Secure cookies are silently rejected by browsers
• Session cookies are not persisted
• Authentication appears to “succeed” but immediately collapses

This creates a misleading symptom where the API is functioning correctly, but the browser refuses to maintain state.

In production deployments, HTTPS is not optional, it is a functional requirement for session-based authentication to work correctly.

Missing reverse proxy SSL termination

In many Wazuh deployments, TLS is terminated at a reverse proxy (Nginx, Apache, or a cloud load balancer).

Misconfigurations here are a primary cause of cookie breakage.

Typical issues include:

• TLS terminated incorrectly or inconsistently
• Backend services receiving HTTP while the client uses HTTPS
• Missing X-Forwarded-Proto header
• Cookies generated with the wrong scheme context

When the API believes the request is HTTP, it may issue cookies without the required Secure flag, causing browsers to reject them.

Multiple conflicting cookie policies across services

In distributed Wazuh architectures, different components may define different cookie behaviors:

• API enforcing SameSite=Lax
• Dashboard expecting SameSite=None
• Reverse proxy rewriting or stripping headers

This inconsistency leads to non-deterministic authentication behavior, some requests succeed while others fail depending on which component handled the session.

Standardization across all layers is required for stable authentication.

Misconfigured base URL in Wazuh dashboard settings

If the dashboard baseURL or public-facing URL is incorrectly configured:

• Cookies may be scoped to the wrong domain
• Sessions may not be shared between API and UI
• Redirect loops can occur after login

This is especially common when:

• Migrating from localhost to production
• Introducing a reverse proxy without updating config
• Changing domain names without clearing old sessions

A mismatch between the configured base URL and the actual access URL almost always results in silent session failures.

Related Guide: Wazuh Dashboard Not Loading? Complete Troubleshooting Guide

Advanced Fixes (Enterprise / Complex Deployments)

Load balancer sticky session configuration

In multi-node Wazuh environments behind a load balancer, lack of session affinity can break authentication consistency.

To stabilize sessions:

• Enable sticky sessions (session persistence) at the load balancer layer
• Ensure session cookies are consistently routed to the same backend node
• Avoid round-robin balancing for authenticated API traffic

Without stickiness, one node may issue a valid session while another node fails to recognize it, resulting in intermittent login loops.

Cross-domain authentication adjustments

Enterprise deployments often split services across domains or subdomains:

• dashboard.company.com
• api.company.com

In these cases, cookie handling must explicitly support cross-domain authentication:

• Cookies must use SameSite=None; Secure
• Domain scoping must be carefully defined (or omitted where appropriate)
• CORS headers must allow credentialed requests

Improper cross-domain configuration is one of the most common causes of persistent authentication failures in scaled deployments.

Reference:

OWASP Session Management guidance: OWASP Session Management Cheat Sheet

Centralized authentication integration (SSO / SAML considerations)

When integrating Wazuh with enterprise identity providers (Keycloak, Azure AD, Okta), cookie behavior becomes secondary to token exchange, but still critical for session bridging.

Key risks include:

• Identity provider issues tokens that are not compatible with Wazuh session handling
• Redirect-based authentication flows losing cookies due to SameSite restrictions
• Mismatched session lifetimes between IdP and Wazuh API

To mitigate:

• Ensure IdP redirects are treated as top-level navigation (Lax-safe flows where possible)
• Validate cookie persistence after SSO callback
• Align session expiration policies across systems

Handling multi-node Wazuh clusters

In clustered deployments, authentication consistency depends on all nodes sharing session context.

Common pitfalls:

• Nodes issuing different cookie attributes
• Indexer/API nodes not synchronized
• Uneven configuration drift across cluster members

Best practices:

• Centralize configuration management (Ansible, Terraform, etc.)
• Ensure identical API and dashboard versions across nodes
• Validate session behavior after node failover

Related Guides:

• How to Build a Wazuh Indexer Cluster
• Fix Wazuh Docker Compose Deployment

Prevention Best Practices

Always enforce HTTPS in production Wazuh deployments

HTTPS is not optional for modern Wazuh deployments, it is a dependency for authentication stability.

Ensure:

• All traffic is redirected from HTTP → HTTPS
• Valid certificates are installed and renewed automatically
• No internal services expose insecure endpoints externally

This directly ensures compatibility with SameSite=None; Secure cookie requirements.

Standardize cookie policy settings across services

Inconsistent cookie behavior is a primary source of authentication instability.

Standardization should include:

• Uniform SameSite=None usage where cross-origin flows exist
• Consistent Secure enforcement across API and dashboard
• Centralized configuration templates for all nodes

This prevents edge-case authentication failures in distributed environments.

Keep Wazuh components updated

Version drift between components can silently introduce authentication bugs.

Maintain alignment across:

• Wazuh Manager
• Wazuh API
• Wazuh Dashboard
• Indexer stack

Upgrades often include fixes for session handling and browser compatibility improvements.

Validate browser compatibility after upgrades

After any upgrade:

• Test login flows in Chrome, Firefox, and Edge
• Inspect cookies via DevTools
• Confirm no silent blocking of session cookies

Browser updates can introduce stricter enforcement without any backend changes, making regression testing essential.

Monitor authentication logs for early detection

Proactive monitoring reduces downtime caused by authentication failures.

Monitor:

• Repeated login attempts without session persistence
• API responses returning 401 immediately after login
• Cookie generation warnings in API logs

Early detection allows you to catch configuration drift before it becomes a full dashboard outage.

Related Guide:
How to Fix Wazuh Active-Response Error 1204

FAQ

Question: What causes Wazuh API SameSite cookie errors?

Wazuh API SameSite cookie errors are primarily caused by browsers rejecting or restricting session cookies due to missing or incompatible SameSite attributes.

The most common triggers include:

• Cookies not explicitly set to SameSite=None; Secure
• HTTP-based deployments where Secure cookies are invalid
• Reverse proxies modifying or stripping cookie headers
• Browser enforcement of stricter cross-site cookie rules

In most cases, the API is functioning correctly, the failure occurs at the browser’s cookie storage layer.

Question: Why does the dashboard keep logging me out?

This behavior typically indicates that session cookies are not being persisted or returned on subsequent requests. When the dashboard logs you out immediately after login, it usually means:

• The authentication cookie was never stored by the browser
• The cookie was stored but not sent on follow-up API requests
• The session is being invalidated due to domain or protocol mismatch

This is almost always tied to SameSite enforcement or proxy misconfiguration rather than incorrect credentials.

Question: Do browser updates affect Wazuh authentication?

Yes. Modern browser updates frequently tighten cookie handling rules without requiring any changes on the server side.

Key impacts include:

• Stricter enforcement of SameSite defaults
• Blocking of third-party or cross-site cookies
• Increased reliance on HTTPS for secure cookie transmission

This means a previously working Wazuh deployment can break after a browser update even if no backend changes were made.

Question: Can reverse proxy settings break Wazuh login sessions?

Yes, reverse proxies are one of the most common causes of authentication failures in Wazuh deployments.

Misconfigurations can:

• Strip or alter Set-Cookie headers
• Break Secure flag propagation
• Misrepresent request protocol (HTTP vs HTTPS)
• Prevent proper domain scoping of session cookies

Even small proxy misconfigurations can completely disrupt session persistence.

Related Guide: Fixing Wazuh 502 Bad Gateway: Troubleshooting Guide

Is HTTPS required to fix SameSite cookie issues?

Yes. HTTPS is mandatory when using SameSite=None; Secure cookies.

Without HTTPS:

• Secure cookies are rejected by browsers
• Sessions will not persist reliably
• Authentication flows break silently

Modern browsers strictly enforce this rule, making HTTPS a non-negotiable requirement for Wazuh dashboard authentication.

Which Wazuh logs show authentication cookie errors?

Authentication-related issues can be identified in multiple log sources:

• Wazuh API logs → session creation, authentication failures
• Wazuh Dashboard logs → session rejection, login loop behavior
• Browser DevTools (Network tab) → missing or rejected Set-Cookie headers

Look for patterns such as:

• Repeated 401 Unauthorized responses after login
• Missing session tokens in API responses
• Authentication retries without persistent session state

How do I verify cookie settings in the Wazuh API response?

You can verify cookie behavior using browser tools or CLI:

Browser DevTools:

• Open Network tab
• Perform login request
• Inspect response headers for Set-Cookie

Check for:

• SameSite=None
• Secure flag
• Correct domain/path scoping

Using curl:

curl -I https://your-wazuh-api:55000

Verify that:

• Set-Cookie header is present
• Cookie attributes include correct SameSite and Secure flags

If curl shows correct headers but the browser fails, the issue is almost certainly browser policy enforcement or proxy interference.

Question: Will upgrading Wazuh fix SameSite cookie problems automatically?

Not always, but it can help.

Upgrades may:

• Fix outdated cookie handling logic
• Improve compatibility with modern browsers
• Resolve known authentication/session bugs

However, upgrading alone will not fix issues caused by:

• Incorrect reverse proxy configuration
• Missing HTTPS enforcement
• Misconfigured base URLs
• Load balancer header manipulation

In most cases, upgrades must be combined with configuration corrections to fully resolve SameSite-related issues.

Related Guide:
Wazuh Vulnerability Detection Not Working? Here’s How to Fix It

Conclusion

Wazuh API SameSite cookie errors are not caused by a single bug but by a convergence of browser security enforcement, deployment architecture, and configuration inconsistencies.

As modern browsers increasingly restrict cross-site cookie behavior, authentication systems that rely on session cookies must explicitly declare compatible attributes such as SameSite=None; Secure and operate fully over HTTPS.

In practice, most failures stem from one or more of the following:

• Missing HTTPS enforcement across the stack
• Reverse proxy misconfiguration altering cookie headers
• Inconsistent cookie policies between Wazuh components
• Browser-level rejection of insecure or cross-site cookies
• Version mismatches introducing outdated session handling behavior

Resolving the issue requires a layered approach: validating API configuration, ensuring proxy correctness, enforcing secure transport, and verifying client-side behavior using browser tools.

For long-term stability, Wazuh deployments should treat authentication behavior as an infrastructure concern rather than a purely application-level setting.

Standardizing cookie policies, enforcing HTTPS, and maintaining consistent versions across components significantly reduces the likelihood of recurrence.