API Security Threats and API Security Best Practices

In this app-driven world, APIs provide highways to ensure smoother transport of sensitive data. Insecure APIs add to web applications’ top security issues and act as an easy invite for hackers. Just because APIs deal with data at the backend does not mean they are hidden from the plain view and are safe.

This article provides an API security checklist that can be used as a primary benchmark before the release. It also includes examples and recommendations on controlling the REST API security threats that are useful during the security design process.

Before, during or after production, continuous identification and mitigation of API vulnerabilities are essential in this ‘shifting left’ SDLC process. Google research suggests that three out of four organisations continued their digital transformation investments during the pandemic. Digital transformation relies on how best software can be leveraged for effective business transformation. APIs are how software communicates with other software & services.

Shift left Security

As it says on the tin, moving the security initiatives earlier during the development process eases out pains for later. Sharing the highway code analogy, APIs are similar to road intersections. Any incidents at the meeting would impact all connecting roads to that junction. Similarly, any error defects in the API would affect every application that relies on that API. Depending on the REST API use, this could impact internal and external organisations at an enterprise level. You cannot let the internal team perform functional testing, work on the findings and live with the process. Simulating threat actor threats, tactics & techniques (TTP) is vital to determine how an API would behave in a particular situation. REST API penetration testing with external third-party security assessments adept at tailoring test cases in the context of the underlying endpoints utilising REST APIs, SOAP (Simple Object Access Protocol) and other web protocols. This exercise identifies API vulnerabilities affecting the underlying endpoints and applications, helping to analyse and minimise the risk. Check out our web application and API penetration testing services and how we put service quality at the centre of our delivery approach. Based on Postman’s famous state of API 2021 report, 56% of respondents cited Security as a development priority.

Old habits die hard.

A REST API uses a representational state transfer (REST) architecture. This style uses stateless HTTP to request access and process data for integration with RESTful web services. Gartner says that, exploitation of API (Application Programming Interface) will be the most common attack vector for data breaches. A good developer keeps a threat profile in mind even if their organisation has no defined security processes. Unfortunately, with most developers coming from web design backgrounds and lacking certain coding practices and skills, development disregards common API security risks and threats different from traditional web applications. There are other goals and approaches to secure web and API designs. API attack prevention measures, in many cases, are different from web application prevention strategies. A few examples of API security vulnerabilities that led to high-risk incidents are listed below:

• Broken Object-Level Authorization (BOLA/IDOR) Vulnerability in Facebook’s GraphQL API
• Shopify security incident notice
• Authentication bypass – Google Cloud service account

Right-sizing API security strategy

API security is not about fixing issues during functional and technical API security testing but about thinking through the secure SDLC lifecycle. An organisation must have base pillars supporting software security across the estate. These include fast coding guidance and policies to ensure standards are followed across applications, networks, data planes and metrics to track progress over time. It acts as a catalyst to secure a culture for secure software development. REST API attack prevention strategy is all about understanding the complexity, business logic, and process of REST API development and then using a reverse mentality to include the prevention measures. Read OWASP’s Top 10 web application vulnerabilities to understand the commonalities between web applications and REST API vulnerabilities. A starting point for assessing your API security would be simulating what happens in the real world. Learning from real-world examples would prove how valuable API security testing is to development practices.

Critical API security threats with API gateway and API endpoints

The most common attack vectors linked to security attacks are parameter-based man-in-the-middle, or identity-based attacks. An API security checklist, at the minimum, should consist of the  OWASP top 10 vulnerabilities. While scoping security assessments for web applications, API shouldn’t be considered just another add-on but assessed according to methods defined under an endpoint, functionalities and the dynamic nature of requests contributing to data transfers.

Injection Attacks

Similar to web applications, dangerous code submitted with the user input into an insecure application could lead to the desired output for a threat actor. Most notable injection attacks, such as SQL Injection, NoSQL, LDAP injections, Cross-Site Scripting, and XXE (XML Entity ), are caused by a lack of strict input validation where untrusted data is transferred into the API as part of the input query or command. This is subsequently implemented by the interpreter, resulting in processing the malicious input submitted by the attacker. Injection attacks are one of the most dangerous attack vectors. These could lead to unauthorised access expose sensitive data, escalation of privileges, data leakages or other potentially high-risk scenarios. Reliable avoidance of API injection attacks involves strict input validation of client-side data. Define implicit input parameter validation guidelines to ensure strong types are used in API requests containing parameters and strong error-handling practices are used in case of error situations.

Sensitive Data Exposure

Due to the lack of threat modelling the information based on how data flows between the client and REST API endpoint, excessive data exposure issues are a common rest API security vulnerability. Insecure implementations or lack of data filtering implementation leads to unnecessary information exposures that may act as stepping stones for an attacker’s success. One minor fix for data in transit or at rest related attacks would be using a valid and securely configured TLS certificate. You can always check the Security of your website by utilising free SSL server test sites on the internet.

Insufficient Logging and monitoring

Logging and monitoring are essential to protect REST APIs and the underlying data continuously. Due to insufficient logging controls, security teams may miss the relevant events that must be logged to help incident response teams or for audit trail purposes. Additionally, due to the lack of analysis and alerting processes, an organisation may miss an ongoing attack because there was a lot of event logging and recorded data but no one to look for suspicious events and alert the security team. Ensure all necessary log levels are in place for all REST API endpoints. Deploy a monitoring solution to monitor logs for REST APIs and infrastructure continuously.

Man In The Middle (MITM) Attacks

MiTM is a scenario where an attacker is positioned suitably between two parties to intercept or change communications. For instance, a threat actor between a user’s browser and an API issuing session tokens in an HTTP request could easily block the session and use it to obtain the user’s account access from his computer. It may lead to a threat actor inggaining unauthorised access to a user account, including personal details and installing malware or other malicious actions. Such attacks are possible where applications do not use SSL/TLS securely or do not use HTTPS at all. It leads us to another important point: the absence of HTTPS is an open invitation to attackers. Simply put, HTTP is a stateless protocol and does not provide any safety of information exchanged between two parties. HTTPS ensures the encryption of data transmitted between a browser and the server/application defined by the user accounts and the secure configuration of encryption methods supported by the server. An application utilising TLS (Transport Layer Security) – when done correctly – provides the following security benefits:

• Confidentiality – protection of the contents of data in transmission between two web points
• Integrity – protection against tampering with traffic
• Replays – protection against a threat actor replaying requests
• Authentication of hosts with certificates or users with client certificates

Ensure TLS configuration aligns with acceptable security practices to avoid any data transmission security threats.

Lack of resources and rate-limiting (DoS Attacks)

Abuse of size and rate limits often leads to threat actors carrying out Denial of Service (DoS) attacks. This rest of the API security vulnerability is based on the concept that if an API consumes available resources as a request processing loop or causes an erroneous situation, it would render the service unavailable to legitimate users. Threat actors seek opportunities to target APIs such as public APIs where lack of authentication is confused with lack of Security. It is also an issue that could be exploited using multiple attack vectors such as brute force attacks, credential stuffing attacks, user enumeration, or other fuzzing techniques. By implementing rate limits on the total number of items in a request, implementing a size limit would help control API endpoints’ abuse. Mobile applications should also be tested against the top 10 mobile security risks to assess the gaps and identify weaknesses in current controls.

Broken Authentication

Due to the inherent nature of API endpoints, publicly exposed APIs are often an attractive target for attackers. Most authentication vulnerabilities occur due to insecure or missing protection mechanisms that are easy to exploit, leading to sensitive data theft, account takeovers or user impersonations. Implement stricter protection, including but not limited to factors such as credential solid encryption, failed login attempts limit, and authentication token validation. OAuth has been the de facto standard for securing APIs for authentication and authorisation mechanisms. Using encrypted JWT tokens ensures identity and user characteristics are not readily susceptible to attacks for Java. This topic has been detailed in-depth below.

Security Risks with API Authentication Methods

This is one of the most critical security challenges that require greater understanding. Multiple API vulnerabilities, such as misconfigurations, broken access control, injection attacks, and privilege escalations bypassing security controls, are associated with authentication and authorisation mechanisms.

Authn vs authz (Authentication vs authorisation)

Authn is abbreviated from authentication, and authz is an authorisation. Authentication vs authorisation is a popular topic and equally important concept when it comes to verifying the identity of a user and enforcing the specific permissions to gain access to particular information. Authentication and authorisation are both processes that protect information and systems. Authentication verifies a user’s or system’s identity, while authorisation determines what level of access a user or system has to protect resources. These pillars of a robust security system work closely in today’s internet applications, defining who can access and what access is available. Let’s see what authentication and authorisation terms are:

• Authentication – who you are (e.g. you require a username and password to log in). A broken user authentication flaw is a relevant example in the security context.
• Authorisation – what you can do (e.g., authorised to make changes or delete users in an application). Broken object-level authorisation or broken function-level authorisation allowing exploitation of horizontal or privilege escalation is an example.

The following section covers in-depth content around the most used authentication methods and the security vulnerabilities of the web services’ security APIs.

HTTP Authentication Methods

Several HTTP authentication schemes are available, but two of the most common are Basic and Bearer authentication.

Basic Authentication

Basic authentication is a simple scheme that transmits only the user’s login credentials in base64 encoded format. This method is insecure because the credentials are sent plain text over the network, making them vulnerable to interception.

Bearer Authentication

Bearer authentication is a more secure scheme that uses an access token to authenticate the user. The access token is a string generated by the authorisation server and sent to the client application. The client application then sends the access token to the resource server when it makes a request.

API Keys

API keys are another standard authentication method. API keys are unique values that are assigned to each user. The user then sends the API key to the resource server when it makes a request.

OAuth

OAuth is a more complex authentication scheme that is based on the concept of authorisation grants. An authorisation grant is a set of credentials to obtain an access token from the authorisation server. The client application then sends the access token to the resource server when it makes a request.

OpenID Connect

OpenID Connect is an authentication layer on top of OAuth 2.0. It provides a way for applications to authenticate users without storing and managing their passwords.

Security Considerations

When choosing an authentication method, it is essential to consider the security of the process. Basic authentication is not secure and should only be used over HTTPS. Bearer authentication is more secure, but it is still essential to protect the access token. API keys can be stolen, so they should only be used for low-value applications. OAuth is a more secure authentication method but also more complex. OpenID Connect is a good choice for applications that authenticate users across multiple domains.

API security best practices

Here is a list of security best practices when designing applications with API usage.

Authentication

• Use robust authentication methods: Implement OAuth 2.0, JSON Web Tokens (JWTs), or other strong authentication mechanisms.
• Enforce granular access control: Employ role-based access control (RBAC) or attribute-based access control (ABAC) to restrict user access to specific resources.
• Validate and scope requests: Verify user identities and enforce access scopes for every API request.

Authorisation

• Employ OAuth 2.0 or JSON Web Tokens (JWTs) for secure authorisation.
• Implement granular access control mechanisms based on user roles and permissions.
• Validate and enforce access scopes for each API request.
• Utilise attribute-based access control (ABAC) for fine-grained access management.

Input Validation

• Sanitise and validate all user-provided input to prevent injection attacks.
• Employ input validation libraries or frameworks to ensure data integrity.
• Implement schema validation to enforce data structure and format.
• Use context-aware input validation to adapt validation rules based on request context.

Output Sanitisation

• Escape and encode all output data to prevent cross-site scripting (XSS) vulnerabilities.
• Use template-based rendering or templating languages to generate output securely.
• Implement output filtering techniques to remove potentially harmful content.
• Employ content security policies (CSP) to restrict executable content sources.

Error Handling

• Handle errors gracefully and avoid exposing sensitive information in error messages.
• Use consistent error codes and formats to facilitate error handling.
• Log errors thoroughly for incident analysis and debugging purposes.
• Implement rate limiting and throttling to mitigate excessive error occurrences.

Logging and Monitoring

• Enable comprehensive logging of API access and activity.
• Monitor API usage patterns to detect anomalies and potential attacks.
• Implement intrusion detection and prevention systems (IDS/IPS) to identify malicious traffic.
• Utilise security analytics tools to correlate and analyse log data for threat detection.

Here is an excellent consideration to consider before API projects go live. This ensures the organisation feels all security threats, including OWASP API top 10, to reduce the attack surface.

OWASP API Security Top 10 (With examples & fixes)

Continuous API Security Testing is the way to go…

APIs are the go-to choice for the modern app-driven world. It has extended from traditional web applications to all-inclusive IT ecosystems with mobile and IoT (Internet of Things) devices. Potential risks associated with API endpoints and their exposures differ, demanding a dedicated approach toward securing APIs. Skill set, business context and continuous validation are critical for businesses to know their attack surface. A business aims to ensure user data by establishing a reliable API security program to provide continuous protection. If you aren’t sure where to begin, feel free to get in touch and schedule a free consultation. We would be happy to listen to your security concerns and advise accordingly.