API security Tutorial

What is API Security?

As APIs make the entrance of your network or application, API Security in a present day is one of the most mportant component of web security. 

Organizations, breached by the entities they entrusted or due to their vulnerabilities, have now opted for the zero-trust model. It implies that no human or computer will be able to access a resource until authorized. And even when the authorization is done, threat monitoring and prevention will remain essential for the network. 

Opting for the above approach is required because APIs face unlimited threats every day. Cybersecurity strategy, revolving around authentication, authorization, and threat prevention can safeguard your APIs really well.

In this article you will learn how API Security is built from all sides, how to make pentest in-house using opensource tools and how to protect API.

‍

What Does API Security Entail? 

APIs, related to the app that you own, can only be controlled. This is why security API is focused on securing APIs that are exposed to a user, directly or indirectly. APIs, offered by other parties, that a user consumes are not a prime priority of Web API security as valuable insights related to such APIs can be gained by detailed analysis of outgoing API traffic. 

One another key point to note here is that API security practice implementation involves multiple teams and systems. Network security principles like throttling, rate limiting, along with key data security concepts like identity-based security and analytics are a part of API security.

‍

API Security Checklist

Not sure where you stand with API security?  

Wallarm API Security Checklist can serve as a starting point for Engineering and Security teams looking to keep APIs compliant and secure.

In this checklist we have collected all the common API safety vulnerabilities and their consequences. We also gave recommendations on how to fix them and mitigation strategies.

Download the API Security checklist by Wallarm

‍

API Protocols

Based on the requirements, APIs can be used in various forms and styles. The chosen API style (REST, SOAP, GraphQL, gRPC, Websocket or Webhooks) decides how API security should be applied and implemented.  Before web APIs came into being, the key API style uses were SOAP Web Services. In the era of service-oriented architecture WS from 2000-2010, XML was used widely.  

API Protocol Comparison

‍

API Security for Cloud, On-premises and Hybrid Deployments

The current advancements in the technology areas like cloud services, integrated platforms, and API gateways have granted APIs providers the ability to secure the API in multiple ways. The type of technology stack picked for building the APIs has a direct impact on the procedure used for securing the APIs.  

For instance, a large organization might be using multiple applications with their own APIs. As organizations merge all these applications, various API silos or stacks are created. The API security requirements related to one API silos can be easily directly mapped from the silo’s technology. 

From a portability point of view, it’s crucial to have used security configurations to be highly portable so that they can be easily transported or extracted to any futuristic technology.

In a heterogeneous ecosystem, the API security-specific infrastructure across the API silos is used widely for defining the API security practices. The connection between API silos and API security infrastructure is configured as sidecars, sideband agents, and APIs embedded between cloud and on-premise deployments. 

‍

Layers of API Security

API security is a diverse area with multiple layers. The focus of each layer is on specific API security and is designed to earn a specific and strong protection level.

API Discovery

The first layer of API security is dedicated to API discovery, as one can’t save anything if there is no idea about the target or threat. There are a couple of obstacles that keep security operatives away from having full visibility of the used APIs. API silos, as quoted above, is the first obstacle, as it hampers the API visibility as it grants access to a partial API list.

Rogue or shadow API is the second most hurdle in API visibility. It occurs when an API that is a part of the development and itself serves as application implementation. Shadow APIs happen when an API is developed as part of an application but the API itself is considered an implementation detail of the application and is only known by a close-knit group of developers. Shadow APIs are not on the radar of security operatives because they don’t have visibility into the implementation details.

Finally, APIs go through their lifecycle. An API evolves, new versions of an API come up or an API may even be deprecated but continue to operate for a temporary period for backward compatibility and then be forgotten or gradually fall off the radar because they receive very little traffic.

API discovery is a race between API providers and hackers who will easily exploit the APIs when found. To discover your APIs before attackers do, you can mine your API traffic metadata. This data is extracted from API gateways, load balancers, or directly inline of network traffic and then fed to a specialized engine that reports on an effective list of APIs which can then be compared with catalogs of APIs that are available via an API management layer.

‍

API Authentication Methods

The task of verifying users’ identity is imperative as it keeps ill-usage of API at bay and verifies user authenticity before granting him the access to the stored information kept for better Web API Security. It involves verifying the identity of someone who tries to view or edit the API resources, allowing only authenticated users for the same.

1. Host-based authentication
   

The host-based authentication schema is widely used for IOT devices and raw network authentication. It is not recommended for web technologies since it can be bypassed with spoofing. This process comprises verifying the host or server so that only the verified users can access resources deployed on the servers. It doesn’t demand any key or other means to initiate the process. However, the server should be competent to validate the login keys beforehand to keep the incidents of DNS spoofing, routing spoofing, and IP spoofing under control. 

In the process and manner, it’s very much similar to RSA. 

The argument used here is either yes or no. By default, no argument is set. The host-based verification of users can be done by an administrator by creating a private key for the local host or extracting the public key used for the localhost. 

2. Basic authentication
   

One of the most straightforward API identity-confirmation schemes, this method is crafted using HTTP protocol and process as the client dispatches an HTTP request with a pre-built header for verification of authenticity and demanding credentials like account’s password and username. This basic check is done in a browser-powered environment.

Being supported by every possible browser and server makes basic identity-confirmation the most common one. The credential details are shared over the network in the form of cleartext and are encoded using base64. The credential details are shared over the network in the form of cleartext (or base64) by default, this is a bad practice since it gives man-in-the-middle attack vectors. The good practice is to encrypt the credentials using algorithms such as RSA, SHA-256 or even custom made ones.

It is functional over proxy servers and grants access to resources not hosted on IIS servers. As it fails to add encryption, not much security can be expected out of it. Also, it’s more prone to replay attacks.

3. OAuth
   

OAuth is the open method of identity confirmation. It is a customary API authenticity-verification technique that covers users’ identity verification and defining authorization criteria. The protocol is used widely for allowing applications to authorize their users based on tokens, published from OAuth server (such as Google).

It requires asking for a token when someone tries logging into the system. The token serves here as the means of verifying and approving the user identity. The person/request-creator has to forward the request to accessing the resource to the authentication server. Based on the quality and result of identity-verification, the server can accept or reject the request. 

OAuth is safer and more secure than other processes making it the first choice for many. The three key ingredients of OAuth are OAuth provider, Google and Facebook are the common ones, OAuth Client, refers to the information-owning website/page, and owner, denotes the user making an access request.

4. OAuth 2.0
   

A widely used protocol of API access management, OAuth 2.0 is an updated version of OAuth. Its functioning involves keeping the API client access limited by using HTTP services for the client application enabling. Some HTTP services needed for this sort of protocolare GitHub and Facebook. It takes the help of a code for identity-verification and doesn’t ask for user credentials.

The three factors involved in OAuth 2.0 are the user, who is possessing the data to which the API wants the view or edit permission, the application, and the API.

Using this method for identity confirmation, it’s easy to interpret user data using different resources. It can be deployed for the verification and approval of web-based, mobile-based, and desktop-based applications/devices.  

5. SAML
   

SAML stands for Security Assertion Markup Language and is a standard API process for identity confirmation using single-sign-on technology. It denotes confirming the user as per the provided details. Once the process completes and the user is verified, access to assorted applications/resources is granted. Presently, its SAML 20 version is running. It’s very much similar to the ID. Only user identity assessment is done with its help.

API Security OWASP TOP 10 Vulnerabilities

API1:2019 Broken Object Level Authorization

APIs will in general uncover endpoints that handle object identifiers, making a wide assault surface Level Access Control issue. Item level approval checks ought to be considered in each capacity that gets to an information source utilizing a contribution from the client.

API2:2019 Broken User Authentication

Validation systems are frequently executed mistakenly, permitting assailants to think twice about tokens or to take advantage of execution defects to accept other client's characters for a brief time or for all time. Compromising a framework's capacity to distinguish the customer/client, compromises API security generally speaking.

API3:2019 Excessive Data Exposure

Anticipating nonexclusive executions, engineers will in general uncover all item properties disregarding their singular affectability, depending on customers to play out the information sifting prior to showing it to the client.

API4:2019 Lack of Resources and Rate Limiting

Frequently, APIs don't force any limitations on the size or number of assets that can be mentioned by the customer/client. Not exclusively would this be able to affect the API worker execution, prompting Denial of Service (DoS), yet additionally leaves the entryway open to verification imperfections like animal power.

API5:2019 Broken Function Level Authorization

Complex access control strategies with various chains of command, gatherings, and jobs, and a hazy detachment among authoritative and ordinary capacities, will in general prompt approval blemishes. By taking advantage of these issues, assailants access other clients' assets as well as regulatory capacities.

API6:2019 Mass Assignment

RESTricting customer gave information (e.g., JSON) to information models, without legitimate properties sifting dependent on an allowlist, for the most part prompts Mass Assignment. Either speculating objects properties, investigating different API endpoints, perusing the documentation, or giving extra article properties in demand payloads, permits assailants to change object properties they shouldn't.

API7:2019 Security Misconfiguration

Security misconfiguration is ordinarily an aftereffect of unstable default designs, fragmented or impromptu arrangements, open distributed storage, misconfigured HTTP headers, pointless HTTP techniques, lenient Cross-Origin asset sharing (CORS), and verbose mistake messages containing delicate data.

API8:2019 Injection

Infusion blemishes, like SQL, NoSQL, Command Injection, and so forth, happen when untrusted information is shipped off a translator as a component of an order or question. The assailant's noxious information can fool the translator into executing accidental orders or getting to information without appropriate approval.

API9:2019 Improper Assets Management

APIs will in general uncover a larger number of endpoints than customary web applications, making appropriate and refreshed documentation exceptionally significant. Appropriate has and conveyed API forms stock additionally assume a significant part to relieve issues, for example, censured API forms and uncovered investigate endpoints.

API10:2019 Insufficient Logging and Monitoring

Lacking logging and checking, combined with absent or inadequate incorporation with occurrence reaction, permits aggressors to additional assault frameworks, keep up with steadiness, turn to more frameworks to alter, remove, or annihilate information. Most break studies exhibit an opportunity to distinguish a break is more than 200 days, normally identified by outside parties instead of inward cycles or observing.

API Security Standards - TOP 12 Best Practices

API security is a non-negotiable aspect for data-centric projects and API development. Based upon the types of API implementation and various stages, the below-mentioned API security best practices are widely used to keep diverse security risks at bay.

1. Use of Encryption

Encrypted APIs are hard to get attacked. APIs, used for internal and external communications, should be ciphered using the TLS encryption protocol. If possible, try to use encryption at both ends. Most TLS versions should be deployed. 

2. API Authentication

API authentication is the easiest way to ensure that APIs are not exposed to strangers. Keep track of the resources that are calling the APIs, via API key or basic access authentication. This practice will increase the difficulty of the system and make it more secure. 

3. Make Most Of OAuth&OpenID Connect

OAuth is a mechanism designed to prevent the need of remembering copious passwords. OAuth&OpenID Connect allows APIs to take the full responsibility of authorization and/or authentication.

Rather than generating different website-based accounts, OAuth allows you to connect via different credentials like Facebook or Google. In the case of APIs, it has the same sort of modus-operandi. API providers need to bank upon other third-party servers for API authorizations as API consumers, instead of offering their credentials, hand over the third-party granted token,  

In this process of authorization, both the API consumers and API providers are not directly bearing the API authorization responsibility. Being a widely used delegation protocol, OAuth allows API providers to secret APIs a little further by adding the identity layer. That additional identity layer is known as the Open ID Connect standard that extends OAuth 2.0 with ID tokens.

4. Security Experts  

With multiple API security practices, it’s natural to get confused and pick one. Hiring seasoned security experts that can guide you on using suitable Antivirus systems or ICAP servers will help you big time to enjoy robust API security. 

5. Continual Monitoring, Auditing, and Logging 

Prevention is better than cure. On the same note, it’s wise to keep track of the API interaction and spot the errors in the infancy stage. Audit and log relevant information on the server. These logs and records will be used later at the time of debugging. To keep track of API consumption, monitoring the dashboard is vital. When you’re updating the versions, don’t forget to add them to all the APIs.

6. Share Limited Information 

The less information you share via APIs, the fewer would be API security risks. Try to display the least possible information in the error messages.  

The content and email subjects of pre-defined messages that are not customized should be locked up as IP addresses can give away the location details.

Using IP Whitelist and IP Blacklist is a great way to keep the resource access limited. API resource access should be granted only to authorized professionals and all the crucial information, saved on interfaces, should be kept hidden. 

7. Throttling and Quotas For Protection 

To make sure the backend system bandwidth is as per the server’s capability, throttle yourself and grant access to only a limited number of messages. Throttling and quotas are useful to keep the dangers like DDOS at bay.  

8. Valid Data 

Everything that the server is going to accept should be checked twice and validated. Any added content, data that is huge, and information shared by the consumer should be verified. JSON and XML validation are the two most widely used tools to find out whether or not the parameters are safe. They also keep SQL injection or XML bomb incidents under control. 

9. Robust Infrastructure

Implementation of updated security networks and latest server and load balance software always keep API security tight and makes APIs strong enough to deal with data breaches. 

10. Pay Attention To OWASP Top 10

In this list, the worst API vulnerabilities and their impacts are explained in detail. Experts suggest referring to this list and getting educated on the dangers that your API might encounter in the future. Alongside, securing all the OWASP vulnerabilities is also crucial

11. Use API Firewalls

Just as building a wall around our home keeps unwanted access controlled, building API firewalls ensures APIs have only allowed access. While you’re firewalling the APIs, make sure two layers are added. 

The first layer should be used to perform basic security checks like paying attention to the message size, the presence of SQL injections, and blocking the intruders instantly. 

The second layer should be in LAN loaded with high-end security mechanisms. 

12. API Gateway Deployment  

APIs that are well managed are less prone to dangers. For effortless API management, we suggest using API Gateways as they allow you to control, monitor, and secure the API traffic from beginning to end.

How to Pen testing API?

Watch our webinar "API Threats Simulation With Open-Source Tools"

Read the guide - "How To Hack API"

Update 2022: We published online service - API Security testing platform - GoTestAPI

‍

How to secure / protection API and cloud-native apps

Use Wallarm - a dependable and complete API security tool - designed to safeguard websites, microservices, and APIs from all sorts of dangers including OWASP API Top 10, bots, and application abuse easily. 

The great part is Wallarm’s zero manual rule configuration and ultra-low false positives with Wallarm. Only reliable and real-time API security analysis and viable solutions will be offered. There is a free trial and demo offered for the convenience of the users.  The tool is capable of protecting APIs of all sorts such as REST, SOAP. 

Our seasoned API security team is skilled enough to secure APIs in any sort of environment. We have mastered the art and science of API security in AWS, GCP, Azure and IBM Cloud ecosystem, regardless of the type of deployment.