Add a quiz item about http only cookies to how clerk works #2097
Conversation
|
Hey, here’s your docs preview: https://clerk.com/docs/pr/2097 |
alexisintech
force-pushed
the
je.add-httponly-quiz
branch
2 times, most recently
from
ae920a9 to
e1a58a1
Compare
|
TIL 'exfiltrated' 😆 I've pretty much just made this entire thing more concise. I had to re-read it multiple times to grasp what you're were trying to convey, so I've organized it in a way that it's more palatable. |
alexisintech
force-pushed
the
je.add-httponly-quiz
branch
from
e1a58a1 to
52f8fdc
Compare
alexisintech
force-pushed
the
je.add-httponly-quiz
branch
from
52f8fdc to
eb97b62
Compare
docs/how-clerk-works/overview.mdx
Outdated
| @@ -270,26 +270,20 @@ For more information on the differences between development and production envir | |||
| - **HttpOnly:** No - must be able to be accessed by client-side SDKs | |||
| - **SameSite:** Lax | |||
|
|
|||
| When your app makes a request from the frontend to your backend, if the backend is on the same origin, the `__session` cookie will automatically be sent along with the request. Your backend can then [cryptographically verify](/docs/backend-requests/manual-jwt) the session token's signature and extract the user ID and other claims. | |||
| When your app makes a request from the frontend to your backend, if the backend is on the same origin, the `__session` cookie, also referred to as the session token, will automatically be sent along with the request. Your backend can then [cryptographically verify](/docs/backend-requests/manual-jwt) the session token's signature and extract the user ID and other claims. | |||
There was a problem hiding this comment.
This edit isn't exactly accurate. The session token and session cookie are two different things - the cookie is the vehicle which contains the token. You could say "the session token is sent" or "the session cookie is sent" colloquially and those would mean the same thing - the former implying that it's sent either via cookie or header, but technically saying that the session token and cookie are the same is not true.
There was a problem hiding this comment.
we refer to it as "session token" thru out the docs, and even thru out this particular doc. the quiz was written as "Why are session tokens not HttpOnly? Is this a security issue?" and technically, the session token is not HttpOnly, the session cookie is.
so shall we update this doc to be more clear according to this suggestion? or what do u think
There was a problem hiding this comment.
Yeah I think we should for sure - the quiz title as quoted there should for sure be corrected, thats not right!
docs/how-clerk-works/overview.mdx
Outdated
| > The drawback is that it does make the session token vulnerable to XSS attacks, since it's not `HttpOnly`. However, Clerk mitigates this risk substantially with the token's very fast expiration time of 60 seconds. In order for an XSS attack to be able to take advantage of this, the developer would need to ship a vulnerability on their site, and the attacker would need to exfiltrate users' tokens and use them to take over accounts in an average of less than 30 seconds. While this is absolutely possible for a very specific targeted attack, it's quite challenging, and extremely unlikely to be an issue for the most common type of XSS attacks, which are broad sweeps across many sites to harvest tokens, typically after a CVE is disclosed, that can take advantage of those who didn't patch their sites in time. | ||
| > | ||
| > Additionally, there are a variety of ways that session tokens can be exfiltrated outside of only XSS attacks, and Clerk's fast-expiring token provides an extra layer of protection against these attacks that are not mitigated by using the `HttpOnly` flag on a long-lived session token. | ||
| > Clerk mitigates this risk substantially by setting the session token's expiration to a very short duration of 60 seconds. For an XSS attack to succeed, the developer would need to ship a vulnerability on their site, and the attacker would need to exfiltrate users' tokens and use them to take over accounts in an average of less than 30 seconds, which is an extremely difficult scenario. Additionally, Clerk's fast-expiring token provides an extra layer of protection against other attacks that `HttpOnly` cookies alone wouldn't mitigate. |
There was a problem hiding this comment.
I think this is a relevant detail that was cut:
and extremely unlikely to be an issue for the most common type of XSS attacks, which are broad sweeps across many sites to harvest tokens, typically after a CVE is disclosed, that can take advantage of those who didn't patch their sites in time.
|
@jescalan check out the updates and lmk what u think ! |
|
good with this let's ship! |
🔎 Previews:
What does this solve?
We sometimes get folks asking about why the session cookie is not
HttpOnly, or feeling like it's a security issue. Wanted to add this section to add some context and clarity on this topic.What changed?
I added a section that clarified it.
Checklist