Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



If 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


Oops your developer accidentally enabled logging for headers. Now everyone with access to your logs can take over your customer accounts.


You 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.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: