The idea is, once you've proven you have some "a thing you have" second factor (a phone number), you can basically turn your PC into another "thing you have" second factor. Since it's usually vastly easier to steal somebody's phone number than their PC, this is probably fine.
It's done the same way any other long-term authentication ...
At least in Chromium-based browsers and in Firefox, it's no longer possible for a non-secure origin
to set cookies with a Secure flag, or
to overwrite cookies whose Secure flag is true.
At the time the question was asked, draft-ietf-httpbis-cookie-alone-01 had already (September 5, 2016) been proposed to prevent non-secure origins from ...
Can someone still use that browser cookie to impersonate me?
As @Hackndo noted, this is totally up to the web-developer.
am I safe now
Guessing, I would suggest you change your password, not just log out.
Here is a deterministic way to check:
Now take your cookie, then log in (or change your password) and compare the 2 keys to see if they are the same.
This depends on the different websites on which these cookies were valid. Normally, if you have logged out, the cookies should no longer be valid, and you should be safe.
Sometimes websites do not invalidate cookies even after logging out, they simply delete them on the user side. In this case, it is still possible to re-authenticate by re-using the cookies. ...
If I understand your question correctly, you are trying to compare things that are not comparable.
"Cookie-to-header" is a defense mechanism against CSRF attacks, although not a very good one as it relies on an attacker not being able to inject cookies into the user's browser. Better to tie a unique CSRF token to the user's session and put that ...
New answer to an old question, but please bear with me.
Regardless of the type of anti-CSRF-token implementation you're considering (whether if be the synchronizer token pattern or another), be aware that the SameSite cookie attribute is not a drop-in replacement for anti-CSRF tokens; SameSite and anti-CSRF tokens do not protect against the same attack ...