Consider OWSAP and Comprehensive security as part of API development guidelines

 

With the recent increase in attack vector and threats,  an enormous amount of sensitive, personally identifiable data of consumers has been captured by unknown hackers, so organizations needs to build the necessary cyber resilience. As the organizations allow REST based programmatic access to their core infrastructure, it is important to ensure that REST APIs and custom applications utilizing REST API are secure. Such security depends on the interactions of a number of technologies and project-team functions that protect the network from accidental or malicious application behaviors.

APIs security is becoming increasingly critical as more and more business functionalities gets exposed to the rest of the world. Security should never be an afterthought—it’s an integral part of any software system design, and it should be well thought out from the design’s inception.  Security by Design starts  with requirements gathering and proceeds through the Design, Development, Testing, Deployment, and Monitoring phases. A proper security design should include all the communication links in the system. Your system is no stronger than its weakest link.

OWASP seeks to educate developers, designers, architects and business owners about the risks and security vulnerabilities and provide tools, document and code library projects in a neutral manner.

These are organized into three categories, tools and documents that can be used to find security-related design and implementation flaws, tools and documents that can be used to guard against security-related design and implementation flaws and tools and documents that can be used to add security-related activities into the application  lifecycle management (ALM).

A great starting point is OWSAP defined cheat sheets including the ones for REST and Mobile(IOS).

—————————————————

An example from REST cheat sheet,

Authentication and session management:

RESTful web services should use session-based authentication, either by establishing a session token via a POST or by using an API key as a POST body argument or as a cookie. Usernames, passwords, session tokens, and API keys should not appear in the URL.

For example,

OK:

https://example.com/resourceCollection/<id>/action
https://twitter.com/vanderaj/lists
NOT OK:

https://example.com/controller/<id>/action?apiKey=a53f435643de32 (API Key in URL)
http://example.com/controller/<id>/action?apiKey=a53f435643de32 (transaction not protected by TLS; API Key in URL)

 

An example from IOS cheat sheet,

Insecure Data Storage (M1)

Without a doubt, the biggest risk faced by mobile device consumers comes from a lost or stolen device. The information stored on the device is thus exposed to anyone who finds or steals another person’s device. It is largely up to the apps on the device to provide adequate protection of any data they store.

———————————————————-

It is in the best interest of organizations to introduce security guidelines and rules that make contextual sense for their needs, not just because something has been published. So embrace comprehensive security leveraging OWASP guidelines and specific controls and functionalities provided by the adopted technology platforms which will be more effective to train and enable developers to use them consistently.

More important is a contextual list of necessary security controls that must be used throughout an application and APIs. And by contextual I mean the list is specific not only to the company or organization, but also contextual to the language, framework and platform being used. For example, if framework being built on prohibits direct access to a database, then instead everything must go through an object model. For threats like SQL Injection, unless the vulnerability is in the underlying framework, which would need to be addressed by the framework developers or an internal security team tasked with mitigating vulnerabilities introduced by third party software. Irrespective of  various layers, it is always a best practice to implement a certain level of default security controls at the API gateway layer.

Also security by design will vary depending on the type of APIs e.g. public, partner or private/internal APIs.

Again there is a need for API asset classification based on security, compliance and privacy needs. Additional classification criteria’s needs to be defined e.g. Atomic Segments (Elements that share the same policy and protection characteristics), Trusted Channels (Protect interactions and data flow between segments) and Data masking elements.