I have a question regarding request limits for a REST service endpoint.

I think of course the most basic identification used to limit requests is by taking the user's IP address, but what if we have customers in an office using the same IP address?

I thought about using the HTTP Headers and other properties to fingerprint the user but the attacker could just change the user agent.

Is there a way to uniquely identify a device without the caller being able to maliciously altering its data easily?

  • Hi and welcome to the site! Could you elaborate a little on what you want to achieve? Normally there would be some sort of authentication that tells you what user the request is from. Here, it seems like you want to make sure that the request comes from a specific device or application and has not been altered by the user?
    – Anders
    Nov 18, 2022 at 13:18

3 Answers 3


Why not use a customer provided identity like an API key instead? This way, you can have an ultra high through put system that validates the requests and rate limits, then passes the rate limited traffic to your high request sensitive systems.


Apparently using IP addresses only to identify persons is a terrible idea - IPs in most of the cases do not identify a person, but rather a router, behind which possibly tens or hundreds of devices sit behind. That's why banning possibly malicious users by IP is a horrible idea - you might block entire offices, hotels and innocent people, which shared their internet access among others.

Your best approach would be fingerprinting using various fingerprinting JavaScript APIs - installed fonts, canvas data, browser window size (known as viewport I think?) etc and combining this information with IP addresses to uniquely identify devices.

To protect against DDoS Rate Limiting is what you're looking for..

Now for users trying to tamper with this information - most of it can be easily tampered with - Firefox contains settings which prevent fingerprinting, LibreWolf is even more hardcore on that. Brave also offers fingerprinting protection and even by default, so apparently most of this data will be randomized and spoofed making identification nearly impossible in my humble opinion.

  • Considering CGNAT systems of cellular providers (and the all use it works wide because there are wy too less IPv4 addresses) blocking one IP could have an even bigger effect that all your examples together.
    – Robert
    Nov 17, 2022 at 19:41
  • @Robert that's why I said among others... Nov 18, 2022 at 18:15

Your question has three parts:

The first has to do with limiting the rate of requests that can be made by a specific peer ("I have a question regarding request limits for a REST service endpoint"). This is usually related to defending your system against denial of service attacks. Normally you would want to apply one of the suggested mitigations or use a solution offered in the market.

However, if you want a quick-and-dirty solution, you can use the X-Forwarded-For HTTP header as a condition to limit the request rate. Beware that this is NOT a safe approach to rely upon, because the header is not guaranteed to be properly populated.

The second is related to device fingerprinting ("Is there a way to uniquely identify a device [...]"). It can be used to identify a device, however there isn't any easy way to do it, because software can be modified to adjust its fingerprint granularity (how unique the fingerprint is). So, in your case, you want to produce a fingerprint based partially on the HTTP headers sent, but those can (and will, if need be) change to modify the fingerprint at will.

Which brings us to the third part, which is about remote attestation ("[...] without the caller being able to maliciously altering its data easily?"). You can use remote attestation in order to verify that a user's browser is not modified in order to change its fingerprint, however remote attestation requires the use of trusted computing hardware, which is not available (or enabled) to every client you may have.

So, to answer your question, uniquely identifying a device is not an easy thing to achieve - if at all. As such, limiting the request rate based on a guaranteed client identification is practically impossible.

You must log in to answer this question.

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