DEV Community: Faqih

Bypassing Secure Cookie Limitation in WebKit for Localhost Playwright Testing

Faqih — Wed, 25 Mar 2026 12:14:11 +0000

Cookie have one of the most crucial attribute, the Secure attribute. This Secure attribute is an option that the server can set when sending cookies to users over HTTP. The purpose of this attribute is to prevent unauthorized access to cookies because they are sent in plain text—thus, browsers that support the Secure attribute will only send/set cookies when requesting a page or resource that uses HTTPS (encrypted).

In practice, if you create a web application that can run on all browsers, there will be issues when trying to run it on browsers with the WebKit engine, such as Safari. One bug report mentions inconsistent behavior in WebKit when determining whether localhost is a secure origin. This report is also supported by the consensus status and standardization of the feature to treat localhost or loopback address as secure context in Chrome Platform Status which states that WebKit still does not support it.

To address this issue during development, there are several ways to address it, such as:

Configuring HTTPS for local development
Conditionally sending the Secure attribute based on the origin of the request
Installing a proxy server to modify cookies before sending them to the client

If you tried the simplest example, configuring HTTPS locally, your secure cookie should now be set properly in Safari. However, a different configuration is required if you're using end-to-end, cross-browser testing like Playwright in your CI/CD. Well, it's quite possible to do the same thing to configure HTTPS in CI/CD as mentioned in this article—but we need to do something simpler: keep using localhost without HTTPS and configure our existing test suites, in this case using Playwright.

For other E2E framework like Cypress, you should be able to adapt by finding the equivalent configuration

The example case for this article is an end-to-end test for a to-do list application I created where the authentication uses HttpOnly and Secure cookies which will fail when run in Safari. For this, we can utilize project dependencies and create a setup for each browser, where each browser will have a different user account.

Getting to know projects in Playwright

Playwright has something called projects. A project is a way to group tests that will run with the same configuration. Projects are used to run tests on different browsers and devices. This is what we use to test whether our web application runs normally in most browsers (Chrome, Firefox, and Safari).

Here's an example for a project configuration in Playwright:

import { defineConfig, devices } from "@playwright/test";

export default defineConfig({
  projects: [
    {
      name: "chromium",
      use: { ...devices["Desktop Chrome"] },
    },

    {
      name: "firefox",
      use: { ...devices["Desktop Firefox"] },
    },

    {
      name: "webkit",
      use: { ...devices["Desktop Safari"] },
    },

    /* Test against mobile viewports. */
    {
      name: "Mobile Chrome",
      use: { ...devices["Pixel 5"] },
    },
    {
      name: "Mobile Safari",
      use: { ...devices["iPhone 12"] },
    },

    /* Test against branded browsers. */
    {
      name: "Microsoft Edge",
      use: {
        ...devices["Desktop Edge"],
        channel: "msedge",
      },
    },
    {
      name: "Google Chrome",
      use: {
        ...devices["Desktop Chrome"],
        channel: "chrome",
      },
    },
  ],
});

Additionally, there are also project dependencies that are usually used for setup before running all tests on project. This setup is useful for configuring authentication.

Creating setup for each browser

The first step is to create a setup for each browser. This setup is essentially just an abstraction of the authentication setup, where the authentication flow is defined, except we need a different storage location for each browser and to modify the behavior of that particular browser—in this case, Safari.

Create several setup files like the following:

my-app/
├─ tests/
│  ├─ auth.setup.ts
│  ├─ chromium.setup.ts
│  ├─ firefox.setup.ts
│  ├─ webkit.setup.ts

Making authentication setup an abstraction

In the auth.setup.ts file, we will create a function that will abstract the entire authentication flow plus a callback to add modifications to the authentication flow if needed.

import { test as setup, expect, type Page } from "@playwright/test";

type SetupAuth = {
  email: string;
  password: string;
  authStorePath: string;
  alterStoreCallback?: ({ page }: { page: Page }) => Promise<void>;
};

export function setupAuth({ email, password, authStorePath, alterStoreCallback }: SetupAuth) {
  setup.describe.configure({ mode: "serial" });
  setup.describe("Authentication", () => {
    setup("Register", async ({ page }) => {
      await page.goto("/register");
      await page.getByLabel("Email").fill(email);
      await page.getByLabel("Password").fill(password);
      await page.getByRole("button", { name: "Create account" }).click();
      await page.waitForURL("/login");

      await expect(page.getByText("Login to your account", { exact: true })).toBeVisible();
    });

    setup("Login", async ({ page }) => {
      await page.goto("/login");
      await page.getByLabel("Email").fill(email);
      await page.getByLabel("Password").fill(password);
      await page.getByRole("button", { name: "Login" }).click();
      await page.waitForURL("/todo");

      await expect(page.getByText("To-Do", { exact: true })).toBeVisible();
      await expect(page.getByText("Please, do something.", { exact: true })).toBeVisible();

      await alterStoreCallback?.({ page });
      await page.context().storageState({ path: authStorePath });
    });
  });
}

The setupAuth function will be exported and used in the setup file for each browser. This allows us to define where Playwright will store the auth state for each browser, as well as to modify that auth state.

Updating `playwright.config.ts`

We need to ensure that each of the projects is paired with its appropriate dependency.

import path from "node:path";
import { defineConfig, devices } from "@playwright/test";

export const CHROMIUM_AUTH_FILE = path.join(import.meta.dirname, "./.auth/user-chromium.json");
export const FIREFOX_AUTH_FILE = path.join(import.meta.dirname, "./.auth/user-firefox.json");
export const WEBKIT_AUTH_FILE = path.join(import.meta.dirname, "./.auth/user-webkit.json");

export default defineConfig({
  /* Other configuration is hidden for conciseness */

  /* Configure projects for major browsers */
  projects: [
    // { name: "setup", testMatch: /.*\.setup\.ts/ },

    //--begin-chromium
    {
      name: "chromium-setup",
      testMatch: /chromium.setup.ts/,
      use: { ...devices["Desktop Chrome"] },
    },
    {
      name: "chromium",
      use: {
        ...devices["Desktop Chrome"],
        storageState: CHROMIUM_AUTH_FILE,
      },
      dependencies: ["chromium-setup"],
    },
    //--end-chromium

    //--begin-firefox
    {
      name: "firefox-setup",
      testMatch: /firefox.setup.ts/,
      use: { ...devices["Desktop Firefox"] },
    },
    {
      name: "firefox",
      use: {
        ...devices["Desktop Firefox"],
        storageState: FIREFOX_AUTH_FILE,
      },
      dependencies: ["firefox-setup"],
    },
    //--end-firefox

    //--begin-webkit
    // setup using chromium to get the secure cookies and alter it later
    {
      name: "webkit-setup",
      testMatch: /webkit.setup.ts/,
    },
    {
      name: "webkit",
      use: {
        ...devices["Desktop Safari"],
        storageState: WEBKIT_AUTH_FILE,
      },
      dependencies: ["webkit-setup"],
    },
    //--end-webkit
  ],
});

As we can see, above the configuration, there are constants that define where the auth state for each project will be stored. These constants are also exported for use in each setup file.

webkit-setup will be run before running the project named webkit, which uses the desktop version of Safari. In the webkit.setup.ts file, we will modify the stored cookies to allow them to run on localhost by disabling the Secure attribute.

Setup for each browser

For Chrome and Firefox, very simple, the setup file will look like this:

import { CHROMIUM_AUTH_FILE } from "../../playwright.config";
import { setupAuth } from "./auth.setup";

setupAuth({
  email: "chromium@test.com",
  password: "chromium",
  authStorePath: CHROMIUM_AUTH_FILE,
});

import { FIREFOX_AUTH_FILE } from "../../playwright.config";
import { setupAuth } from "./auth.setup";

setupAuth({
  email: "firefox@test.com",
  password: "firefox",
  authStorePath: FIREFOX_AUTH_FILE,
});

Specifically for Safari (WebKit), we will utilize the callback parameter provided by setupAuth to modify the cookie received.

import { WEBKIT_AUTH_FILE } from "../../playwright.config";
import { setupAuth } from "./auth.setup";

setupAuth({
  email: "webkit@test.com",
  password: "webkit",
  authStorePath: WEBKIT_AUTH_FILE,
  async alterStoreCallback({ page }) {
    /**
     * workaround to make `Set-Cookie` work in unsecure context (localhost) for webkit.
     * https://chromestatus.com/feature/6269417340010496
     * https://bugs.webkit.org/show_bug.cgi?id=281149
     */
    const storageState = await page.context().storageState();
    const cookies = storageState.cookies;
    const unsecureCookies = cookies.map(cookie => ({
      ...cookie,
      secure: false,
    }));

    await page.context().addCookies(unsecureCookies);
  },
});

alterStoreCallback is called just before Playwright saves the page context, so the modified cookie can be used in the rest of the test.

If this not done, the test in Safari will always fail because WebKit (the engine used in Safari) does not store cookies with the Secure attribute on localhost or without HTTPS. Therefore, for testing, we need to modify the stored cookie in Safari only, so that all cookies have the Secure attribute disabled.

Have you ever experienced the same case? Let me know in the comment!

Thank you!

Runtime Variables Configuration for Static Frontend Apps in a Docker Image Promotion Workflow

Faqih — Mon, 02 Mar 2026 16:36:28 +0000

Deploying the same Docker Image from staging to production is common when using container-based deployments. Docker Image Promotion is an approach to using Docker Image that have been built, tested, and verified for use in different environments such as staging, test, and production without needing to re-build
at each step.

Docker Image Promotion ensures consistent behavior between environments, so that the image that has been previously built and tested is the image that is deployed to production. Apart from that, image promotion will also cut deployment time shorter by not doing a rebuild; for example, if the build is carried out at the deployment to staging stage, then when we want to deploy to production, we only need to "promote" the Docker Image, and not do a rebuild.

Root of the problem

We need to know that ARG/--build-arg is only available during build time on the image and ENV/--env is available during build time and runtime on the image. This means, if we have an environment variables scheme as follows:

ENV	Staging	Production
`API_URL`	https://staging.api.com	https://api.com

So, when the image is built and in it there is a build process for our static application, generally build tools like Vite will replace the import.meta.env.API_URL reference to its value directly (static replace). This will damage the process of "promoting" our image from staging to production, because production will get the wrong API_URL.

How about using --env when running the container? Please note, understanding the context of the application is very important. Because our application is a static application, access to environment variable values with process.env or similar from the server is not possible; our application runs in the browser and is not pre-processed on the server (SSR).

To overcome this problem, we can use the window object to place the environment variable values sent via --env when the container is run. Of course, there is one thing that needs to be ensured before using this method, namely making sure the value is something that is safe for the public to see, such as an API URL; it is highly discouraged to put any secrets into the window object.

Breaking down the solution

Because in this context our application runs in a browser environment, we can use the window object to hold all the values needed from --env when the container is run. There are only two core steps we will do:

Create a placeholder in the HTML file in the <head> section
Create a shell script to put the values send via --env into the created placeholders

So, the entire deployment flow will be like the following:

We will use this repository for practice, please clone and follow the steps!

Preparing the placeholder

In the index.html file, we can add a placeholder in the <head> tag as follows:

<script>
  // ENV_PLACEHOLDERS
</script>

Creating shell script to replace the placeholder

This shell script is useful for replacing ENV_PLACEHOLDERS with a valid window.env values. The expectation is that the window.env object will look like this:

window.env = {
  API_URL: "https://staging.api.com",
};

We can utilize sed to perform text replacement on the placeholders that have been prepared. Create a file and name it init.sh with value as below:

#!/bin/sh
ENV_STRING='window.env = { \
    "API_URL":"'"${API_URL}"'" \
}'

sed -i "s@// ENV_PLACEHOLDERS@${ENV_STRING}@" /usr/share/nginx/html/index.html
exec "$@"

nginx -g 'daemon off;'

Then, we need to copy the above init.sh file into our container and run it. Update the Dockerfile to look like this:

FROM oven/bun:1.3.3 AS base

WORKDIR /app

COPY . /app/
COPY package.json /app/package.json
COPY bun.lock /app/bun.lock
RUN bun install --frozen-lockfile

FROM base AS builder
RUN bun run build

FROM nginx:alpine-slim AS runner
COPY ./nginx /etc/nginx/conf.d
COPY ./init.sh /app/init.sh
COPY --from=builder /app/dist /usr/share/nginx/html

EXPOSE 80
CMD ["sh", "/app/init.sh"]

When the container is created and run, init.sh will be executed and will replace the placeholders with the appropriate environment variables, then run NGINX to make our application accessible.

Try with some test scenarios

For the first try, we will just run the container without passing any environment variables. Before that, we need to build the image with the available Dockerfile. Please run the following command:

docker build -t mupinnn/inject-fe .

If the build process is complete, you can ensure the image is ready by running the docker image ls command and seeing that the image with the name mupinnn/inject-fe is on the list.

Then, we will create and run a container based on the image we created earlier with the command:

docker run -p 8181:80 \
mupinnn/inject-fe:latest

The above command will start the container and make it accessible via http://localhost:8181. You can verify that window.env is available by opening the page source (CTRL + u) or opening the console and typing window.env.

Okay, so now we've successfully replaced the placeholder with the desired window object. Next, we need to test it with different environment variable values.

Next, we will run it with the API_URL for staging as follows:

docker run -p 8082:80 \
--env API_URL="https://staging.api.com" \
--name mupinnn-inject-fe-staging \
mupinnn/inject-fe:latest

Access http://localhost:8082 and double-check that the window.env values are present, as in the previous step. The final result should look like this:

Then, we will run the container for production from the same image with the command:

docker run -p 8083:80 \
--env API_URL="https://api.com" \
--name mupinnn-inject-fe-prd \
mupinnn/inject-fe:latest

Access http://localhost:8083 and double-check the window.env value as above. You'll notice that the API_URL value changes depending on what's passed through --env, and we did it without a rebuild!

To access it at runtime, you can now use window.env.API_URL. If you're not using Docker at all during development, window.env won't be available. You can access its value using a fallback like import.meta.env.API_URL ?? window.env.API_URL. For ease of use, you can create a helper function to access environment variable.

function getEnv(key) {
  const envMap = {
    API_URL: import.meta.env.API_URL,
  };

  return window?.env?.[key] || envMap[key];
}

If you're using TypeScript and Vite, you can improve the developer experience by making getEnv function more type-safe.

export function getEnv<K extends keyof ImportMetaEnv>(key: K) {
  const envMap = {
    API_URL: import.meta.env.API_URL,
  };

  return window?.env?.[key] || envMap[key];
}

Then, you can extend the type of the window object by adding the code below to the vite-env.d.ts file.

declare global {
  interface Window {
    env?: ImportMetaEnv;
  }
}

The real workflow

The process above is a brief proof-of-concept and can be implemented in simple deployment scenarios. More complex and structured organizations typically label and tag images at each stage. Labeling and tagging facilitate tracking and rollback if an error occurs in the application or while running the container.

Of course, this labeling and tagging doesn't require another build process, so the above process is still relevant. Build once, multiple environments, deploy anywhere.

Conclusion

With a simple shell script, understanding the deployment process, understanding the difference between runtime and build time, and understanding the environment in which the application runs—you will be able to maximize all the potential and possibilites that exist to optimize from this knowledge.

Have you ever experienced the same thing? Let me know in the comment!