3 ms·
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
by reza_n 8y ago
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.
- chrisseaton 8y agoIt'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.
- jimktrains2 8y agoNot just browsers, but any service.
- reza_n 8y ago> 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.