Understanding OWASP Top 10 For API Security

I still remember when websites were just... websites? The days when you’d be redirected to a customer support contact person to make a purchase. Those days are long gone. Today, everything you do is online, from something as complex as checking your bank balance to simply ordering coffee, all these happen through APIs. But like they say, with every great innovation comes even greater threats (I know no one says that, but maybe they should!)

As I was going through the OWASP Top 10 for APIs, I noticed they’re not only everywhere, but also very vulnerable.

So in this article, I’ll be talking about API security flaws according to OWASP and how to make them not so vulnerable when integrating them.

What Exactly is an API?

API stands for Application Programming Interface, but that's not helpful, is it?

I think of API as an ATM. I don't walk into the bank vault to grab my cash, instead, I use the ATM interface, enter my PIN, request what I need, and the ATM communicates with the bank's systems to verify my identity and deliver exactly what I’m authorized to receive. The ATM is the API, the secure middleman between me and my money.

APIs ensure the flow of data between the user interface and the backend. When I tap "show balance" in my banking app, an API fetches that number from the bank's servers. When I post on social media, an API carries my brilliant thoughts to the database.

APIs can become dangerous when an application’s backend functionalities are exposed to users using the APIs. Essentially, the APIs shouldn’t grant or deliver these confidential features to the users even if they request for it.

Why Should I Care About API Security?

APIs are different from traditional web applications in that:

1. They provide direct access to sensitive information and data
2. They're designed for machines, not humans: This means they can handle way more requests, way faster. Great for functionality, but catastrophic for security.
3. They're everywhere but invisible: Users don't see APIs. They see nice buttons and interfaces. But behind every button click(request) is most probably always an API call.

API vulnerabilities often expose more data than traditional web vulnerabilities. When a web page has XSS, you might lose a session cookie. When an API has broken authorization, you might lose your entire database.

The OWASP Top 10 for API Security

OWASP released their API Security Top 10, and it's different from the web application list (Check out my article on OWASP Top 10 for Web Apps.) These vulnerabilities are specific to how APIs work and how they're attacked.

1. API1:2023 - Broken Object Level Authorization (BOLA)

This is basically IDOR (Insecure Direct Object Reference) for APIs, and it's first for a reason.

So after authenticating as user Mel, I can access another user's info. Sound familiar? It should, since it's the same concept as IDOR in web apps, but it's even more common in APIs.

Example:

The problem here is authorization, not authentication. I (Mel) am properly authenticated (the API knows who I am), but the authorization is broken (the API doesn't check if I can access user 124's data).

This access control should be enforced at the application logic design phase.

How to prevent it:

• Implement authorization checks for every API endpoint
• Don't rely on client-side ID validation
• Use random, non-guessable object references
• Test with different user contexts

2. API2:2023 - Broken Authentication

If BOLA is about "can this user access this data?", Broken Authentication is about "is this really the user they claim to be?"

I’m talking about:

• Weak authentication controls (or non-existent ones)
• Weak passwords being allowed
• Lack of rate limiting (I shouldn’t be able to try 10,000 passwords against an API without getting locked out?)
• Poor password storage
• Missing multi-factor authentication

Prevention strategy:

• Carefully define your authentication policy
• Implement rate limiting on authentication endpoints
• Use strong password policies
• Add MFA where possible
• Monitor for suspicious authentication patterns

3. API3:2023 - Broken Object Property Level Authorization

This one's interesting because it's actually a combination of two problems:

• Mass Assignment: When validation isn't properly done and users can escalate their privileges. This means that a user can change their role from 'free' to 'premium' or 'user' to 'admin' just by adding a field to their API request.

For example:

• Excessive Data Exposure: When API responses include data that wasn't requested. For example, an API that should return user IDs shouldn't also return home addresses, passwords, or social security numbers.

Prevention:

• Explicitly define which properties can be updated by users
• Return only the minimum required data
• Use response schemas to control output
• Implement field-level authorization

4. API4:2023 - Unrestricted Resource Consumption

APIs are designed for machine-to-machine conversation. They're built to withstand many requests at once. But obviously, the fact that they are designed for machine-to-machine doesn’t mean that’s what always happens. Most often than not, this property of APIs is abused, and without proper controls, attackers can:

• Cause denial of service
• Impact performance (things slowing down)
• Exhaust system resources

Examples of said abuses include:

• Sending 10,000 requests per second
• Requesting huge amounts of data in single calls
• Uploading massive files
• Creating thousands of objects

Prevention:

• Implement traffic controls and rate limiting
• Set maximum sizes for uploads and responses
• Add pagination for large data sets
• Monitor resource usage patterns
• Test the effectiveness of controls regularly

5. API5:2023 - Broken Function Level Authorization

This is about the abuse of API endpoints by using methods users shouldn't have access to. Like replacing passive methods (GET) with active ones (PUT, DELETE).

Example:

Prevention:

• Make the right functions only available to the right users
• Regularly check every user's abilities and permissions
• Implement function-level access control
• Don't assume client-side restrictions are enough
• Test access control for every function

ASIDE:

An API endpoint is a specific URL where an API can be accessed by a client, it's where you send your requests to get or manipulate data. I’ll remember it if I think of it as a specific department in a company: just as I’d go to HR for employee info or Accounting for invoices, I’d hit /api/users to get user data or /api/invoices for invoice information.

Each endpoint typically handles one specific function (like GET /api/users/123 retrieves user 123's info, while DELETE /api/users/123 removes that user), and together, all these endpoints make up the complete API that applications use to talk to each other.

6. API6:2023 - Unrestricted Access to Sensitive Business Flows

This is about the abuse of legitimate business flows through automation.

This means:

• Mass automated ticket purchasing
• High-volume referral bonus farming
• Inventory hoarding through automated purchases
• Review bombing through API automation

These are legitimate functions being used in illegitimate ways. Rate limiting and CAPTCHAs aren't always effective because the attackers might use distributed systems or solve CAPTCHAs programmatically.

Prevention:

• Identify critical business flows that could be abused
• Implement business logic rate limiting (not just technical rate limiting)
• Monitor for abnormal patterns
• Add human verification for sensitive operations
• Test controls regularly

7. API7:2023 - Server Side Request Forgery (SSRF)

API endpoints that accept URLs as input can be exposed to SSRF vulnerabilities. The API requests a URL, but the URL provided contains a command or points to internal resources.

For example:

Instead of fetching an innocent image, your API just triggered an internal admin function.

What attackers can do:

• Access internal services
• Read cloud metadata (containing credentials)
• Scan internal networks
• Bypass firewalls

Prevention:

• Sanitize and validate all user input
• Implement zero-trust networking
• Use allowlists for URL schemes and domains
• Test URL validation effectiveness
• Never trust user-provided URLs

8. API8:2023 - Security Misconfiguration

This covers vulnerabilities from... well, misconfiguring things. It's usually what bots are looking for:

• Missing security patches
• No security hardening
• Missing TLS encryption
• Unnecessary features enabled
• Verbose error messages
• Default configurations

Common misconfigurations:

• CORS allowing all origins (*)
• Debug mode enabled in production
• Stack traces in error responses
• Unnecessary HTTP methods enabled
• Missing security headers

Prevention:

• Implement hardening procedures
• Check configurations regularly
• Test security continuously and automate where possible
• Use configuration management tools
• Have different configs for different environments

9. API9:2023 - Improper Inventory Management

This one got me giggling a bit because it seems so insignificant, yet it's part of the top 10 security concerns when it comes to APIs.

You can't secure what you don't know exists. You need an appropriate, all-round view of your API environment:

• All running API endpoints
• All versions (old and current, especially the version you're using)
• Who's accessing them
• What data do they expose

Attackers are vigilant, checking how you handle API updates. They check for:

• Old API versions are still running
• Undocumented endpoints
• Test APIs in production
• Shadow APIs nobody remembers

Prevention:

• Manage APIs through gateways
• Test thoroughly before going live
• Have rules for updates and retirement
• Audit regularly
• Decommission old versions properly
• Maintain an inventory of all APIs

10. API10:2023 - Unsafe Consumption of APIs

This exposes the risk of using third-party APIs. Your API might be secure, but what about the APIs you consume?

You're not just managing your own APIs anymore, but we’re relying more on external APIs whose security posture you can't fully control or even assess.

That payment processor API you integrated last year?

The social media authentication service?

The analytics platform?

Each one is a potential blind spot in your security inventory.

For example, if your application uses address information and you use a third-party API for address validation. An attacker might:

1. Guess which API you're using
2. Compromise or impersonate that API
3. Use injection attacks through the third-party response
4. Redirect your application to malicious sites

You can’t have a secure house but trust a sketchy locksmith with your keys now, can you?

Prevention:

• Maintain an inventory of all third-party APIs
• Encrypt API communications
• Validate ALL data returned by APIs (even trusted ones)
• Implement timeout and error handling
• Have a plan for when third-party APIs fail

The Bigger Picture: API Security is Different

After going through these vulnerabilities, I've realized API security requires a different mindset than traditional web security:

1. Everything is an endpoint - There's no security through obscurity. Attackers will find your endpoints.
2. Authentication isn't authorization - Just because someone is logged in doesn't mean they should access everything.
3. APIs are chatty - They often reveal more information than intended. Every extra field is a potential vulnerability.
4. Automation is a double-edged sword - APIs are built for automation, but that means attacks can be automated too.
5. Version control is a security control

Looking Forward

As I continue exploring API security, I'm struck by how critical yet overlooked it is. We spend so much time securing our web applications, but APIs often handle more sensitive operations with less security scrutiny.

The OWASP API Security Top 10 isn't just another list to memorize but a wake-up call. APIs are the new battleground for cybersecurity, and we need to treat them with the respect (and security controls) they deserve.

And remember: every API endpoint is a door into your system. Make sure you know where all your doors are, who has the keys, and what's behind them.