When it comes to API Security, it looks like the main issue is the misinformation spread on social networks and every other place, primarily because of the vendors. The vendors take it to their interests, which causes misconception, misinformation, and missteps in many environments. In general, you can see that many environments suffer from a “mis-something” that leads to exposure and security gaps.

To my great happiness, some general principles and approaches will remain the same for the long way with API Security.

In the last period, I had many discussions and conversations with many vendors about API security and what each one offers, including the differences. From those conversations, I had across some gaps, and some of them are – How much security do developers build into APIs? And What are the differences between FrontEnd and API from a security perspective?

The shift-left support doesn’t mean that security will be baked into every API by your development process and security automation. Many security issues can’t be spotted as part of automated design, development, and build scans with typical security analysis and testing tools – the APIs need to be exerted to spot business logic flaws.

Sometimes, the application architecture uses Front-End and back-end. The architecture is slightly different with API, Front-End, and Back-End.

The “Good Bye Web APIs” article highlights and clarifies a specific situation when developing with two or three components. Because there are dissimilarities between both scenarios, you should look at each security difference.

API in a Nutshell

So what is an API? APIs, also known as Application Programming Interfaces, allow applications to talk to other applications at their most basic level. Still, they are so much more than this when you begin exploring the world of APIs.

APIs are becoming part of every aspect of our personal and business worlds, often even without us knowing. APIs are affecting your life right now, and with a little more understanding, you can learn to identify APIs and put them to work for you. If you explore the web and use a mobile phone, explain what an API is for you.

The API, or the Application Programming Interface, is a set of tools that allow a user (or a programmer) to access an application’s functions without knowing its inner workings. For example, Google Maps provides a Javascript API that lets anyone embed a fully customizable map in their web pages or mobile apps.

Developers don’t need to know how an API is implemented; they use the interface to communicate with other products and services. API use has surged over the past decade to the degree that many of the most popular web applications would not be possible without APIs.

How does an API work? At its core, API is just a means of communication. As you might have heard, computers have their own ‘languages.’ Javascript, Python, etc.

The problem? There is no one standard language. Just like people from different countries might speak different languages, applications made by different people often use different programming languages. This makes it very difficult for computer programs to communicate with one another, as the syntax of one language rarely matches the other.

This is where API comes in. An API of a program provides a language-agnostic interface for communicating with it. Whether the program is coded in machine language or Java, another programmer can use its functions through the API. This makes APIs indispensable for all kinds of software, from web-based services to the applications making up your personal computer.

APIs are for storing and recalling data into databases, creating dynamic web pages, integrating with social media tools, and countless more. Any software feature you can think of has likely already been developed by someone else – and can be used in your apps through a simple API.

API Structure – As we have already discussed, the primary purpose of an API is to facilitate app-to-app communication across different programming languages. But in machines, communication needs to follow a strict format. Here are the primary architecture components:

• Low-Level APIs are the most straightforward APIs typically reserved for function libraries.
• SOAP APIs use XML data format, a stricter subset of HTML that is the standard for web pages.
• REST specifies an overarching structure of representing and passing on data, leaving the exact details of the implementation to every individual application itself.
• Two sides are involved in the functioning of an API: The Client and the Server. The server implements the internal functions of an API, managing the data and providing it upon request. On the other hand, the client refers to the user making API calls and requesting the data.
• RESTful API Methods contain four standard methods: GET, POST, PUT, and DELETE.
• And the Code…

More about API can be found in the “What are APIs and how do APIs work?”

Now that we know what API is, we can continue the vital part of API security.

Why is API Security Important?

API security is important because APIs expose sensitive data and functionality that can be exploited by attackers. Some of the common reasons why API security matters are:

• Data breaches: Attackers can use APIs to access confidential or personal data stored by an application or a service. For example, hackers can use stolen API keys or credentials to access customer data or payment information.
• Business logic abuse: Attackers can use APIs to manipulate or bypass business logic or workflows implemented by an application or a service. For example, hackers can use APIs to perform fraudulent transactions or abuse promotions.
• Denial-of-service (DoS) attacks: Attackers can use APIs to overload or disrupt an application or a service by sending a large number of requests in a short period. For example, hackers can use bots or scripts to send malicious requests to an API endpoint and cause performance degradation or downtime.

What is API Security?

An API allows applications to interact with each other and with other systems and components. It’s an essential part of modern software patterns.

API Security is defending APIs from attackers and minimizing the security issues and the attack surface areas. Because APIs are commonly utilized and enable access to sensitive applications, systems, and data, they become a primary target for attackers.

API Security for attackers is a gateway to heaven because of massive threats, exposures & risks. Since APIs serve as pipes that reveal apps for third-party integration, and backend systems, they are susceptible to attacks. Here is a list of the security risks and threats to take precautions of:

• Misconfiguration
• Bad coding
• Inadequate validation
• API incompetence
• Unsatisfactory security
• Traffic Management
• Governance
• Shared Flows
• Hesitating over API utilization
• Rewriting responses and requests

API security is a critical element of modern Cloud-Native apps. APIs probably have security misconfiguration like broken authentication or destructive authorization process and may have some vulnerabilities, lack of rate-limiting, and code injection. Many environments must regularly meet API security tests and simulations to identify misconfiguration and vulnerabilities to address these vulnerabilities using security best practices.

From the “Equity for Punks”

If we take the cloud as an example with Azure API Management, the significant elements in the cloud are creds such as keys, secrets, certificates, etc.

With API Management, we can’t control the creation of weak client secrets (default). Hence, the best is to validate the use of certificate credentials on the API management side and monitor the creation, anomalous, and malicious activity changes with Azure Sentinel.

When operating with OAuth2 client credentials flow in Azure AD, you’ve got two options for authentication:

👉 The first is using the client’s secret (based string)
👉 The second is using a client certificate (based on JWT with key)

As part of my day-to-day AppSec and cloud security, I’ve frequently seen many security gaps and external exposure to API. For example, API management validates credentials used by unsecured deployment.

Top Threats

API security threats constantly evolve as attackers find new ways to exploit vulnerabilities or abuse functionality exposed by APIs. Some of the common API security threats are:

• Injection attacks: These are attacks where an attacker injects malicious code or commands into an API request that is executed by the backend system. For example, SQL injection attacks where an attacker injects SQL queries into an API parameter executed by the database server.
• Broken authentication and authorization: These are attacks where an attacker exploits weaknesses in how an API authenticates (verifies identity) or authorizes (grants access) users or devices. For example, credential stuffing attacks where an attacker uses stolen usernames and passwords to access protected API resources.
• Lack of rate limiting is when an API does not implement any mechanism to limit the number of requests sent by a user or device in a given period. This allows attackers to perform brute force attacks (trying many combinations of credentials) or DoS attacks against an API.
• Code injection is when an attacker exploits vulnerabilities in how an API handles input data and executes malicious code on the backend system. For example, XML external entity (XXE) attacks where an attacker injects external entities into XML input data that cause file disclosure or remote code execution on the server.

The growth in API-related security threats has prompted the OWASP to release the API Security Top 10, which helps raise awareness of the most severe API security issues affecting organizations. These are the top list:

API1:2019: Broken Object-Level Authorization – APIs often expose endpoints handling object identifiers. Any function that accepts user input and uses it to access a data source can create a Level Access Control issue, widening the attack surface. It would be best to carry out object-level authorization checks for all such functions.

API2:2019: Broken User Authentication – Attackers often use incorrectly applied authentication mechanisms. They may compromise an authentication token or exploit flaws in implementation to pose as another user, on a one-time basis or permanently. If the system’s ability to identify the client/user is compromised, so is the overall API’s security.

API3:2019: Excessive Data Exposure – Developers often rely on the client-side to filter the data before displaying it to the user. This can create serious security issues—data must always be filtered on the server-side, and only the relevant information should be delivered to the client-side.

API4:2019: Lack of Resources and Rate Limiting – APIs often don’t restrict the number or size of resources the client/user can request. This can impact the performance of the API server, resulting in Denial of Service (DoS) and exposing authentication vulnerabilities, enabling brute force attacks.

API5:2019: Broken Function-Level Authorization – Authorization flaws often result from overly complex access control policies or if there is no clear separation between regular and administrative functions. Attackers can exploit these vulnerabilities to access a user’s resources or perform administrative functions.

API6:2019: Mass Assignment – Mass assignment typically results from binding client-provided data (i.e., JSON) to a data model based on an allow list without properly filtering properties. Attackers can modify object properties in several ways—they can explore API endpoints, read the documentation, guess object properties, or provide additional properties through request payloads.

API7:2019: Security Misconfiguration – This often results from inadequate default configurations, ad-hoc or incomplete configurations, misconfigured HTTP headers or inappropriate HTTP methods, and insufficiently restrictive Cross-Origin Resource Sharing (CORS), open cloud storage, or error messages that contain sensitive information.

API8:2019: Injection – Injection flaws (including SQL injection, NoSQL injection, and command injection) involve data sent to an interpreter from an untrusted source via a command or query. Attackers can send malicious data to trick the interpreter into executing dangerous commands or allow the attacker to access data without authorization.

API9:2019: Improper Asset Management – Unlike traditional web applications, APIs typically expose more endpoints and thus require structured, up-to-date documentation. Issues such as exposed debug endpoints and deprecated API versions can increase the attack surface. This can be mitigated by creating an inventory of deployed API versions and properly configuring hosts.

API10:2019: Insufficient Logging and Monitoring – Attackers can use insufficient logging and monitoring and inadequate or lacking incident response to persist in a system, deepen their hold, and extract or destroy more data. It typically takes over 200 days to detect a persistent threat, and an external party usually discovers breaches, highlighting the critical importance of effective API monitoring.

image credit: owasp

REST and SOAP

There are two main architectural styles used in modern APIs:

• SOAP – a highly structured message protocol that supports multiple low-level protocols.
• REST – a more straightforward approach to APIs using HTTP/S as the transport protocol and typically using JSON format for data transfer.

Both APIs support HTTP requests and SSL responses, but the similarity ends there.

REST API security

• REST APIs do not have any built-in security capabilities—security depends on the design of the API itself.
• Security must be built-in for data transmission, deployment, and client interaction.
• REST APIs do not have built-in error handling and need to resend data when an error occurs.
• A typical architectural choice is to deploy REST APIs behind an API gateway. Clients connect to the gateway, which acts as a proxy, not directly to the REST API. This allows many security concerns to be addressed by the API gateway.

• SOAP offers extensions to the protocol that address security matters
• SOAP is based on W3C and OASIS recommendations, including SAML tokens, XML encryption, and XML signatures.
• SOAP supports the WS specifications, which lets you use security extensions like WS-Security, which provides enterprise-grade security for web services
• SOAP supports WS-ReliableMessaging, which provides built-in error handling

In conclusion, SOAP APIs are more secure by design, but REST APIs can be made secure, depending on their implementation and the architecture selected.

GraphQL Security

GraphQL is a query language that describes how clients can request information via an application programming interface (API). Developers can use GraphQL syntax to request specific data and receive it from a single source or multiple sources. Once a client defines the required data structure for a request, a server returns data using that exact structure.

Since clients can craft highly complex queries, the server must be ready to handle them properly. The server should be able to handle abusive queries from malicious clients and large queries from legitimate clients. The client might take the server down if the server does not handle these scenarios properly.

Here are several approaches that can help you mitigate GraphQL security risks:

• Timeout – a timeout can help you defend against large queries. It is the most straightforward strategy because it does not require the server to know any details about incoming queries. The server only needs to know the maximum time allowed per query.
• Maximum query depth – can help you prevent clients from abusing query depth. Maximum query depth analyzes a query document’s abstract syntax tree (AST) to determine what is acceptable. The GraphQL server can then use this depth to accept or reject requests.
• Throttling – the above options can stop large queries, but they cannot stop clients that make many medium-sized queries. For GraphQL, even a few queries could be too much to handle if queries are expensive. You can determine the server time needed to complete each query type and use this estimation to throttle queries.
• Query complexity – query depth is not always enough to understand the scope of a GraphQL query. This usually happens when specific schema fields are more complex to compute than others. Query complexity can help you define the level of complexity of these fields and restrict queries that exceed a complexity threshold.

API Security Testing Methods

You can use the following methods to test your APIs for security vulnerabilities manually.

Parameter Tampering – Parameters sent through API requests can be easily tampered with in most cases. For example, by manipulating parameters, attackers can change the purchase amount and receive products for free or trick an API into providing sensitive data that is not authorized for the user’s account. Parameter tampering is often performed using hidden form fields. You can test for hidden fields using the browser element inspector. If you find a hidden field, experiment with different values, and see how your API reacts.

Command Injection – To test if your API is vulnerable to command injection attacks, try injecting operating system commands into API inputs. Use operating system commands appropriate to the operating system running your API server. For example, if your API displays content via a URL, you can append an operating system command to the end of the URL to see if the command is executed on the server. It is recommended to use a harmless operating system command that you can observe on the server, such as a reboot command.

API Input Fuzzing – Fuzzing means providing random data to the API until you discover a functional or security problem. It would be best to look for indications that the API returned an error, processed inputs incorrectly, or crashed. For example, if your API accepts numerical inputs, you can try vast, harmful, or zero numbers. If it accepts strings, you can try random SQL queries, system commands, or random non-text characters.

Unhandled HTTP Methods – Web applications that communicate using APIs may use various HTTP methods. These HTTP methods are used to store, delete, or retrieve data. You will usually get an error if the server doesn’t support the HTTP method. However, this is not always the case. If the HTTP method is unsupported on the server-side, this creates a security vulnerability. It’s easy to test if HTTP methods are supported on the server-side by making a HEAD request to an API endpoint that requires authentication. Try all the standard HTTP methods—POST, GET, PUT, PATCH, DELETE, etc.

Testing Tools

Securing production APIs requires automated tools, especially with a steady development and release process. The following open-source tools can help you design security-related test cases, run them against API endpoints, and remediate issues you discover. They can also discover business logic vulnerabilities, which can also be an opening for attackers.

Postman – Postman is an API development platform. Its key features include:

• Automating manual API tests
• Integrating tests into the CI/CD pipeline
• Simulating the expected behavior of API endpoints and responses
• Checking API performance and response times
• Enables collaboration between developers with built-in version control

Swagger – Swagger is an open-source toolkit that can help you create RESTful APIs. It enables two API development styles:

• Top-down API design lets you build an API in Swagger and generate code from specifications.
• Bottom-up API design in which Swagger takes existing code and generates documentation about API operations, parameters, and outputs.

JMeter – JMeter is a load-testing tool used for security testing. Key features include:

• Embedding API tests into the build process with Jenkins.
• Advanced performance testing, with the ability to replay test results.
• Inputting CSV files and using them for load testing lets you perform tests with different values to simulate risky scenarios and cyber attacks.

SoapUI – Soap UI is a popular API functional testing tool. Its key features include:

• It lets you reuse existing load tests or security scans for functional tests.
• Fully customizable provides source code so you can build your features.
• An extensive library of functional testing elements that let you automate API tests.
• The pro package lets you perform data-driven testing, simulating how users work with the API using spreadsheets or databases.

Karate – Karate DSL is a Java API testing tool using the behavior-driven development approach. Its key features include:

• Generates standard reports.
• Enables multi-threaded execution.
• Writing BDD for APIs with ready-made step definitions.
• Supports switching configuration between staging and production.
• It does not require Java knowledge to write tests for Java-based APIs.

API Security Best Practices

Use the following best practices to improve the security of your APIs.

Identify Vulnerabilities – The only way to secure an API effectively is to understand which parts of the API lifecycle are insecure. This can be complex, primarily if your organization operates many APIs. It is essential to consider the entire API lifecycle—the API must be treated as a software artifact, which goes through all the stages of a software product, from planning through development, testing, staging, and production.

Leverage OAuth – One of the most critical aspects of API security is access control for authentication and authorization. OAuth is a powerful tool for controlling API access, a token-based authentication framework that allows third-party services to access information without exposing user credentials.

Use a Service Mesh – Like API gateways, service mesh technology applies different management and control layers when routing requests from one service to the next. A service mesh optimizes how these moving parts work together, including correct authentication, access control, and other security measures.

As the use of microservices increases, service meshes are especially important. API management is shifting to the service communication layer, and service meshes can provide automation and security for large deployments with multiple APIs.

Encrypt Data – All data managed by an API, especially personally identifiable information (PII) or sensitive data protected by compliance standards and regulations, must be encrypted. Require signatures to ensure that only authorized users can decrypt and modify data provided by your API. Implement encryption at rest to ensure attackers who compromise your API server cannot use it, and encryption in transit using Transport Layer Security (TLS).

Use Rate Limiting and Throttling – As APIs become more valuable to attackers as they become popular. APIs are now a prime target for denial of service (DoS) attacks. Set rate limits on the method and frequency of API calls to prevent DoS attacks and protect against peak traffic, affecting performance and security. Rate limiting can also balance access and availability by regulating user connections.

Security by Obfuscation ensures that you do not provide valuable information about your application’s inner workings through error messages. This means you need to make error messages and failed responses clear without providing extra information. For example, if an attacker inputs an incorrect password and username combination, your error message should state only that. It should not supply information about which part of the combination was wrong or whether they are a valid user in your database.

Adopt a Zero-trust – Traditionally, networks had a perimeter, and elements inside were trusted, while elements “outside” were not. Networks are no longer that simple, with insider threats prevalent and legitimate users often connecting from outside the network perimeter. This is especially true for public APIs, with users from all over the world accessing internal software components and sensitive data.

A zero-trust strategy shifts the security focus from location to specific users, assets, and resources. It can help you assure that APIs always authenticate users and applications, provide the least privileges they need to perform their roles, and closely monitor for abnormal behavior.

Do you have any API Security Checklists? Follow the most significant security countermeasures when designing, testing, and releasing your API. API Security Checklist.

Stay tuned for more AppSec 101 in the next post.

More DevSecOps posts