REST Service Security Design Principles

-

REST Security Design Principles

Below are the security design principles.
  1. Least Privilege: An entity should only have the required set of permissions to perform the actions for which they are authorized, and no more. Permissions can be added as needed and should be revoked when no longer in use.
  2. Fail-Safe Defaults: A user’s default access level to any resource in the system should be “denied” unless they’ve been granted a “permit” explicitly.
  3. Economy of Mechanism: The design should be as simple as possible. All the component interfaces and the interactions between them should be simple enough to understand.
  4. Complete Mediation: A system should validate access rights to all its resources to ensure that they’re allowed and should not rely on cached permission matrix. If the access level to a given resource is being revoked, but that isn’t reflected in the permission matrix, it would violate the security.
  5. Open Design: This principle highlights the importance of building a system in an open manner—with no secret, confidential algorithms.
  6. Separation of Privilege: Granting permissions to an entity should not be purely based on a single condition, a combination of conditions based on the type of resource is a better idea.
  7. Least Common Mechanism: It concerns the risk of sharing state among different components. If one can corrupt the shared state, it can then corrupt all the other components that depend on it.
  8. Psychological Acceptability: It states that security mechanisms should not make the resource more difficult to access than if the security mechanisms were not present. In short, security should not make worse the user experience

Best Practices to Secure REST APIs

Below given points may serve as a checklist for designing the security mechanism for REST APIs.

Keep it Simple

Secure an API/System – just how secure it needs to be. Every time you make the solution more complex “unnecessarily”, you are also likely to leave a hole.

Always Use HTTPS

By always using SSL, the authentication credentials can be simplified to a randomly generated access token that is delivered in the username field of HTTP Basic Auth. It’s relatively simple to use, and you get a lot of security features for free.
If you use HTTP2, to improve performance – you can even send multiple requests over a single connection, that way you avoid the complete TCP and SSL handshake overhead on later requests.

Use Password Hash

Passwords must always be hashed to protect the system (or minimize the damage) even if it is compromised in some hacking attempt. There are many such hasing algorithms which can prove really effective for password security e.g. MD5, SHA, PBKDF2, bcrypt and scrypt algorithms.

Never expose information on URLs

Usernames, passwords, session tokens, and API keys should not appear in the URL, as this can be captured in web server logs, which makes them easily exploitable.
https://api.domain.com/user-management/users/{id}/someAction?apiKey=abcd123456789  //Very BAD !!
Above URL exposes API key So, never use this form of security.

Consider OAuth

Though basic Auth is good enough for most of the APIs and if implemented correctly, it’s secure as well – yet you may want to consider OAuth as well. The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.

Consider Adding Timestamp in Request

Along with other request parameters, you may add a request timestamp as HTTP custom header in API request. The server will compare the current timestamp to the request timestamp, and only accepts the request if it is within a reasonable timeframe (1-2 minutes, perhaps).
Input Parameter Validation
Validate request parameters on the very first step, before it reaches to application logic. Put strong validation checks and reject the request immediately if validation fails. In API response, send relevant error messages and example of correct input format to improve user experience

Comments

Post a Comment

Popular posts from this blog

Email Sending through O365 using OAuth Protocol

-
  Microsoft Office365 EWS servers have been extended to support authorization via the industry-standard OAuth 2.0 protocol. Using OAUTH protocol, user can do authentication by Microsoft Web OAuth instead of inputting user and password directly in application Microsoft / Office 365 OAuth + EWS We can use the OAuth authentication service provided by Azure Active Directory to enable our application to connect with IMAP, POP or SMTP protocols to access Exchange Online in Office 365. To use OAuth with our application we need to register application on Azure Active directory and other steps also we need to do to get the access token back. Below are the steps   To use Microsoft/Office365 OAUTH in your application, you must create an application in  https://portal.azure.com . Sign into the Azure portal using either a work or school account or a personal Microsoft account. If your account gives you access to more than one tenant, select your account in the top right corn
Read more

IISRESET vs App Pool Recycling ?

-
Image
 I think most IIS administrators know IISRESET command, and why they use it. One of possible reasons can be to restart IIS services to initialize web applications, or to apply some changes of applications & IIS settings .There’re just a few conditions those need your IISRESET command. In most situations, you don’t need this. I have a concern if you always run this command for applying any changes, or release system resource – memory – regularly, or frequently. Because it’s much more cost than what you really need to take – there’re side effects Recycling App Pool’ has been introduced from IIS6 in Windows2003. It’s designed to restart only application pools(=worker processes). It can be done in a command prompt(run ‘IISAPP /?’ in a command prompt for details), as well as in the IIS manager What IISRESET does? When you run IISRESET, many things will happen. In order to understand them, I think I need to show you how IIS looks like – about IIS core components. The below shows you role
Read more

Deploy .Net6.0 Web api with docker

-
Image
  What is Docker? Docker is a containerization platform, meaning that it enables you to package your applications into images and run them as “containers” on any platform that can run Docker. It negates the classic: “It works on my computer” argument as Docker images contain everything needed for the app to run. Are Containers the same as Virtual Machines? They are similar, but not the same. In short: Virtual Machines provide OS Level Virtualization Containers provide App Level Virtualization This concept is depicted below: Why Would You Use it? In short you would use Docker, (and hence containers), for the following reasons: Portability.  As containers are self- contained  they can run on any platform that runs Docker, making them easy to stand up and run on a wide variety of platforms. Scalability.  With the use of additional “orchestration” you can spin up multiple container instances to support increased load. Performance.  Containers generally perform better than their VM counterp
Read more