#Preventing Backend Abuse

8 messages · Page 1 of 1 (latest)

warm pecan
#

Hi, I had a very basic yet important question to ask -

For the visitor count feature, we're supposed to create an API endpoint which calls the DB and retrieves as well as updates the value.

My question is this -

What prevents anyone from simply calling the backend api and simply increasing this count, thereby tampering with the data.

Implementing CORS wouldn't help, as it can easily be spoofed.

Any leads on this would be really helpful

supple osprey
# warm pecan Hi, I had a very basic yet important question to ask - For the visitor count fe...

What prevents anyone from simply calling the backend api and simply increasing this count, thereby tampering with the data.
Nothing (well, you). Look into rate limiting strategies to reduce invalid use cases.

Rate Limiting Fundamentals (paywalled via substack): https://blog.bytebytego.com/p/rate-limiting-fundamentals

Rate Limiting Fundamentals

Rate limiting is a popular distributed system pattern. It is an integral part of all modern large-scale applications. It controls the rate at which users or services can access a resource, like an API, a service, or a network. It plays a critical role in protecting system resources and ensuring fair use among all users.

warm pecan
#

So, I just wanted to see if there were any other techniques, which I might have been oblivious to

Rate limiting is inbuilt into services like Amazon API Gateway, so that wasn't the exact concern.

But this looks like a good resource to understand the exact implementations for any rate limiting, thanks @supple osprey

sour wave
#

It's a good question! If this were an API that interacted with sensitive data, you'd of course want to put authentication and authorization on it - read up on OAuth for some standard ways this is done. In this case, you're mainly concerned about not having the API called too often - so I would look into quotas, rate limiting, and WAFs.

#

You could also think about whether you want your counter to track every visit to the page (a "hit counter") or just unique visitors (a true "visitor counter"). In the latter case, you could consider maintaining some state on the backend, such as IP address, and use that to help decide whether to count a hit as a new visit. This is actually suggested as one of the mods in the challenge guidebook.

warm pecan
#

Thanks @sour wave .

I was wondering doing that but with keeping the ips stored for a temporary period of time.

I recall reading somewhere that if we store the IP Addresses of visitors, we're supposed to have a Privacy Policy or disclaimer in place

sour wave
#

the question of whether IP addresses should rightly be considered PII (personally-identifying information) is a little squishy - though I believe GDPR does consider them such. So a good extension to this project could be going through the process of setting up a privacy / cookie policy

#

(you could also look at encrypting IP addresses if you are going to store the on the backend)