Obvious 3 safety rules

Rule number 1. Make all authorization cookies HttpOnly

Cookies with the HttpOnly flag are not visible to the browser code, but are sent only to the server. In practice, you almost never need to get their contents from the client (if for some reason you have such a need - review the authorization architecture, most likely there is something wrong). But an attacker who has found an XSS - and XSS will somehow find someplace somewhere - the absence of HttpOnly on authorization cookies will bring a lot of joy.

Rule number 2. Perform actions through POST, protecting with a random key

GET is getting information. POST - perform action. This is not just a matter of paradigm beauty and kosher, it is a practical security issue, because GET is performed without explicit user involvement, and the browser will ask for a suspicious POST request.

For example, if your logout is performed by calling on a spherical / auth / logout, then every user, seeing an invisible image <img src = "/ auth / logout">, will be suddenly logged out. And this is the most innocuous, because there can be pictures "/ comment / add", "/ item / vote" or even "/ admin / delete-all-these-users". If your language and framework mixes data from POST and GET (there are a lot of such), always check the type of request for URL actions.
')
You should also check the referer of the source of the request or, better, compare the random key from the request sent from the client with the same key in the cookie.

Rule number 3. Do not trust the browser

From the server side, always treat your javascript code as if it were all, from the first to the last letter written by your most hated enemy, wishing to break your website, violate the integrity of your data and sell your wife into slavery. Moreover, sometimes this is true.

As always happy to help
your KO