Link to the code that reproduces this issue

https://codesandbox.io/p/sandbox/suspicious-worker-939hzv

To Reproduce

1. Open the CodeSandbox.
2. Open Web Inspector.
3. Click "Delete Cookie".
4. Click "Delete Cookie (with set)".
5. Observe the set-cookie headers for the two requests in Web Inspector:
   • The first one is unexpectedly blocked by the browser.
   • The second one works as expected.

Current vs. Expected behavior

The two buttons both attempt to delete a cookie. The "Delete Cookie" button demonstrates the current unexpected behavior. The "Delete Cookie (with set)" button demonstrates a workaround.

Delete Cookie

This button uses ResponseCookies#delete. It attempts to delete a cookie that uses the __Secure- prefix. When a cookie uses this prefix, it must use the Secure attribute, both when setting the cookie and deleting it, otherwise the set-cookie header will be blocked by the browser.

cookies().delete({
  name: "__Secure-UsingDelete",
  secure: true,
  httpOnly: true,
  sameSite: "none",
})

Expected Behavior

The set-cookie header should include the Secure, HttpOnly, and SameSite=none attributes.

Set-Cookie: __Secure-UsingDelete=; Path=/; Expires=Thu, 01 Jan 1970 00:00:00 GMT; Secure; HttpOnly; SameSite=none

Current Behavior

The set-cookie header does not include the Secure, HttpOnly, and SameSite=none attributes.

Set-Cookie: __Secure-UsingDelete=; Path=/; Expires=Thu, 01 Jan 1970 00:00:00 GMT

Warning

As the set-cookie header has the __Secure-, but does not use the Secure attribute, it is blocked by the browser:

Delete Cookie (with set)

This button uses ResponseCookies#set as a workaround. It attempts to delete a cookie that uses the __Secure- prefix. When a cookie uses this prefix, it must use the Secure attribute, both when setting the cookie and deleting it, otherwise the set-cookie header will be blocked by the browser.

cookies().set({
  name: "__Secure-UsingSet",
  value: "",
  expires: 0,
  secure: true,
  httpOnly: true,
  sameSite: "none",
})

The set-cookie header does include the Secure, HttpOnly, and SameSite=None attributes, as expected.

Set-Cookie: __Secure-UsingSet=; Path=/; Expires=Thu, 01 Jan 1970 00:00:00 GMT; Secure; HttpOnly; SameSite=none

Verify canary release

• I verified that the issue exists in the latest Next.js canary release

Provide environment information

Operating System:
  Platform: linux
  Arch: x64
  Version: #1 SMP PREEMPT_DYNAMIC Sun Aug  6 20:05:33 UTC 2023
Binaries:
  Node: 20.7.0
  npm: 10.1.0
  Yarn: 1.22.19
  pnpm: N/A
Relevant Packages:
  next: 13.5.5-canary.4
  eslint-config-next: 13.5.4
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.2.2
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

App Router

Additional context

No response