In one paragraph
A cookie without the Secure flag may be sent over an unencrypted HTTP connection when its other scope rules allow it. Serving your normal pages over HTTPS does not set that protection on the cookie itself. Add Secure where the cookie is created, confirm HTTPS works throughout the affected application, and test login and session renewal after deployment.
Why it matters
The Secure attribute controls cookie transmission, not cookie creation alone. Without it, a matching cookie can accompany an HTTP request even if the browser originally received the cookie over HTTPS. Anyone able to observe that unencrypted request may be able to read its value.
An HTTP-to-HTTPS redirect does not retroactively protect an HTTP request: the request reaches the server before the redirect response comes back. HSTS can prevent HTTP requests once applicable to the browser, but Secure remains a separate cookie-level control. Do not rely on a redirect as a substitute.
How WebAuditOS evaluates this finding
The check specification supplied with these pages examines Set-Cookie response headers on HTTPS pages. Every cookie in a response must carry Secure to pass. One missing flag fails the response, and the evidence identifies the affected cookie names. HTTP pages and responses that set no cookies are not graded by this check.
This does not audit the complete browser cookie store. Cookies written by JavaScript are outside that response-header test, and an unauthenticated crawl may never reach the response that issues a private session. A pass therefore confirms the observed headers, not every cookie your application can create.
How to fix it
- Find the issuing response. Inspect the exact URL in the finding in the browser Network panel, including redirects. Match each named cookie to its owner: application session middleware, reverse proxy, load balancer, CDN, or plugin.
- Confirm the affected application is available over valid HTTPS. Include authentication endpoints and any hosts that intentionally share the cookie. Resolve transport problems before requiring HTTPS-only cookies.
- Set Secure in the cookie or session configuration. For a conventional session, a response may look like this:
Set-Cookie: session=REPLACE_WITH_SESSION_TOKEN; Path=/; Secure; HttpOnly; SameSite=LaxThe placeholder is not an implementation. Choose SameSite for the actual flow, and protect session values with appropriate creation, rotation, expiry, and revocation.
- Check proxy awareness. If TLS terminates at a trusted proxy, the application must correctly recognise the original HTTPS request. Configure forwarded-header trust for your real infrastructure, not for arbitrary client-supplied headers. Otherwise a session library may omit the cookie or misjudge whether it can set Secure.
- Reissue the cookie and test complete journeys. Check a new login, page refresh, logout, session renewal, and password change. Configuration edits do not rewrite cookies already stored in a visitor's browser; new responses must issue the intended attributes.
- Verify in two places. Inspect Set-Cookie on the issuing response, then check the stored cookie's Secure setting in DevTools. Repeat after renewal, since separate code paths sometimes use different defaults. Rescan the affected URLs in WebAuditOS.
Audit JavaScript-created cookies separately in the browser. Sensitive authentication values should generally be issued server-side so that HttpOnly can also be used where appropriate.
What the fix can break
A Secure cookie is not sent over ordinary HTTP. Local development on a LAN address or a custom hostname may therefore stop maintaining sessions unless you provide HTTPS. Browsers make some localhost exceptions, but those are not a dependable substitute for testing your production configuration.
An old HTTP-only subdomain that relies on a shared cookie can also stop working. Fix that dependency instead of disabling Secure on the production session.
The optional __Host- prefix adds different restrictions: Secure, Path=/, and no Domain attribute. It prevents parent-domain cookie sharing, so do not rename a shared session cookie without redesigning and testing the cross-subdomain sign-in flow.
Questions
Do I need Secure if every normal page uses HTTPS?
Yes. Secure explicitly limits cookie transmission to HTTPS, subject to browser localhost exceptions. A redirect alone does not protect a cookie already attached to an HTTP request.
Does Secure stop JavaScript from reading the cookie?
No. HttpOnly controls JavaScript access. Secure controls the connection on which the browser sends the cookie. Use both for a server-managed session that does not need frontend cookie access.
Why does the finding name a cookie our code does not create?
A hosting platform, CDN, load balancer, or plugin may add it. Identify the issuing layer from the response and vendor configuration rather than changing an unrelated application setting.
Which related checks should I review?
Review cookie without HttpOnly, cookie without SameSite, and the security headers guide. Their protections are complementary, not interchangeable.