Hacker News Reader

To me this sounds like a CSRF problem. There's no token or session associated with these calls, so a browser was able to inadvertently CSRF the calls. Changing this call to POST or PUT would still leave this API vulnerable.

View on HN

It's not about access control, it's about the fact that browsers are free to make speculative GET requests whenever they like, and they actively do to pre-fetch pages. His GET end-point was pre-fetched by his browser, activating the door. This would still happen even if there was a token or session associated.

Not just browsers, but any service.

> This would still happen even if there was a token or session associated.

This is exactly the scenario a CSRF token is support to prevent. But I understand your point.

Reply on news.ycombinator.com