Friday 12 October 2012

Key considerations for securing your REST web service API


Securing your REST service API layer is not just about considering whether you should use OAuth 2.0 or not, or whether REST needs something like WS-Security.  It is about considering why you should care about security, who you are protecting your service against, what the risks are, and more general security principles than just authentication and authorisation.

Why?

Do your service API need securing?  The answer to this will depend on your business, and the nature of the service, but you will want to consider whether there are any reputational, financial or regulatory consequences to a security breach of your service, and if so, how to deal with it appropriately.



Who?

In order of likelihood of actualised loss, the following groups of people offer a potential threat to your RESTful services:
- Disgruntled staff or developers
- “Drive by attacks”, such as the consequences of a virus
- Motivated criminal attackers, such as organised crime
- Criminal attackers without motive against your organisation
- Script ‘kiddies’

Key Security Principles

Confidentiality - only access to data for which the user is permitted
Integrity - ensure data is not tampered or altered by unauthorised users
Availability - ensure systems and data are available to authorised users when they need it

Minimise attack surface area, e.g. restricting search functions to logged in users
Secure defaults, e.g. set password expiry on by default
Principle of least privilege, e.g. don’t allow developer access to production database
Principle of defence in depth - e.g. validation and authorisation at all tiers
Fail securely, e.g. on login failure
External systems are  insecure, i.e. don't trust them
Separation of duties, e.g. someone who requests a computer cannot also sign for it
Do not trust security through obscurity, e.g. security of an application should not rely upon knowledge of the source code being kept secret
Simplicity, i.e. simpler applications are easier to secure
Fix security issues correctly

What are the risks? 

According to the OWASP organisation, some of the key risks to consider are:
- injection
- cross-site scripting
- broken authentication and session management
- insecure direct object references
- cross-site request forgery
- security misconfiguration
- insecure cryptographic storage
- failure to restrict URL access
- insufficient transport layer protection
- invalidated redirects and forwards




Share: