Most apps store a user's login session in a cookie, and most AI coding tools set that cookie up with defaults that work perfectly fine in a demo and quietly leave out settings that only matter once someone's trying to abuse them. Three flags in particular are worth checking on your own app, and none of them require a security background to understand.
HttpOnly: can your own page's JavaScript read the session cookie
When this flag is set, a browser will send the cookie along with requests but won't let any JavaScript running on the page read its value directly. Without it, if your app ever has a cross-site scripting bug anywhere, a form field that doesn't escape input correctly, a comment box, a profile bio, a malicious script injected through that gap can simply read the session cookie and hand it to an attacker, giving them your logged-in user's session without ever needing a password. Setting HttpOnly doesn't prevent the underlying scripting bug. It does mean that even if one exists, the session token itself isn't the thing walking out the door.
Secure: does the cookie only travel over an encrypted connection
This flag tells the browser to only send the cookie over HTTPS, never over a plain, unencrypted connection. Most apps are HTTPS-only today, which makes this feel redundant, but it's a real backstop against the specific case of a misconfigured redirect, an old link still pointing at an http address, or a subdomain that isn't fully locked down, any of which could otherwise leak the session cookie in plain text to anyone watching the network.
SameSite: will the cookie get sent along with requests from other websites
This is the one most directly connected to the CORS conversation I've written about before. SameSite controls whether your session cookie gets attached to requests that originate from a different website entirely, the exact mechanism a malicious page would rely on to quietly act as your logged-in user in the background. Setting this to Strict or Lax, rather than leaving it unset or set to None, closes off a real category of cross-site attacks with a single configuration line.
How to actually check your own app
Open your browser's dev tools, go to the Application or Storage tab, find your session cookie, and look at its flags directly. You're looking for HttpOnly checked, Secure checked, and SameSite set to something other than None, unless you have a specific, deliberate reason for a looser setting on a particular cookie.
Why this rarely gets checked
None of these three flags affect whether login works in a normal test. A cookie without any of them still logs you in, still keeps you signed in, still behaves completely normally for a real user clicking through the app as intended. The gap only becomes visible under exactly the conditions these flags exist to defend against, which is precisely why it's worth checking on purpose rather than waiting to notice something's wrong.