How to secure my API, if I want to use it on a different server

Wappler General How To
#1

Hi,

I already had a similar topic someone time ago (How to use Security Provider with a Server Connect Action from another site)

Brian helped me a lot with this. After reading the following article https://restfulapi.net/security-essentials/ I think I should do more to secure my API.

@George, @Teodor, @patrick what do you recommend how to secure an API if there is no possibility to use sessions?

Thanks a lot for your help.

Marcel

Unable to display Server side "API Action" data on my page
#2

Hi,

So just as an idea on how I would do it if i could not use sessions. also, i’m guessing here that you mean the server side sessions.

Have a key that needs to be present in the request to authenticate each request, without this key nothing can be done/executed. And getting this key could be gotten by an endpoint which takes username and password to return this key. Which is also kept in a db for x amount of time(which you purge after set x time), so you can use it to compare it with the key from the requests made, if it is present you continue the request and if not you stop it.

Basically you create your own session handler but utilizing your DB and your API endpoints and some db scripts to purge sessions.

FYI: This is just a basic idea that quickly came to me and there is zero risk assessments made on it, I have the benefit that my work it contained within a domain, so i don’t have to worry about external factors and only internal, which makes it a bit easier:)

Regards,

Nick.

#3

Thanks @pheaxx for sharing your idea. I will try to figure out how to do this. I had the hope that there would be a solution by the Wappler Team :slightly_smiling_face:

#4

What about something like this?

  1. send your identity key ($api_key)
  2. add a second parameter timestamp ($timestamp)
  3. add a third parameter of the datetime encrypted, perhaps using something like hash_hmac(‘sha256’, $timestamp, $api_key)
  4. on the API call firstly check the datetime against whatever expiry time you want to set (can be very short) and send unauthorised back if expired
  5. recalculate the encrypted datetime and check the validity against the parameter passed and send unauthorised back if expired
  6. check any other credentials you may have optionally passed and send unauthorised back if expired
  7. if all correct perform action
#5

Sorry, old thread. For some reason this popped up as current and i didn’t read the post date before replying!