Check Cookie Security Attributes
A session cookie set with Secure, HttpOnly and SameSite=Lax passes, because all three protections are present. Paste a cookie from a login response or after a proxy change and spot a missing attribute at once. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Text
- session_id=abc123; Path=/; Secure; HttpOnly; SameSite=Lax
- Cookie name
- session_id
Cookie security depends on small attributes that are easy to omit during configuration changes. This checker reads one Set-Cookie header value, confirms that it starts with a cookie name and value, and reports whether Secure, HttpOnly, and SameSite are present. It also returns a concise list of missing attributes, making the result easy to use in reviews, deployment checks, test suites, and CI pipelines. The check is deterministic, case-insensitive for attribute names, and runs without making any network request.
How to interpret each attribute
Secure tells compatible clients to send the cookie only over secure transport, which helps prevent accidental exposure over an unencrypted connection. HttpOnly prevents ordinary client-side JavaScript from reading the cookie through common browser APIs, reducing the ways a script injection flaw can extract a session token. SameSite controls whether the browser includes the cookie in different cross-site request contexts and is commonly used as part of cross-site request forgery defenses.
The checker deliberately reports presence rather than deciding which SameSite policy is correct, because Strict, Lax, and None serve different application requirements. For example, a cross-site integration may intentionally require SameSite=None and must pair that choice with Secure in modern browser deployments. Review the reported booleans alongside the cookie's purpose, authentication sensitivity, browser support requirements, and intended cross-site flows.
Missing attributes deserve attention, but their appropriate values remain an application-level decision.
Using the result in development and CI
Run the checker against representative Set-Cookie values captured from application tests, reverse-proxy configuration, or framework output. An input that does not begin with a name=value pair is rejected as invalid rather than producing a misleading audit. After correcting a server configuration, test the actual emitted response again; checking a configuration file alone can miss attributes added, removed, or rewritten by middleware, an ingress proxy, a CDN, or an authentication component.
What you can do with it
Review authentication cookies
Check a session cookie emitted by a login response and immediately identify whether any of the three expected security attributes are absent.
Validate proxy changes
Compare headers after a reverse-proxy or CDN change to catch a security attribute that was lost during rewriting.
FAQ
What does the check cost?
The browser version can run locally without sending the header to a network service.
Does this validate the SameSite value?
No. It reports whether the SameSite attribute is present. Choosing Lax, Strict, or None depends on the application's intended cross-site behavior.
Are attribute names case-sensitive?
No. Secure, HttpOnly, and SameSite are recognized regardless of capitalization.
Why was my input rejected?
The value must begin with a non-empty cookie name followed by an equals sign and its value, before any semicolon-delimited attributes.
Can I check several Set-Cookie values at once?
No, check one cookie at a time. Joining several cookies into a single comma-separated line is unreliable, because cookie values and expiration dates can contain characters that break the split. Paste each one separately.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/security/cookie-attribute-check \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"text":"session_id=abc123; Path=/; Secure; HttpOnly; SameSite=Lax"}'const res = await fetch("https://api.kit.forhosting.com/security/cookie-attribute-check", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"text": "session_id=abc123; Path=/; Secure; HttpOnly; SameSite=Lax"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/security/cookie-attribute-check",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"text": "session_id=abc123; Path=/; Secure; HttpOnly; SameSite=Lax"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/security/cookie-attribute-check", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"text":"session_id=abc123; Path=/; Secure; HttpOnly; SameSite=Lax"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"text":"session_id=abc123; Path=/; Secure; HttpOnly; SameSite=Lax"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/security/cookie-attribute-check", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"text": "session_id=abc123; Path=/; Secure; HttpOnly; SameSite=Lax"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "security.cookie_attribute_check",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
What the checker examines
Paste the value of a single Set-Cookie response header, beginning with its cookie name and value. The checker separates the first name=value pair from the semicolon-delimited attributes that follow it. A successful result with all three attributes present should therefore be treated as one concrete configuration check, not a complete web security assessment. It then looks for Secure, HttpOnly, and SameSite without depending on capitalization, so `secure`, `SECURE`, and `Secure` are treated as the same attribute. The result contains an individual boolean for each protection, an ordered list of the attributes that are missing, and an `all_present` summary. This focused output makes the capability useful both to a person inspecting a header and to a program enforcing a release rule. It checks whether each attribute is present; it does not claim that the cookie's wider design, scope, lifetime, or application behavior is safe.
Using the result in development and CI
In an automated test, fail the build when `all_present` is false, or apply a more specific policy by inspecting the three booleans and the `missing_attributes` list. Because the parser is deterministic and uses no network, the same input produces the same structured result in a local check, browser tool, or API workflow. Supply only one header value per request: combining several Set-Cookie headers into a comma-separated string is unreliable because cookie values and expiration dates can contain punctuation with special meaning.
Integration use cases
Add a CI security assertion
Feed a Set-Cookie value from an integration test into the API and fail the pipeline when all_present is false.
Technical questions
Can I check several Set-Cookie headers at once?
No. Send one Set-Cookie header value per request so each cookie receives an unambiguous result.