Testing SameSite, Secure, and Domain Cookie Behavior with Selenium

Selenium cookie testing for SameSite rules must verify browser policy, not merely cookie storage. addCookie can create a record and getCookieNamed can read it, yet a later request may omit that cookie because its site context, scheme, host, path, security, or expiry does not match.

Build cookie tests around controlled origins and a server echo. Navigate to the cookie's host, create one policy attribute at a time, cross the intended boundary, and assert what the receiving server observed. That structure separates WebDriver setup errors from browser enforcement and application behavior.

Trace the cookie policy decision

The official Selenium cookie examples begin by navigating to a domain before adding and reading cookies. That current address supplies the context in which the browser validates the new cookie.

The browser's cookie store and the request's Cookie header answer different questions. Keep them as two assertions so a failure identifies whether creation, retention, or transmission broke.

Establish a controlled origin matrix

Cookie policy is defined across scheme and site relationships, not arbitrary URLs. Use DNS names and HTTPS endpoints owned by the test environment, for example app.example.test, admin.example.test, and partner.other.test. Configure certificates trusted by the browser session instead of disabling security and calling the result representative.

Record the matrix before writing code: creation host, request initiator, destination host, navigation method, cookie attributes, expected storage, and expected server receipt. A top-level navigation and an embedded subresource do not necessarily exercise the same SameSite path. Test the product's actual interaction, such as an identity-provider return or embedded payment callback.

Include a control row whose cookie should unquestionably be sent and one whose cookie should unquestionably be withheld. Without controls, an empty receipt can mean either correct policy enforcement or a broken echo endpoint. Controls prove that DNS, TLS, redirects, and server rendering are functioning before the policy-specific assertion is interpreted.

Do not use a third-party public site as the cross-site initiator. Its redirects, headers, consent behavior, and availability are outside the suite's control and can change the very request context being tested.

Create cookies only from a valid domain context

Navigate to a lightweight HTTPS page on the target host, clear prior state, and build the cookie explicitly. Omitting domain creates host-scoped behavior based on the current host; providing it asks the browser to validate that domain against the current document.

import java.time.Instant;
import java.time.temporal.ChronoUnit;
import java.util.Date;
import org.openqa.selenium.Cookie;

driver.get("https://app.example.test/test/cookie-seed");
driver.manage().deleteAllCookies();

Cookie session = new Cookie.Builder("qa_session", "case-482")
    .domain("app.example.test")
    .path("/")
    .isSecure(true)
    .isHttpOnly(true)
    .sameSite("Strict")
    .expiresOn(Date.from(Instant.now().plus(10, ChronoUnit.MINUTES)))
    .build();

driver.manage().addCookie(session);

Use synthetic values rather than production tokens. HttpOnly limits script access, but WebDriver cookie commands can still inspect browser cookie state. That is useful for metadata assertions and should not be confused with an application script's capabilities.

Verify stored attributes without overclaiming

Read the cookie after creation and compare the attributes that matter to the case. This catches builder mistakes and browser rejection before the cross-site transition.

Cookie stored = driver.manage().getCookieNamed("qa_session");
if (stored == null) {
    throw new AssertionError("qa_session was not stored");
}
if (!stored.isSecure() || !"Strict".equals(stored.getSameSite())) {
    throw new AssertionError("Unexpected cookie policy: " + stored);
}
if (!"app.example.test".equals(stored.getDomain())) {
    throw new AssertionError("Unexpected cookie domain: " + stored.getDomain());
}

Domain serialization can expose normalized forms depending on how the cookie was created and returned. Assert the contract your browser matrix guarantees, not incidental punctuation. Likewise, avoid comparing expiry to an exact current timestamp; conversion and command latency make a tolerant range more appropriate.

Prove SameSite behavior through server receipt

To test Strict, Lax, or None, create a request context that actually challenges that policy. Navigate to the controlled external site, activate the same kind of link or form the product uses, and land on an endpoint at app.example.test that renders whether it received qa_session.

driver.get("https://partner.other.test/test/start-cookie-return");
driver.findElement(By.cssSelector("[data-testid='return-to-app']")).click();

WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));
wait.until(ExpectedConditions.urlContains("app.example.test/test/cookie-result"));

String receipt = wait.until(ExpectedConditions.visibilityOfElementLocated(
    By.cssSelector("[data-testid='server-cookie-receipt']")
)).getText();

Assert receipt against the row in the planned matrix. Do not derive expected behavior from whether getCookieNamed still returns the cookie afterward. A cookie may remain stored while being withheld from a particular request.

SameSite=None belongs in a secure test because browsers enforce security constraints on cross-site cookie use. If the browser refuses an invalid attribute combination, treat that as policy evidence and capture the returned cookie state and browser logs rather than weakening the setup.

Test Secure, domain, and path independently

A Secure test needs both an HTTPS success path and an intentionally non-secure path in an isolated environment. The assertion should be server receipt, not merely that the cookie object says secure: true. Do not expose real credentials over HTTP to create a negative case.

For domain scope, compare a host-only cookie on app.example.test with a valid domain cookie when moving to admin.example.test. The expected result should follow the application's domain design and browser rules. An unrelated domain must never receive it.

For path scope, request both an included route such as /account/profile and an excluded route such as /public/status. Path is a request-selection rule, not a security boundary against other application code. Keep security conclusions focused on what the browser sends.

Changing one attribute per test reduces ambiguity. A single case that crosses scheme, site, subdomain, path, and expiry can fail correctly for five different reasons while reporting only one missing cookie.

Exercise expiry and session lifetime carefully

A cookie without an expiry is session-scoped from the cookie model's perspective. Testing its lifetime by restarting a browser can be complicated by profile restoration, so use fresh isolated profiles and state the product expectation clearly.

For explicit expiry, create one cookie safely in the future and another already expired. Verify that the future cookie is stored and received on an in-scope request. Verify that the expired cookie is absent or not transmitted according to the browser's observable behavior. Avoid sleeping across a near-future boundary; remote latency makes that test inherently unstable.

Deleting a named cookie should be followed by a server-observed request if the application consequence matters. deleteCookieNamed proving local absence is useful setup evidence but does not validate cached UI state or a server session that remains active by another mechanism.

Diagnose policy failures with layered evidence

Start with the current URL and creation host. An invalid cookie domain error usually points to a mismatch or a document that cannot accept cookies. Next inspect the stored cookie's domain, path, SameSite, Secure, HttpOnly, and expiry values. Then inspect the exact request path and initiator that should have carried it.

If storage succeeds and server receipt fails, the browser may be correctly enforcing policy, the request may not match the intended context, or an intermediary may have altered the flow. Capture sanitized server headers and redirect history. If the server receives the cookie but the UI remains signed out, move the investigation to application session validation rather than changing cookie attributes.

Run policy cases on the supported browser matrix. Differences should remain visible as named compatibility findings, not be flattened by JavaScript injection or direct HTTP requests that bypass browser selection rules.

Keep browser profile settings in the report as well. Privacy controls, enterprise policy, and disabled third-party storage can affect the observed path even when the cookie attributes are identical. The test result should identify the browser capability and environment policy so a deliberate restriction is not mistaken for an application regression.

Apply a cookie policy checklist

• Use controlled HTTPS origins with trusted test certificates.
• Navigate to the intended host before adding a cookie.
• Clear prior cookies or start with an isolated browser profile.
• Set and verify each relevant attribute explicitly.
• Separate storage assertions from request-transmission assertions.
• Use a server endpoint to reveal sanitized cookie receipt.
• Change one policy dimension per focused test.
• Keep negative cases free of real credentials.
• Avoid timing tests near an expiry boundary.
• Preserve redirect, request, browser, and server evidence on failure.

Close on observable browser policy

A cookie object in WebDriver is setup evidence, not proof of authentication or cross-site delivery. Create the right origin context, challenge one policy rule, and let a controlled server reveal what the browser actually sent. That is the difference between testing cookie metadata and testing cookie behavior.