Skip to content
SilktideHelp

Secure cookies

Silktide examines the cookies your pages set and reports any that are allowed to travel over an unencrypted connection. Cookies should be restricted to encrypted connections so they cannot be intercepted in transit.

A is restricted by adding the Secure attribute when it is set:

Set-Cookie: session=abc123; Secure; HttpOnly

Why this matters

Cookies often carry the keys to a visitor's session - the proof that they are signed in. A cookie without the Secure attribute is sent with any matching request, including plain http:// ones, where anyone on the network path can read it. An attacker who captures a session cookie can impersonate that visitor without ever knowing their password.

Even on a website served entirely over , a single stray unencrypted request - an old link, a typed address - is enough to leak a non-secure cookie. The Secure attribute makes the browser withhold the cookie from unencrypted requests entirely.

How to fix it

  1. For cookies your own code sets, add the Secure attribute (and usually HttpOnly, which also hides the cookie from scripts):
Set-Cookie: session=abc123; Secure; HttpOnly

Most web frameworks have a setting that applies this to all cookies.

  1. For cookies set by third-party tools (analytics, chat widgets, embeds), check the tool's configuration for a secure-cookies option, or update to a current version - modern versions of most popular services set Secure by default.
  2. If a third-party cookie cannot be secured and you accept the risk - for example, a tracking cookie containing nothing sensitive - you can the finding for that cookie.

How Silktide tests this

  1. Load each page in a browser and record every cookie that is set, whether by the server or by scripts.
  2. Check each cookie for the Secure attribute.
  3. Report each named cookie that lacks it.

Troubleshooting

You still control whether that service runs on your pages, but not always how it sets cookies. Check the service's settings and documentation for a secure-cookie option first; if none exists, decide whether the cookie's contents are sensitive enough to matter, and approve the finding if not.

The Secure attribute costs nothing on an HTTPS site, so it is good hygiene even for harmless cookies. But if you cannot control the cookie and its contents are genuinely trivial, approving the finding is reasonable.

Learn more

Last updated

Was this page helpful?