A Set-Cookie header for a session needs HttpOnly, Secure and a SameSite policy, and the cookie is the only place those live. This produces the whole header, attributes included, rather than just the value.
What you can control
- Complete
Set-Cookieheaders with the security attributes a session cookie should carry. - JWT-shaped tokens with a real base64url header and payload, so a decoder can read the claims.
- API keys use the
sk_liveandsk_testprefix convention that makes an environment mix-up obvious. - Token length is adjustable, for testing a column limit or a header size cap.
What this is not
JWT tokens here have a syntactically valid structure but a random signature, so any library will reject them at verification. That makes them useful for testing the failure path and useless for the success path.
Questions
Will these JWTs verify?
No. The signature segment is random rather than an HMAC of the header and payload. Every library will reject them — which is exactly what you want when testing your error handling.
What do the cookie attributes do?
HttpOnly blocks JavaScript access, Secure restricts the cookie to HTTPS, and SameSite=Lax stops it being sent on most cross-site requests. All three matter for a session cookie.
Why prefix API keys with sk_live or sk_test?
So a key pasted into the wrong environment is visible at a glance. Stripe popularised the convention and it has saved a lot of accidental live charges.