FmindSecurity guide
Cookie protection (Secure, HttpOnly)
Cookies can keep your visitors or staff logged in. Without the Secure flag a cookie may travel unencrypted, and without HttpOnly malicious code on the page can read it, which could let someone take over a session.
Who can help
Your web developer
Inspect before changing
Use these steps for a website or email domain you manage. Complete the capitalized placeholders with your own values. If a step refers to saved evidence, run the free check and verify your domain to open the private report. Use the exact hostname or DNS query name shown there.
- In the browser’s storage tools, note only each cookie’s name, purpose, origin and flags, never its value. Ask the application or plugin owner which cookies need JavaScript or cross-site access; don’t rewrite every Set-Cookie header at the CDN.
Cookie name | Purpose | Application/plugin owner | Secure | HttpOnly | SameSite
DO_NOT_COPY_COOKIE_VALUESWhat to do
Ask your developer what each cookie is for. Login and session cookies should have both Secure and HttpOnly. Some cookies, such as consent banners or analytics, legitimately need to be readable by the page, so don’t change them all at once: test logging in and your integrations first, and keep a way to roll back.
How to verify the change
Run this check again and review the cookie list with your developer. Then confirm that logging in and your other features still work.
What this check can establish
Every cookie should have Secure; only sign-in and session cookies must also have HttpOnly, because consent or analytics cookies are read by the page on purpose. We only see cookies set by your homepage, we hide their values, recognize session cookies by their name and don’t check their SameSite setting.