Unraveling Web and API Security by Vulnerabilities Examples

In the ever-evolving world of technology, new buzzwords, and terminologies frequently emerge as marketing ploys designed to catch the attention of potential consumers. As cybersecurity professionals, it's crucial for us to look beyond the hype and understand the core concepts of these terms. In this HackerNoon long read, we will delve deep into the differences and similarities between Web Security and API Security, comparing the OWASP Top Ten 2021 and OWASP API Top Security Ten 2019 to shed light on the rationale behind the split. We will conclude by highlighting how legacy web apps are essentially legacy APIs, emphasizing that securing them is fundamentally the same process.

The Rationale Behind the Split, or IDOR/BOLA Tweens

Despite the overlap, there is still a rationale behind the split between web and API security. The key difference lies in the way web applications and APIs are designed, developed, and consumed.

Web applications typically rely on user interfaces (UI) and serve content directly to end-users. APIs, on the other hand, act as intermediaries between different software applications, allowing them to communicate and share data. APIs are becoming increasingly crucial in modern software development, especially with the rise of microservices and cloud-based architectures.

The unique nature of APIs means that they face specific security challenges that might not be as relevant in traditional web applications. For example, broken object-level authorization (BOLA) is a more significant concern in APIs than in web applications, where insecure direct object references (IDOR) are the more common vulnerability. The distinction between BOLA and IDOR lies in the fact that BOLA specifically targets APIs, while IDOR focuses on web applications. However, these two issues are exactly the same from a technical standpoint.

Classic Web Injections vs API Injection

To better understand the differences between Web Security and API Security, let's take a closer look at two common injection vulnerabilities: SQL Injection for Web Applications and Object Injection for APIs. These examples will demonstrate the unique challenges faced by each and provide valuable insights into their respective security requirements.

SQL Injection is a well-known vulnerability in web applications that occurs when an attacker is able to insert malicious SQL code into a query, which is then executed by the database management system. This can result in unauthorized access to sensitive data, modification of data, or even complete control over the affected database. Here's a simple example of vulnerable code:

codedef get_user_data(user_id):
    query = f"SELECT * FROM users WHERE id = {user_id}"
    result = execute_query(query)
    return result

In this example, the user-supplied user_id is directly embedded into the SQL query, making it vulnerable to SQL injection attacks. An attacker could provide a malicious user_id such as 1 OR 1=1, which would result in the query returning all user records.

On the other hand, Object Injection is a vulnerability specific to APIs that occurs when an attacker is able to manipulate serialized objects or data structures within an API request, leading to unauthorized access, data manipulation, or even remote code execution. Here's a simple example of vulnerable code:

codeconst express = require('express');
const app = express();
const bodyParser = require('body-parser');
app.use(bodyParser.json());

app.post('/api/users', (req, res) => {
    const userData = req.body;
    const newUser = new User(userData);
    newUser.save()
        .then(result => res.status(201).send(result))
        .catch(err => res.status(400).send(err));
});

In this example, the API endpoint accepts a JSON payload representing a new user object. However, it does not properly validate or sanitize the input, allowing an attacker to potentially manipulate the object structure, inject malicious data, or even execute arbitrary code on the server. For instance, an attacker could submit a payload containing a malicious $where operator in a MongoDB application, leading to the execution of arbitrary JavaScript code on the server.

As demonstrated by these examples, both Web Security and API Security share similar concerns in terms of injection vulnerabilities. However, the specific nature of these vulnerabilities and the ways in which they are exploited differ due to the unique characteristics of web applications and APIs. As a result, it is essential for developers and security professionals to understand these differences and tailor their security measures accordingly. By doing so, they can better protect their applications and APIs from a wide range of threats and vulnerabilities, ensuring a more secure and robust software ecosystem.

Web XSS vs XSS for API

Cross-Site Scripting (XSS) is a security issue that shows the differences between Web Security and API Security. XSS happens when a bad actor puts harmful scripts into a web app, which the victim's browser then runs. In web apps, XSS attacks are really dangerous because they can lead to stealing sessions, taking data, or damaging the affected site.

Here's a basic example of unsafe code in a web app:

<!-- unsafe_form.html -->
<form action="/submit_comment" method="post">
    <input type="text" name="comment" />
    <input type="submit" value="Submit" />
</form>

<!-- unsafe_comment_display.html -->
<div>
    <%= user_comment %>
</div>

In this case, user input, like a comment, isn't cleaned up before being put into the page's HTML. A bad actor could send a comment with harmful JavaScript code, like <script>alert('XSS')</script>, which would then run on the browser of anyone looking at the comment.

For APIs, XSS attacks usually aren't as big of a deal since APIs don't usually give HTML content right to users. But, XSS issues can still matter for APIs using cookie-based authentication. A bad actor could use an XSS weakness in a web app to steal the user's authentication cookie and wrongly access the API.

Check out this example:

// API endpoint using cookie-based authentication
app.post('/api/comments', (req, res) => {
    const comment = req.body.comment;
    const user_id = req.cookies.user_id;
    
    // Check user_id from the cookie for authentication and authorization
    // ...

    // Save the comment without proper input sanitization
    saveComment(user_id, comment)
        .then(() => res.status(201).send())
        .catch(err => res.status(400).send(err));
});

In this situation, if the web app with the API has an XSS issue, a bad actor could use the XSS weakness to get the user's authentication cookie and make API calls they shouldn't. This shows how important it is to make sure both the web app and API are safe because a problem in one could hurt the security of the other.

So, while XSS issues are more common in web apps, they can still affect API security, especially when using cookie-based authentication. Developers and security pros need to know about these risks and use best practices like checking input, encoding output, and using safe coding methods to reduce the chance of XSS attacks on both web apps and APIs.

One challenge in protecting APIs from XSS attacks is that Web Application Firewalls (WAFs) are often designed to block web XSS only. These firewalls might not be as effective at blocking API XSS, which can lead to security gaps. To address this, developers should consider using API-specific security tools and techniques in addition to traditional web security measures.

Conclusion

As we've seen, both web applications and APIs face unique security challenges, but they also share some common vulnerabilities. Relying solely on Web Application Firewalls (WAFs) for security might not be enough, as they are often designed to protect web apps from XSS attacks but may fall short when it comes to API security.

To better safeguard your web applications and APIs, it's important to consider using an API security solution in addition to traditional web security measures. Not all modern API security tools can easily replace WAFs, but some of them offer a comprehensive approach by combining Web Application and API Protection (WAAP) with their Advanced API Security Solution. This enables you to enjoy robust security coverage for both your web apps and APIs.

By staying informed about the latest security best practices and using the right tools, like Wallarm, you can ensure that your web applications and APIs are well-protected against the ever-evolving landscape of cyber threats.