REST Security Design Principles

Security Design Principles

If you have been following us, we have been posting for some months now, focusing in raising awareness and explaining which are the most common vulnerabilities that you can find in your applications.

Having finished with the OWASP Top 10 related to APIs, we thought it was a good idea to wrap up the section by sharing with you 8 high level Security Design Principles that, if followed, should help mitigate most if not all of those vulnerabilities.

Taking into account the above, this story will differ from the previous ones and will focus on highlighting good practices to develop software that is secure.

The principles to be discussed are:

• Least Privilege
• Fail-Safe Defaults
• Economy of Mechanism
• Complete Mediation
• Open Design
• Separation of Privilege
• Least Common Mechanism
• Psychological Acceptability

Least Privilege

An entity should only have the required set of permissions to perform the actions for which it is authorized, and no more. Permissions can be added as needed and should be revoked when no longer in use.

Fail-Safe Defaults

A user’s default access level to any resource in the system should be “denied” unless they have been granted a “permit” explicitly.

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.

Complete Mediation

A system should validate access rights to all its resources to ensure that they are allowed and should not rely on the cached permission matrix. If the access level to a given resource is being revoked, but that is not being reflected in the permission matrix, it would be violating security.

Open Design

This principle highlights the importance of building a system in an open manner, with no secret or confidential algorithms being exposed in the code or repository.

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.

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.

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.

Resources

Other than the principles, there are a lot of resources that can help you get better at achieving your objective of designing and developing secure programs.

Here I will leave you some that can be useful to you, your company and your users:

• APIsecurity.io: The Latest API security News, Vulnerabilities & Best Practices.
• API Security Checklist: A security checklist you can resort to when building your API.
• OWASP API Security Project: Open Web Application Security Project’s API resources.
• Strike.sh Medium: Weekly posts on latest vulnerabilities & helpful secure coding libraries and practices.
• Strike.sh LinkedIn: Daily news, secure tips, publications and memes so you are always up to date with the latest attack trends and what is happening in the industry.

Conclusion

As mentioned before, the idea of this post, was to give you an insight to what secure design principles looks like. If you are not able to achieve all of them, try picking any two and going for them.

When applied correctly, your applications would be guarded against most logical vulnerabilities that could cause breaches for example.

Hope it has been useful and thank you for taking the time and reading this week’s story on application security. As usual, if you have any doubts or need any help, anyone at Strike will be happy to help you. You can reach out to me here or in LinkedIn!

If you want to see daily news, tips and funny memes (yes, we are into that too :D), be sure to give us a follow there too.

Cheers from Strike :)