I have a publicly available API endpoint. I have to prevent a simple $.ajax script from downloading all of the exposed data within seconds and at least force a page refresh everytime a new request wants to be sent. While this wouldn't entirely protect it, it would help mitigate attacks while non-technical limitations allow us to protect it in a better way.

The problem is CSRF tokens can just as easily be retrieved from the page with javascript and the CSRF cookie is sent along with the ajax request. It seems like a request sent from a browser developer console looks just like a legitimate one. How can I differentiate them?

As a little note, I considered using a nonce in the cookie but that would also mean a page refresh for legitimate clients that need to query the data twice or thrice and that isn't allowed.


1 Answer 1


You can't.

Any legitimately authenticated user can absolutely manipulate any http request made to your API. Using a proxy such as Fiddler or Burp or just the browser console they can adjust headers, copy cookies pretty much anything.

If you need to rate limit something you have to maintain some sort of state on your server. A per session token in the auth cookie will let you do that, every request with a given cookie gets recorded and requests can be denied if too many requests are made within a certain cut off

  • Yeah, that's what I thought. I kept giving this a thought since it was a requirement by my company but I'll just end up implementing a bunch of dissuasive measures to make the process harder
    – patricio
    Oct 20, 2017 at 22:42
  • 1
    You need to explain why it's a stupid requirement and why it will only give false sense of security.
    – vidarlo
    Oct 20, 2017 at 23:18
  • @vidarlo exactly!
    – Xsmael
    Sep 22, 2023 at 0:22

Not the answer you're looking for? Browse other questions tagged .