Check your cookie security settings

SiteCurl reads each Set-Cookie header in your server's response and checks for three flags: Secure, HttpOnly, and SameSite. Each flag guards cookies in its own way. Missing any of them leaves a gap that hackers can use.

The Secure flag makes sure the cookie is only sent over HTTPS. Without it, the cookie can be read on a plain HTTP link. HttpOnly stops JS from reading the cookie, which blocks XSS attacks from stealing session data. SameSite controls if the cookie is sent with cross-site requests, blocking CSRF attacks.

SiteCurl names the exact cookies and the exact flags they lack. If your site sets no cookies, it passes on its own since there is nothing to guard.

Cookies store data between page visits. The most valued cookie on most sites is the session cookie, which keeps users logged in. If someone steals that cookie, they can act as the user without knowing their password.

There are three common ways cookies get stolen. First: network sniffing. On a public Wi-Fi network, traffic over HTTP is visible to anyone nearby. A cookie without the Secure flag can be sent over HTTP, where it is plain text. The hacker copies the cookie and uses it to get into the user's account.

Second: cross-site scripting (XSS). If a hacker injects a script into your page, that script can read cookies using document.cookie. A cookie with the HttpOnly flag is hidden from JavaScript. The script cannot read it, so it cannot steal it.

Third: cross-site request forgery (CSRF). A hacker puts a hidden form on their site that posts to your site. If the user is logged in, the browser sends their cookies with the forged request. The SameSite flag set to Lax or Strict stops the browser from sending cookies with cross-site requests.

Each flag blocks one attack type. All three give defense in depth. Missing even one leaves an opening that is easy to exploit.

Session hijacking is one of the most common web attacks. A stolen session cookie gives the hacker full access to the user's account. They can read private data, make buys, change settings, or lock the real user out. The attack is silent: the user does not know their session was copied.

Cookie safety flags are easy to add and have no downside. The Secure flag only matters if your site uses HTTPS (which it should). HttpOnly only blocks JS access, which real code should not need for session cookies. SameSite with Lax is the default in modern browsers, but setting it clearly ensures the same action across all browsers.

Security testers and large buyers check cookie flags as part of vendor reviews. Missing flags are a common finding in pen tests. Fixing them before the audit saves time and avoids follow-up questions.

Any site with user accounts is at risk. If your site has a login, it has a session cookie. That cookie needs all three flags. This applies to SaaS products, online stores, member sites, and forums.

Sites using third-party analytics or marketing tools often set cookies without the right flags. The site owner may not even know these cookies exist. SiteCurl checks each cookie in the response, including ones set by outside scripts.

Agencies building client sites should check cookie flags before launch. A missing HttpOnly flag on a client's session cookie is a safety gap that the agency owns. A pre-launch scan catches it in minutes.

Step 1: Add all three flags to session cookies. Your session cookie should always have Secure, HttpOnly, and SameSite=Lax. In Rails, this is the default. In PHP, set session.cookie_secure = 1, session.cookie_httponly = 1, and session.cookie_samesite = Lax in php.ini. In Express.js, set these in the session middleware config.

Step 2: Check other cookies. Auth tokens, CSRF tokens, and pref cookies should also have these flags. Review each Set-Cookie header your server sends. Any cookie that holds private data needs all three flags.

Step 3: Audit third-party cookies. If a tracking script or widget sets cookies without the right flags, reach out to the vendor or set up the script to add them. If the script cannot be changed, weigh whether the risk is worth keeping it.

Step 4: Test across your site. Check that the flags show up on each page, not just the home page. Some server setups only apply cookie settings to certain routes. Open your browser dev tools (F12), go to Application > Cookies, and confirm the flags are set on each cookie.

Mistake 1. Adding Secure but not HttpOnly. The Secure flag stops network sniffing, but without HttpOnly, an XSS attack can still read the cookie with JS. Add both flags at the same time.

Mistake 2. Setting SameSite=None without Secure. Browsers reject cookies with SameSite=None that lack the Secure flag. If you need cookies sent cross-site (for third-party embeds), you must use both SameSite=None and Secure.

Mistake 3. Only checking the login page. Cookies are set on any page. Your home page, blog, or landing page may set cookies too. Check the Set-Cookie headers across your full site, not just logged-in pages.

Mistake 4. Thinking the framework handles it. Many frameworks set safe cookie defaults, but only when set up right. Custom cookies set by hand (for prefs, analytics, or A/B tests) may skip the framework defaults. Check each cookie on its own.

After your changes, run a new SiteCurl scan. The cookie safety check should pass for all cookies. You can also check by hand: open your browser dev tools (F12), go to Application > Cookies, and check that each cookie shows Secure, HttpOnly, and SameSite columns.

For a server-side check, run curl -sI https://yoursite.com | grep -i set-cookie. Each Set-Cookie line should include Secure, HttpOnly, and SameSite=Lax (or Strict).

Cookie security attributes are three small flags that block three common attacks. Every cookie that contains session data, authentication tokens, or user preferences should have Secure, HttpOnly, and SameSite set. The fix takes minutes and has no user-visible impact.