Check Cookie Security Attributes

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.

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. 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. A successful result with all three attributes present should therefore be treated as one concrete configuration check, not a complete web security assessment.

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. 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. 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.