Security implementations for RESTful API calls are paramount. Whether it is a web-service API that you are exposing to third-party, or creating an AngularJS/KnockoutJS web application, your service end-points increase the risk of your API being exploited and compromised. It is therefor important to consider (not only the security risks highlighted by OWASP) but also ensure that your end-points are vulnerable despite your security implementations.
- Generate RSA keys – remember to give it a unique name
ssh-keygen -t rsa
- Copy keys (
ssh-copy-id -i ~/.ssh/myserver_id_rsa.pub [email protected]) by installing the ssh-copy-id utility (
brew install ssh-copy-id), and test using
ssh -i ~/.ssh/myserver_id_rsa [email protected]
- Mount folder:
sshfs -o IdentityFile=~/.ssh/myserver_id_rsa [email protected]:/my/remote/folder /my/local/folder
Note: Setting this up only works with publickey authentication enabled.
- Cross-checking facts
Usually there are at least 2 interfaces involved in designing a web application (SaaS) or internal/intranet application
- Public facing – Product information and signup/registration process
- Application – The application/service being used, usually protected by a logging-in process
- Administrative application – An internal-facing application that is used for administering the application.There are 2 approached in this regard – combined functionality or separate.Reusing the existing application and including administrative features into it cuts down on development effort but increases risk for vulnerabilities and exploitation.Creating a separate application might require additional efforts, but this can be secured by using various security features and mechanisms (IP whitelisting, trusts hosts, firewalled appliances etc)
For each of the interfaces that are required, the following should be considered:
The last year or so we’ve been doing alot of mixed technologies for projects on REST web services written in either Microsoft technology stack or the open-source technology stack (LAMP), and what I discovered that the principles and disciplines are the same no matter what environment you work in, just the semantics (language/platform) that is different.
The company I was contracting to at the time had reminded me how easy it is to overlook certain elements of a project when designing a new system. The System/Application Anatomy (S/AS) was my first attempt to document and understand all the various influences that complicate the development efforts in the life-cycle of a system. This was before the implementation of SCRUM (project management at the time was Waterfall) and the developers tend to look at the “Functional implementation of requirements” only for estimation and planning (and as a result only portions of that). By expanding on the section, I tried encourage the developers in the team to consider all the factors that might influence their estimations.
Below is a table explaining the HTTP status codes I like to use when writing RESTful web service end-points. By using the codes consistently it allows me to have a clear understanding when and where these codes needs to be returned from the server side.