3 ms·
That last one should largely be solved by 1) TLS 2) make your cookie __Secure- or __Host- - which then require the secure attribute. If DNS is wrong, it shou
by dgoldstein0 1y ago
That last one should largely be solved by
1) TLS
2) make your cookie __Secure- or __Host- - which then require the secure attribute.
If DNS is wrong, it should then point to a server without the proper TLS cert and your cookie wouldn't get sent.
- peanut-walrus 1y agoOops your developer accidentally enabled logging for headers. Now everyone with access to your logs can take over your customer accounts.
- londons_explore 1y agoYou could have similar secure handling of cookies on your server. For example, the server could verify the cookie and replace it with some marker like 'verified cookie of user ID=123', and then the whole application software doesn't have access to the actual cookie contents. This replacement could be at any level - maybe in the web server, maybe in a trusted frontend loadbalancer (who holds the tls keys), etc.
- thayne 1y agoIf DNS is wrong, that server can get a domain validated certificate. What I am imagining here is that you set a cookie with Domain set, and not __Host, possibly because you need the cookie to be accessible on multiple domains, and then someone sets up a CNAME that points to a third party hosting service without thinking about the fact that that would leak the cookie. Sure