Check your cookie security settings

SiteCurl inspects every Set-Cookie header in your server's response and checks for three security attributes: Secure, HttpOnly, and SameSite. Each attribute protects cookies in a different way, and missing any of them leaves a gap that attackers can exploit.

The Secure flag ensures the cookie is only sent over HTTPS connections. Without it, the cookie can be intercepted on an unencrypted HTTP connection. The HttpOnly flag prevents JavaScript from reading the cookie, which blocks cross-site scripting (XSS) attacks from stealing session data. The SameSite attribute controls whether the cookie is sent with cross-site requests, protecting against cross-site request forgery (CSRF).

SiteCurl names the specific cookies and the specific attributes they are missing. If your site sets no cookies, it passes automatically because there is nothing to protect.

Cookies store information between page visits. The most important cookie on most sites is the session cookie, which keeps visitors logged in. If someone steals that cookie, they can impersonate the visitor without knowing their password.

There are three common ways cookies get stolen. First: network interception. 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 readable in plain text. The attacker copies the cookie and uses it to access the victim's account.

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

Third: cross-site request forgery (CSRF). An attacker puts a hidden form on their site that submits to your site. If the visitor is logged in, the browser sends their cookies along with the forged request. The SameSite attribute set to Lax or Strict prevents the browser from sending cookies with cross-site requests.

Each attribute blocks one attack vector. All three together provide defense in depth. Missing even one leaves an opening that is straightforward to exploit.

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

Cookie security attributes are easy to add and have no downside. The Secure flag only matters if your site already uses HTTPS (which it should). HttpOnly only blocks JavaScript access, which legitimate code should not need for session cookies. SameSite with Lax is the default in modern browsers, but setting it explicitly ensures consistent behavior across all browsers.

Security auditors and enterprise buyers check cookie attributes as part of vendor assessments. Missing attributes are a common finding in penetration 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 attributes. This applies to SaaS products, e-commerce stores, membership sites, and community platforms.

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

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

Step 1: Add all three attributes 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 options.

Step 2: Check other cookies. Authentication tokens, CSRF tokens, and preference cookies should also have these attributes. Review every Set-Cookie header your server sends. Any cookie that contains sensitive data needs all three flags.

Step 3: Audit third-party cookies. If a tracking script or widget sets cookies without proper attributes, contact the vendor or configure the script to set them. If the script cannot be configured, consider whether the risk is worth keeping it.

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

Mistake 1. Adding Secure but not HttpOnly. The Secure flag stops network interception, but without HttpOnly, a cross-site scripting attack can still read the cookie with JavaScript. Add both attributes together.

Mistake 2. Setting SameSite=None without Secure. Browsers reject cookies with SameSite=None that do not also have 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 entire site, not just authenticated pages.

Mistake 4. Assuming the framework handles it. Many frameworks set secure cookie defaults, but only when configured correctly. Custom cookies set manually (for preferences, analytics, or A/B tests) may bypass the framework defaults. Check every cookie individually.

After making changes, run another SiteCurl scan. The cookie security check should pass for all cookies. You can also verify manually: open your browser developer 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.