❔ How to ensure an api can be used securely
So I'm currently making a REST api that users can use to help them build analytics of certain things
But the thing is, how do I ensure a user can safely implement the api into their code, because it's linked to analytics I don't want any random person to come and just send the request a million times to spam a users dashboard
I know I can't prevent a user from implementing a faulty system into their application, but I can at least ensure to give a guide on how it could work
Or what things do I as the api author need to ensure
10 Replies
and just send the request a million timesare you really scared of this? will there be many people using these api? anyway you can put rate limiting, i don't know if you will have "levels" of access to the api btw http 429 is the status code for this
I mean I want the user of the account to link the api with their things to ensure proper analytics
But I seen often enough that people get the api data and route and just spam the request
Which in turn would disrupt the analytics data
I don't mind the owner of the api key sending it a million times it's their key but I don't want a third party to deal with it
Or do I just not care and leave it up to the key owner?
it depends on a bunch of things, how and where is this api is used, how easy is to get to it and/or sniff it, if you have authentication and authorization, and how much do you want to complicate the life of your users
one practice is make your users send a key that invalidate every few minutes so that they have to refresh it, but again security from your part is useful up to a certain point
other stuff you can do is whitelist the ip, check for cookies, user agent, and so on
Normally the api isn't being embedded into a frontend directly so in the regular use case a user should not be able to ever see the api
The api is supposed to be embedded into another backend of the api key holder
So I wonder
Do I as the api maintainer have the responsibility to protect the few that won't do it the intended way
is there a contract/order involved?
there is always a lot to think and to do as a programmer, everything you add will be "used against you"
(and will be a burden to maintain)
i'm not saying you should always stick to the minimum, it depends on the situation
i at least would keep my responsibilities to what i can "defend", so protecting my systems by whoever abuses it
then probably it's the trust relationship between you and your users that can dictate what extra efforts to take
the api is supposed to be linked into payment handlers
for example if you have a pay with paypal button on your website, you link my API into it therefore i ASSUME its pretty secure since this endpoint of the user would only fire when paypal makes a successful transaction
couldnt i just put in the user agreement (or whatever the service usage policy is called i forgot the name rn) that im taking no responsibility if they use the API in an insecure way or smth
i mean i cant do anything if a user exposes smth like the api key
then i guess you could look into secret management
keeping keys and passwords and stuff in the code is quite bad
How the user handles his tokens is up to the user
Best I can do is a configurable AES and signiture checking
again, it depends on the architecture of the whole system
for particularly sensible stuff sometimes there's the practice to store a key in a separate storing service so that it will be an agent service that reads the key and do what it's supposed to, completely isolated from users' access
but adding this stuff (or using a cloud platform) would mean more costs and complexity
Was this issue resolved? If so, run
/close - otherwise I will mark this as stale and this post will be archived until there is new activity.