HTTPOnly + Secure cookies

HTTPOnly and Secure cookies is a review and setup of cookie attributes: we set HTTPOnly (the cookie is inaccessible from JavaScript — reduces session theft on XSS), Secure (the cookie is sent only over HTTPS — won't leak over http), and check the lifetime and scope (path/domain). Honestly about the scope, this matters: the flags protect the cookies THEMSELVES (their theft/transmission), but do NOT eliminate the cause — the XSS vulnerability in the code (closed by 752): if an attacker can execute a script, they can do harm even without access to the cookie. So this is reduction of consequences, not a replacement for XSS protection. Honestly about the prerequisite: Secure makes sense only with working HTTPS (736) — otherwise a Secure cookie simply won't be set. Honestly about the effect: lower risk of session theft, we do NOT guarantee sales growth by itself. Honestly about compatibility: if some front-end script read the cookie directly — after HTTPOnly it won't be able to (we will check and redo it properly). Honestly about access: access to the code/config where cookies are set is needed. An important boundary: this is the HTTPOnly/Secure flags; CSRF protection via Same-Site is a separate service (759), and protection against XSS itself is 752. Picture this: instead of 'the session cookie can be stolen by a script or intercepted over http' — the cookie is closed off from JS and travels only over HTTPS. The base price starts from 9,000 ₽ per project.

• The session cookie can be read by JavaScript (session theft on XSS).
• The cookie is sent over http and can be intercepted.
• Cookie attributes (lifetime, scope) are set carelessly.
• Sensitive data is stored in a cookie without protection.

• An audit of current cookies and their attributes
• Setting the HTTPOnly flag for session/sensitive cookies
• Setting the Secure flag (HTTPS only)
• Reviewing lifetime and scope (path/domain)
• Checking the front-end did not break (if it read the cookie)
• Indicating boundaries (not a replacement for XSS protection)
• Checking application
• Handover and review with you

• Session cookies are inaccessible to JavaScript
• Cookies are sent only over HTTPS
• Lower risk of session theft/interception
• A narrow but important layer (XSS protection — separate)

• We capture all cookies and attributes, find those read by the front-end; collect access
• We set HTTPOnly/Secure, review attributes, fix compatibility
• We check application, review boundaries with you

• Will HTTPOnly protect against XSS?

  Not against XSS itself, but against one of its consequences: with HTTPOnly a stolen script cannot read the session cookie. But the cause — the XSS vulnerability in the code — remains and must be closed separately (752): on XSS an attacker can do harm even without access to the cookie. This is reduction of consequences, not a replacement for protection.

• Is Secure really needed?

  Yes, if you have HTTPS (and you should). Secure forbids sending the cookie over insecure http — otherwise it can be intercepted. Important: Secure makes sense only with working HTTPS; if there is none — TLS first (736).

• Will something on the site break?

  It can, if some front-end script read the cookie directly — after HTTPOnly it won't be able to. That is why an audit comes first: we will find such places and redo them properly (via the server) so that nothing falls off.