Mastering the essentials of API security with examples for OWASP Top 10 for APIs
When you hear about API (Application Programming Interface), do you get anxious because you don’t understand it very well? Do you feel like you can’t keep up with new technology? If you do, you’re not alone!
Take a deep breath. Take another. Excellent! I’ll help you overcome your API security FOMO.
In this guide, you’ll learn:
how APIs work
how to exploit the most common API vulnerabilities
real-life examples of data breaches caused by API security issues
API security best practices, and much more!
How do APIs work, and why do you actually need them?
APIs are intermediaries that make communication between applications and users smoother.
Take a look at the diagram below because I’m about to explain it as simply as possible:
Now let’s get into it and break down every step.
1. Request initiation
The process starts with a client application or component attempting to perform a specific task or access specific data from a server or service.
2. API request
The client sends an API request, which is usually in the form of an HTTP or HTTPS request. This request contains specific parameters, headers, or a request body that includes the desired operation or data.
3. Server processing
The server processes the API request according to its predefined specifications. This could include things like querying databases, performing calculations, or interacting with other services.
4. Response generation
Following the processing phase, the server produces a response. This response includes the requested data or the outcome of the server's operation. It is often structured in a standardized format, such as JSON or XML.
5. Delivery
The server sends the response to the client over the Internet. The client application subsequently processes the received data or results to achieve its intended goal.
Common APIs you’ll find in pentest engagements
1. REST APIs
REST APIs use HTTP requests as their primary method of communication to carry out common database operations like creating, reading, updating, and deleting records (also known as CRUD) within a resource.
The flexibility to return messages in different formats, such as HTML, XML, plain text, and JSON, is a feature of RESTful APIs, also referred to as RESTful web services.
Despite its name, JSON (JavaScript Object Notation) is compatible with all programming languages, it's machine, human-readable, and lightweight. These factors make JSON stand out as a preferred message format. This makes REST API security more flexible and easier to set up.
2. SOAP APIs
Unlike the REST API, SOAP (Simple Object Access Protocol) is a protocol that the World Wide Web Consortium maintains. SOAP is a standard protocol designed to enable communication between applications built in different languages and on different platforms.
Any OSI model layer (SMTP, HTTP, TCP) can handle SOAP. When processing requests, it is mandatory to be in XML.
Let’s take a simple real-life example to understand why we need APIs and why we have to keep them secure.
Because I’m a huge fan of electronic music, we’ll take a look at the untold.com website. Try it now with me to understand better. You’ll see there is a music player playing songs 24/7 in the lower right corner of your screen.
Nothing is interesting about it to a regular user, but, for a curious penetration tester, this may be a clue to look further.
From old software that can lead to Remote Code Execution or to an API misconfiguration that allows the attacker to make PUT requests and stop the music player, there’s a lot a malicious actor can do in this “playground”.
APIs are great for penetration testers because you can’t just fire up a scanner. Experienced pentesters with an adversarial mindset and curiosity will always love to hack APIs. To do it, you need confidence in your skills and experience with business logic vulnerabilities.
Many popular vulnerabilities exist within APIs, including injections, XSS, and many more. Let’s delve into an easy one to demonstrate the impact of a simple API vulnerability.
Taking the first step on the web application, we encounter a shopping page with no hints or anything related to APIs.
Using the BurpSuite target section and selecting only the domain in scope, I found a get request to an API endpoint. You can also find it through fuzzing, but we took the BurpSuite way.
Pro tip: Always take recon seriously because gems won’t appear from nothing.
Aaand, we’re done! Cool little challenge to learn more about API vulnerabilities and put into practice what you learn from this article. Remember that the learning process is more valuable when you combine theory with practice.
Did you like this challenge? We encourage you to exploit more web API-based machines from Portswigger. Also, don’t forget to check our new, free to use REST API vulnerable machine on Pentest-Ground.com.
Ok, but what tools does a web application pentester use when hacking into APIs?
The answer may (or not) surprise you: BurpSuite, the API Scanner from Pentest-Tools.com, and a lot of Javascript manual code review. Yup, that’s pretty much it. You can achieve great things with this toolkit!
For instance, let’s take this article where Mohammed Waleed explains how he found two API vulnerabilities simply by reading Javascript code. While looking into the source code, an API endpoint caught his attention.
It looked like this:
export function updateCTA(videoId: string, ctaURL: string, ctaText: string) {
return getResults(
appendQuery(`${TARGET_API_URL}videos/${video_id}/cta`, {
api_key: WEB_API_KEY,
link: ctaURL,
text: ctaText,
}),
{
method: ctaText ? 'put' : 'delete',
}
)
}Now, for someone who doesn’t understand Javascript very well, this doesn’t make any sense. Only a trained eye can find some bugs, but folks who know their way around immediately see there are no authorization headers.
Mohammed investigated and discovered the web API key is the same for all users – and you know what that means, MORE INVESTIGATION!
The result? He played so well with the requests that he deleted any user video without any user interaction.
So, you see, with just BurpSuite and code review, he managed to do that and get a valid bug from Hackerone for Improper Access Control.
3 data breaches linked to API security issues
Don’t believe me? Take a look at these real incidents, one of which manipulated a simple API misconfiguration into a history-changing event.
Uber data breach (2016)
Uber suffered a major data breach in 2016, exposing the personal information of approximately 57 million users worldwide. Uber did not initially disclose the breach, which was only made public a year later, in 2017.
The vulnerability was discovered after attackers gained unauthorized access to Uber's private GitHub repository through stolen credentials. This information disclosure led to a good subject for months in the cybersecurity community.
Because of this security flaw, attackers could breach Uber's servers and extract a large amount of sensitive user data, including names, email addresses, and phone numbers.
The attackers also managed to acquire driver's license information for around 600,000 Uber drivers. Shockingly, Uber paid the hackers $100,000 in hush money through its bug bounty program, disguising it as a legitimate reward, to keep the breach quiet.
Twitter API breach (2022)
A Twitter API vulnerability exposed sensitive information of people from the EU and the U.S. The exploit enabled hackers to submit email addresses or phone numbers to the API to identify which account they were linked to.
As Wired states, “about 5.4 million Twitter users' email addresses and phone numbers” were leaked. This was a huge hit for Twitter (now X) and its users. Data breaches like these always damage the reputation of big companies and make them less credible. They can also lead to government investigations.
Security teams are often called on holidays to remediate problems because cybercriminals always have a strategy. What’s a better time to exploit vulnerabilities if not the holidays, when security teams are not at work?
T-Mobile data breach (2021)
T-Mobile experienced a data breach that exposed sensitive customer data. Malicious hackers accessed the company’s API without authorization to gain access to customer information such as names, phone numbers, and social security numbers.
The “funny” part about the T-Mobile Data Breach is that they didn’t learn from their mistake and damaged their reputation again with another data leak. Even if it’s their eighth breach since 2018, it seems that T-Mobile is still a great target for cybercriminals.
How to find and exploit the OWASP Top 10 most common API vulnerabilities
API vulnerabilities got so “popular” that, in 2019, the OWASP Top 10 for APIs appeared.
Learning about API security best practices is key to understanding them. So let’s dive deeper to gain insight into these vulnerabilities - how they work, why they matter, and how to find them.
API 10:2023 - Unsafe consumption of APIs
The term "unsafe consumption of APIs" refers to flaws in interactions with APIs, which can lead to unauthorized access, data breaches, and other security incidents. This problem emphasizes how crucial it is to integrate and use APIs safely within systems and applications.
An attacker can prepare a git repository named '; drop db;--.
Now, if a compromised application integrates with a malicious repository, the attacker injects an SQL payload into the application that builds an SQL query. This happens because the application assumes the repository’s name is safe input.
API 09:2023 - Improper inventory management
This refers to non-production APIs (staging, test, beta) that are not protected as well as the production API. It’s common for malicious actors to target those kinds of API endpoints instead of the production API.
Let’s explore a real-life scenario.
A financial service provider implements a strong authentication and authorization mechanism for its main API (api.financeprovider.com). However, during a security assessment, a researcher discovers a subdomain (beta.api.financeprovider.com) that hosts a beta version of the API. Surprisingly, the beta API lacks proper authentication checks, allowing unauthorized access to sensitive financial data.
In this case, the main API is well-secured with proper authentication and authorization controls. However, the oversight occurs in the API beta version, where these security measures are not properly implemented.
If an attacker discovers and targets the beta API, they can exploit this weakness to gain unauthorized access to financial information and perform restricted actions. This emphasizes the importance of consistently applying robust security practices across all API instances and environments.
API 08:2023 - Security misconfiguration
Incorrectly configured security settings expose systems to intrusion or attack by unauthorized parties. For instance, if you don't control access to sensitive files, malicious actors could access them.
Let’s take a healthcare platform that introduces a feature for patients to securely communicate with their doctors through a messaging system. The platform issues API requests like:
GET /messages/doctor_updates?conversation_id=9876543
However, because of an oversight, the API responses lack the Cache-Control HTTP header. This absence of caching directives leads to the messages being stored in the browser cache inadvertently.
As a consequence, you can access the same device to exploit this vulnerability by extracting sensitive health information from the browser cache files. This leads to compromised privacy and data protection violations.
API 07:2023 - Server-Side Request Forgery
When an API retrieves a remote resource without checking the user-provided URL, Server-Side Request Forgery (SSRF) occurs. Even with firewall or VPN protection in place, attackers can still exploit this vulnerability to manipulate the application into sending requests to an unexpected location. Therefore, expanding the attack surface increases the overall security risks.
Three specific use cases where you can encounter this API security flaw:
An API takes a URL as a parameter for redirection, enabling attackers to redirect responses to a malicious site and steal sensitive API data.
Attackers compel an API to load resources from a server they control, laying the foundation for a key injection attack in JWTs.
An API allows access to the local host, giving attackers the ability to exploit malformed requests for accessing local resources.
API 06:2023 - Unrestricted access to sensitive business flows
In this context, critical processes or data are accessible without proper controls.
For example, allowing anyone to use automated methods can lead to harmful actions, such as modifying financial transactions without authorization or scraping data for competitive advantage.
This vulnerability is my favorite! It’s easy to exploit and can have a really big impact. It’s not like you can achieve RCE or that it’s very technical. It’s common to find this vulnerability in payment systems, restaurant reservations, online shopping carts, and such.
I love watching movies at the cinema with my friends while eating nachos with a big cup of juice. I purchase most of the tickets from the cinema website, so I don’t waste time in the queue.
Now let’s take a look at this approach: until now, CinemaJHG had to manually approve the tickets bought online. So they launched an API for clients to buy the tickets more easily and quickly. What a lovely company, caring about their clients!
Bob is very happy with this update because he’s been thinking about going to the cinema with his girlfriend on February 14th to celebrate. But there is only one problem. John Doe found a critical vulnerability in the API that allowed him to book as many seats as possible while paying for only one seat. With only one paid ticket, he reserved seats so couples couldn’t sit next to each other.
Sounds fun, right? It's too bad this actually happened in real life. In 2014, a group of single people in Shanghai bought every odd-numbered seat in a movie theatre on Valentine’s Day so that couples couldn’t sit together.
API 05:2023 - Broken Function Level Authorization
This refers to security flaws that allow users to access functions or endpoints beyond their intended level of privilege because of insufficient checks or controls. Attackers may exploit this vulnerability to carry out unauthorized actions, compromising the security of the system.
Here’s how:
An API contains an endpoint that should be exposed only to administrators
GET /api/admin/v3/users/all
This endpoint returns details of all application users and fails to implement function-level authorization checks. An attacker who learned the API structure takes an educated guess and manages to access this endpoint, which exposes sensitive details of the users of the application.
API 04:2023 - Unrestricted resources consumption
Here, the API doesn’t have any sort of protection for how many requests you can perform or the maximum length. This is also known as no rate-limiting and can really damage an organization. This attack can lead to DoS (Denial of Service) and financial losses.
Imagine that, for every customer that signs up, a company has to pay 0.2$ to all the cloud operators for using their service. “Ok, that’s not too much”, you may think (and it’s pretty fair too), but what if a malicious actor made a simple Python script that registered 10,000 users per minute? This vulnerability, combined with no checks applied to the email registration form, is a perfect attack scenario that could make a company lose tons of money in just an hour.
API 03:2023 - Broken Object Property Level Authorisation
For this particular API vulnerability, improper checks or misconfigurations allow users to access or modify specific properties of objects beyond their intended level of privilege.
Attackers may take advantage of this flaw to gain unauthorized access to sensitive data or manipulate object properties.
API 02:2023 - Broken authentication
Authentication, the validation of an individual or entity's identity, becomes a vulnerability when mechanisms are insufficiently implemented in your APIs. This lapse enables attackers to temporarily or permanently assume other users' identities.
Attacks targeting authentication endpoints, such as brute-force, credential stuffing, and credential cracking, pose significant risks.
Depending on the business and application logic, this vulnerability may empower attackers to take control of other users' accounts, access sensitive personal data, and perform privileged actions on their behalf.
API 01:2023 - Broken object level authorization
Users can only access authorized thanks to object-level authorization, which is implemented in the code. API endpoints handling object IDs must verify the user’s action capabilities because failures can lead to data compromise.
Broken Object Level Authorization (BOLA) is not sufficiently addressed by comparing session user IDs with weak ID parameters. Only a portion of cases cover this strategy.
BOLA users can legally access exposed API endpoints. By manipulating IDs, breaches happen at the object level. Broken Function Level Authorization, or BFLA, not BOLA, is the term used to describe unauthorized API endpoint access.
Here’s an example:
/api/v2/user/3/mypassword
/api/v2/user/0-100000/mypassword
This is an example of brute-forcing the API endpoint to harvest other users’ passwords. In this scenario, this is possible because no proper token is implemented.
Does API security really matter?
Yes. I believe APIs will rule the world of the web in the upcoming years. That’s because we already use APIs for most services.
Consider online transactions, social media integration, healthcare systems for sharing patient data, IoT, etc. These include sensitive data, yet the API concept is often misunderstood.
Who uses APIs?
Postman conducted a piece of research on this topic and created a helpful statistic specifically to address this question for the community.
Are only developers using this technology or everyone else in the IT industry?
The graphic clearly shows that developers make up the majority of this statistic. But it’s noteworthy that non-developers are also embracing the API landscape, which is encouraging to see.
Remember we talked previously about the REST API? REST remains the top API used over the Internet.
REST API kept its position in 2023, but according to Postman, 86% of respondents said they used REST, down from 89% last year and 92% the year prior. The trend indicated that in the following years, REST will decline while other APIs will gain traction.
Initial access brokers are particularly interested in breaking API security to gain access to sensitive data. As Adrian Furtuna highlighted in his DefCamp 2022 presentation, gaining access to valuable resources is a hot commodity on the dark web.
Understanding these groups' modus operandi as a pentester enhances your adversarial mindset. If you want to dive deeper into this topic, there’s a dedicated guide about initial access to simulate in your penetration tests.
Let’s consider this scenario: Bob and Alice just hacked into an API and got access to the internal computers through it. They managed to do so by bypassing the not-so-hidden developer API console.
They don’t know much about bug bounty programs and want to make quick money with the information they have. What can they do? Exactly, sell the data to ransomware groups. It’s a win-win situation for both groups, except the company that got hacked. 🙁
Let’s continue with the first example with the music player. If you don’t think too much about it, you would say, “Hey, that’s just a music player that plays some songs from the radio” and I understand.
But what if that music player is on the local network along with the main webserver and customer information? How would you feel if your card details and other private information were on sale on some underground, deep-web onion site?
Regular users often overlook this thin layer and we can’t blame them. People working in cybersecurity understand that this layer could serve as the entry point for critical cyberattacks, granting access to sensitive data.
However, the efforts to secure these APIs often fall behind. This gap between adoption and security can leave organizations vulnerable to cyber threats.
API security best practices
Every API application requires protection by applying threat prevention through a complex process of authentication and authorization rules.
And, of course, following the Zero Trust Principle is important. It’s more effective not to trust user input and take all possible precautions to mitigate potential malicious actions.
When implemented correctly, these methods can save a lot of time spent on mitigation.
Use tokens to confirm identities
Create a token to confirm identities and restrict access to data and resources exclusively to those authenticated by tokens.
Use JWT tokens internally only
Security threats in JWT tokens are very popular because many companies don’t understand their usage and expose their clients' data to anyone who understands the simple process of decoding a base64 string.
A common mistake during JWT token implementation is the exposure of sensitive data such as emails, phone numbers, and even passwords.
Rate limiting
Implement rate limiting to prevent abuse and DDoS (Distributed Denial of Service) attacks on your APIs.
I can’t highlight the importance of rate limiting enough, not just on APIs but on everything. Login inputs, transactions, basically everything you can brute force or cause server shutdowns.
Here’s a cool video showing how no rate-limiting impacts services.
Implement a Zero Trust policy (ZTP)
Zero Trust is a security model focused on designing and implementing better security measures within organizations.
Many attacks happen because the developer trusts the user too much. Why don't we implement API protection strategies to ensure user input validation doesn’t occur? For example, a whitelist to restrict inputs.
Zero Trust principles have a basic principle: don’t trust user inputs!
Consider these 3 principles when designing the ZTP:
Verify explicitly
Use the least privilege access
Assume breach
API gateway
Use API gateways to centralize API management, enforce security policies, and provide additional security features. API attacks and security risks can pose significant threats to the integrity and availability of your services. API gateway plays a crucial role in mitigating these risks and ensuring the smooth operation of your APIs.
How understanding API security makes you a better pentester
You can’t be a network engineer without networking knowledge, nor can you be a web app penetration tester without API security know-how. I mean, you can, but you will be behind others who learned technologies as they emerged.
API usage is widely expanded and it’s no wonder that APIs are already taking over all web applications.
If cloud security engineers were hard to find years ago, the same will happen with penetration testers who master this skill. Clients will not exactly look for an API security expert but rather a pentester who has the skill of pentesting APIs in their arsenal.
Grasping this concept is straightforward. The expansion of APIs is essential and you can’t stop it because it streamlines the work of developers and companies. So if you aim to turn this into your competitive advantage, hop on the wave and learn as much as you can to better help your customers.
What does the future of API security look like?
When it comes to the future of API apps, I think it involves anticipating emerging threats and using best practices for stronger application security.
One of the technologies that will shape API security is the Zero Trust security model. This model is bound to become more popular for API security. Implementing it involves no longer defining trust based on network boundaries but on continuous authentication, authorization, and monitoring. APIs must follow Zero Trust principles to ensure secure interactions.
OAuth 2.1 is another technology that organizations will likely use for API security. We already have OAuth 2.0, but the 2.1 version is expected to address its known security flaws. The new specification will improve security and usability, especially for mobile and single-page applications.
As APIs become more deeply embedded into business operations, API security is gaining recognition as a critical component of organizations' overall cybersecurity posture.
As a result, cybersecurity experts will play a key role in guiding organizations to adopt these evolving best practices and protect their business operations’ stability and growth.
