You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The value of `document.cookie` consists of `name=value` pairs, delimited by `;`. Each one is a separate cookie.
34
+
The value of `document.cookie` consists of `name=value` pairs, delimited by `;`. Each one is a separate cookie.
35
35
36
-
To find a particular cookie, we can split `document.cookie` by `;`, and then find the right name. We can use either a regular expression or array functions to do that.
36
+
To find a particular cookie, we can split `document.cookie` by `;`, and then find the right name. We can use either a regular expression or array functions to do that.
37
37
38
38
We leave it as an exercise for the reader. Also, at the end of the chapter you'll find helper functions to manipulate cookies.
39
39
@@ -255,7 +255,7 @@ Overall, `samesite` is a great option.
255
255
256
256
There's a drawback:
257
257
258
-
-`samesite` is ignored (not supported) by very old browsers, year 2017 or so.
258
+
-`samesite` is ignored (not supported) by very old browsers, the year 2017 or so.
259
259
260
260
**So if we solely rely on `samesite` to provide protection, then old browsers will be vulnerable.**
261
261
@@ -269,7 +269,7 @@ The web-server uses the `Set-Cookie` header to set a cookie. Also, it may set th
269
269
270
270
This option forbids any JavaScript access to the cookie. We can't see such a cookie or manipulate it using `document.cookie`.
271
271
272
-
That's used as a precaution measure, to protect from certain attacks when a hacker injects his own JavaScript code into a page and waits for a user to visit that page. That shouldn't be possible at all, hackers should not be able to inject their code into our site, but there may be bugs that let them do it.
272
+
This is used as a precautionary measure, to protect from certain attacks when a hacker injects his own JavaScript code into a page and waits for a user to visit that page. That shouldn't be possible at all, hackers should not be able to inject their code into our site, but there may be bugs that let them do it.
273
273
274
274
275
275
Normally, if such a thing happens, and a user visits a web-page with hacker's JavaScript code, then that code executes and gains access to `document.cookie` with user cookies containing authentication information. That's bad.
0 commit comments