Web API Security Auditing Best Practice Standards and Checklist

Web Application Programming Interface (API) is a medium or intermediary through which an application interacts with another application for the purpose of exchange of data. Applications typically render services or allows use of its data through an API. To be able to connect to or communicate with an API, there are set of rules and standards that are defined with the API for which the external application or human consumer must follow for successful retrieval or posting of data to the interface. These rules and standards are captured in the API documentation or specification of the host application. There are different Web API services, however, the most commonly used are SOAP and REST APIs. SOAP means Simple Object Access Protocol while REST stands for Representational State Transfer. The predominant API interface between them is the REST API, which is based on HTTP protocol, and generally JSON formatted responses. SOAP API only works with XML unlike the REST API that can do XML, HTML, JSON and plain text. API interface security has become an integral component of internet or web access security. However, because of its wide usage, it has presented additional challenges due to:

Exposure to a wider range of data in the application database:
This including transactional and personal identifiable information, which are subject to several regulatory and legal protections (e.g. PCIDSS, GDPR, etc.)
Direct access to the back-end server:
API typically have direct access to backend servers and processes, which poses significant security risk where security controls are not properly calibrated and layered.
Ability to download large volumes of data:
Large volume of data could be downloaded from an API endpoint without any restriction.
Different usage patterns.

Below are some of the security controls that could be implemented in an API to restrict access and promote secure usage.

Define Security Baseline for APIs

Remember that you cannot control what you did not define. Every organization that intend to open its core application for external access through web API must document an API standard or security baseline that guides the operations and access to its data via the API. The application security baseline should stipulate the rules of connection to the different data endpoints. Open Web Application Security Project (OWASP) security guidelines is one of the leading standards and best practices in the web application security and API industry and as such, most organization simply adapt their API security baselines to the requirements of the OWASP framework.

Authentication

One of the requirements of the OWASP guidelines is the enforcement of strong authentication control for access to application data (view only) or insertion of data into application backend database through the API. Typically, the first line of defense is to identify the user (i.e. human or application) that want to consume the API service by determining that the user has permission to invoke your API. This is similar to entering a user ID and password when trying to gain access into an application. For an external application, a service account is typically granted access to the API with a password that is usually authenticated to open a connection session with the API to retrieve or insert data into the backend system.

Authorization

Another requirement of the OWASP guidelines is the enforcement of strong authorization control for access to application data (view only) or insertion of data into application database through the API. Authorization control comes to play after a user (application or human) has been successfully authenticated. The API should be able to determine what the user have been granted access to and what access has been denied. Authorization control is therefore to validate the resources the user has been allowed to access at a given time. For example, a user could be allowed only a read access (i.e. GET) while POST (create), PUT (replace/update) or DELETE (delete record) have been expressly denied. In other cases, a GET and POST access could be allowed, which depends on what you want the user to do. Therefore, it is important that these accesses are determined and properly calibrated for each user based on the need to do and principles of least privilege for access. An additional identifier could be introduced for access to the web interface. For every POST, PUT or DELETE API request, an API ID and an API key is required for users to complete the request. The API key is a unique string generated from the application for each user of the API as an additional layer of security.

Access Control

Typically, not all authenticated users will be authorized to access all endpoints or services provided by APIs. For example, some users or application will require access to only retrieve (GET) information from the API, but should not necessarily be able to change/replace or update (PUT) any information in a database. This can be achieved using an access control framework, such as OAuth, which can be used to control the list of API endpoints that each specific API key can access. To prevent a distributed denial of service (DDoS) attack on APIs, which is characterized by massive amount of API requests within a short period of time or other misuse of the API service, limits or cap are applied on the interface per user to limit or control the number of requests a user can make within a given time interval for each API. When the call rate or limit is exceeded, access is temporarily denied on the API for a user accessing from an API key while a 429 (too many requests) HTTP error code is returned to the user. The limits are renewed typically after the specified period of time (e.g. in hours).

Encryption

To protect the request in transit, HTTPS protocol is required for all access to protect messages in transit from being intercepted. This can be achieved using TLS message encoding. It is important to note that TLS 1.0 and 1.1 has been widely proven to be insecure and vulnerable to man-in-the-middle attack that could risk integrity and authentication of data. Also, there is a risk of heartbleed and Poodle attacks for TLS 1.1. However, TLS 1.2 and higher remain secured and should be used for all SSL encryption. JSON Web Token (JWT) should be implemented to protect the JSON formatted response. JWT is an open standard RFC 7519 that defines a compact and self-contained way for securely transmitting information between parties as a JSON object using digital signature for trust and verification such as the RSA public/private key pairs.

Confidentiality

Best security practice requires that confidential information should not be exposed to unintended users. As such, in all APIs, error should be carefully handled to prevent exposure of backend processes and server information that could aid in launching attacks against the API. This can be achieved by proper error handling process to display generic messages in the place of backend confidential information to prevent the exposure of database.

Application Layer Attacks

There are different ways through which an attacker or malicious actor could gain unauthorized access to an API or even backend application to wreak havoc. One of the most effective methods is to obtain authorization and authentication credentials via phishing attacks on authorized users. Attackers typically conduct footprinting and reconnaissance to identify their target systems and persons before narrowing efforts towards them. You’ll need to validate all data to prevent application layer attacks, such as:

Cross-site-scripting (XSS)-
Malicious scripts are injected into one of the request parameters. This can be prevented by following secure coding practices/standards, fixing bugs and keeping application up-to-date with the latest security fixes, validate all inputs in the application and implementing web application firewalls (WAF).
Code injection-
Inject valid code to services and queries, such as SQL injection or XQuery, to open the interface to user control. This can be prevented with WAF solution and validating all inputs in the application.
Business logic-
Allows the attacker to circumvent the business rules implemented in the application.
Parameter pollution attacks-
Exploit the data sent in the API request by modifying the parameters of the API request. This can be prevented by whitelisting parameters with expected values and blacklisting risky contents, such as SQL schema manipulation statements.
Log all API access. This is essential to assist resolving any issues. From these logs, you can easily monitor activity and potentially discover any patterns or excessive usage activity.

API Middleware Applications

For proper security, consider using an API middleware application or framework that has many of the security features built in. This will enable you leverage the existing and already optimized security standards to enhance your API security posture. However, if you must develop your own API, separate the security portion of your API from the application portion. This is to ensure easy and more layered approach of administration and monitoring and as such, promote uniform security across board to enable developers focus on the application logic and functionalities. Ensure that your API are adequately tested by engaging services of penetration testers and red team to adequately scope and perform your testing for better security benefits.

Nwabueze Ohia

(Cybersecurity consultant, Tech Blogger & Author)

Will appreciate your questions and contributions on to post. For sponsorship, ad placement, speaking opportunity and training bookings, please Contact US or Send us an email at info@oxleyconsults.com.ng.