Hello Everyone, Can anyone tell me when designing a secure RESTful web service, what points should be followed? I am preparing for a web service interview and I want to know about this.
You must choose explicitly what you want to expose from your system. Resist the temptation to make a generic API endpoint that could access any table and return data from it, and especially a generic API endpoint that writes to any table based on parameters - both of these would be huge security holes and a nefarious actors dream.
For a standard database table that you both read and write from, you use the same API endpoint name. Say you have a table like “invoices”. You could do an api endpoint like “/invoices” and in your doGet you have some logic that returns maybe the 1000 most recent invoices, and in your doPost, you would have logic for validating the information before writing it to the database, and then returning a success/error value.
Regarding your doPost, I highly recommend putting any validation functions/modification functions of the incoming data before posting into a separate function. This way, say there comes a day when you want to make a Vision or Perspective client - then you can utilize the same validation/modification/insert function, so that no matter what way some tries to make a new invoices, the same logic is applied. The trickier part is customizing the response for errors/success for vision/perspective/your webdev api, but but that part you could probably generalize a bit more.
I have not done things this way but I don’t see why you can’t have Vision/Perspective hit your same API endpoints, and then from there have Vision/Perspective parse the response messages in appropriate ways. Might cause a CORS issue but should be resolvable.
Check our the response codes and send back the appropriate ones for success or error - you can see the different codes here. Normally 200 is used for success, and the error is will be dependent on other factors.
Try to follow standard JSON response objects for APIs - I am not sure what the context for your API is, but if you want to ever expose your data so that other applications can use, it’s best to follow the standard that everyone else uses. Check out standard json responses here.
Last thing and goes without saying since I already mentioned validating inside your API logic but do not rely on client validation. All validation should be done on the server side. Clients can be spoofed, especially if you’re serving up a website, a user can see exactly what payload they are sending you, and could, if desired send you a completely custom payload to the API, bypassing all client validation.
Caveat - if you expect a large userbase and a lot of clients, you can still utilize client side validation to help lower the load on the server, but again, validation should ALWAYS be done server side.
Last thing - definitely use the security settings on your API. If you don’t then any random internet person who has your API URL can hit it whenever they want. You’re opening yourself up to DDOS attacks by allowing anyone to hit your API.
That’s all I got off the top of my head. I’m sure others have good thoughts on this as well.
2 Likes