Contents
Cookies, when used with the HttpOnly cookie flag, are not accessible through JavaScript, and are immune to XSS. However, if an injected script makes same-origin requests (e.g. API calls), the cookies get included with it. So it doesn’t matter if JavaScript doesn’t have access to it.
If you want to store sensitive data, think very hard if you really need to store that particular bit of data in a cookie. By using cookies, you may prevent expensive requests to the server, but the data may also get outdated. Data is typically more secure if it not stored on the client side.
How are cookies stolen in a XSS attack?
Cross-site scripting (XSS) attacks are often aimed at stealing session cookies. In such an attack, the cookie value is accessed by a client-side script using JavaScript ( document.cookie ). However, in everyday use, web applications rarely need to access cookies via JavaScript.
If this cookie is set, the browser will never send the cookie if the connection is HTTP. This flag prevents cookie theft via man-in-the-middle attacks. Note that this flag can only be set during an HTTPS connection.
There are 3 very important directives ( Secure, HttpOnly , and SameSite) that should be understood before using cookies, as they heavily impact how cookies are stored and secured. Cookies contain very sensitive information: if attackers can get a hold of a session ID, they can impersonate users by hijacking their sessions.
What does the Secure flag mean on cookies?
Here are two more that can be useful. The Secure flag is used to declare that the cookie may only be transmitted using a secure connection (SSL/HTTPS). If this cookie is set, the browser will never send the cookie if the connection is HTTP. This flag prevents cookie theft via man-in-the-middle attacks.