API security: Most common vulnerabilities and how to fix them

The number of APIs in companies is growing at a double-digit rate annually. Mobile apps, partner integrations, microservices, everywhere there are APIs. And that is precisely why they are an attractive target: attackers do not need to bypass the firewall; they only need to find a poorly secured endpoint. According to 2024 data, more than 40% of security incidents in companies were linked to API vulnerabilities.

OWASP (Open Web Application Security Project) has been publishing a special list since 2019. API Security Top 10which differs from the classic OWASP Top 10 for web applications. In this article, we will review the most serious items, explain why they are dangerous, and show how to fix them.

1. Broken Object Level Authorization (BOLA / IDOR)

BOLA has long and deservedly topped the list. This is a situation where the API does not verify whether the logged-in user actually has access to the object they are requesting. An attacker changes the ID in the URL and gains access to someone else's data.

Real-world example: a call GET /api/orders/12345 returns order number 12345. If the server does not verify whether it belongs to the logged-in user, one can simply try numbers sequentially and download other people's orders. This vulnerability has been responsible for data breaches at many e-shops and fintech applications.

How to repair a split system

• Always verify access to the property against the caller's identity on the server side, not the client side.
• Use UUIDs or ULIDs instead of sequential numbers, as they are unpredictable.
• Implement a centralized authorization layer (e.g., OPA: Open Policy Agent).
• Log access to sensitive facilities and monitor anomalies (an unusual number of different IDs from a single token).

2. Excessive Data Exposure and Mass Assignment

Many APIs return significantly more data than the client needs, relying on the client to select the relevant fields themselves. This is a poor approach. An attacker can see all data transmitted over the network and may exploit internal fields (role, account status, password hash) that should never leave the backend.

A related vulnerability is Mass Assignmentthe client sends a JSON with extra fields (for example isAdmin": true) and the server writes it to the database without validation.

How to resolve the issue

• Define an explicit response schema (DTO - Data Transfer Object) and return only the fields listed in it.
• Never serialize the entire database model directly into the response.
• For incoming data, use an allowlist of permitted fields, ignore everything else or reject it with a 400 error.
• Tools such as OpenAPI and Swagger help you keep the schema consistent.

3. Injection via API: SQL, NoSQL, Command Injection

Injection attacks are old, but in the context of APIs they take on new forms. REST APIs accept inputs via URL parameters, query strings, JSON bodies and headers, and each of these inputs is a potential attack vector.

SQL injection via API endpoint GET /api/products?category=shoes' OR '1'='1 may return the entire contents of the database. NoSQL injection in MongoDB is specific: attackers use operators such as $gt, $where or $regex embedded in the request body of the JSON. Command injection It poses a risk wherever the backend executes system commands based on user input.

How to eliminate injection vulnerabilities

• Always use parameterised queries (prepared statements): never string concatenation.
• Validate and sanitise all inputs: type, length, allowed characters.
• For NoSQL databases, disable or restrict dangerous operators in user input.
• Run the backend with minimal permissions (principle of least privilege).
• Implement a WAF (Web Application Firewall) with rules to detect injection attempts.

4. Authentication, OAuth and API key management

Weak authentication is the entry point for a wide range of further attacks. In the area of APIs, we most frequently encounter these problems:

JWT implementation errors

JSON Web Tokens are widespread, but their poor implementation is treacherous. Most common errors: using the algorithm none (server accepts unsigned tokens), weak signing secret, excessively long token expiration or lack of blacklisting for revoked tokens.

• Always explicitly specify permitted algorithms (HS256 or RS256): never blindly trust the token header.
• Set expiration to a maximum of 15-60 minutes for access tokens and store refresh tokens securely.
• Implement token revocation (blacklists or short-lived tokens with a refresh mechanism).

OAuth 2.0 in Practice

OAuth 2.0 is a standard for delegated authorization, but its poor implementation is very common. Critical requirements: always validate redirect_uri exact match (not prefix), use PKCE for public clients, protect the state parameter against CSRF.

API keys

• Never send API keys in URLs (they appear in access logs); always include them in the header. Authorization or X-API-Key.
• Implement key rotation and the ability to revoke access immediately.
• Keys with different permissions (read-only vs. Read-write), principle of least privilege.
• Detect compromised keys in GitHub repositories using tools such as GitHub Secret Scanning or GitLeaks.

5. Rate Limiting and Protection Against Abuse

An API without rate limiting is like a door without a lock. An attacker can perform credential stuffing (testing stolen login credentials), data scraping, password brute-forcing, or cause a DoS by flooding the server.

Rate limiting implemented only at the IP address level is insufficient, sophisticated attackers distribute traffic across a botnet with thousands of IP addresses. Effective protection requires a combination of multiple approaches:

• Per-user rate limitinglimitations based on an authenticated user or API key.
• Per-endpoint rate limiting. Sensitive endpoints (login, password reset, payments) have stricter limits than others.
• Sliding window algorithmfairer than a fixed window, prevents burst attacks at the window edge.
• Exponential backoff: following repeated errors, the waiting time is extended.
• CAPTCHA for public endpoints upon detection of suspicious behaviour.

Do not forget to return the correct HTTP codes: 429 Too Many Requests with a header Retry-AfterIn your response, state the limit, but not in a way that allows an attacker to easily calibrate their attack.

How to properly test API security

Understanding vulnerabilities is half the battle; the other half is finding them before an attacker does. API security testing should be part of the development process (shift-left security), not a one-off activity before deployment.

Tools for testing the API

• OWASP ZAPAn open-source scanner supporting REST API, GraphQL and SOAP. Suitable for automated tests in a CI/CD pipeline.
• Burp Suitea professional tool for manual testing, capturing and modifying requirements.
• Postman + Newman. Writing and automating security tests within an API test suite.
• Nucleitemplate engine for rapid scanning of known vulnerabilities.
• 42Crunch: a specialised tool for auditing OpenAPI specifications.

Testing methodology

1. Start by inventorying all API endpoints. You will be surprised to find forgotten or unmaintained ones.
2. Verify authorisation at each endpoint: log in as User A and attempt to access User B's data.
3. Test boundary values and invalid inputs, check whether the server returns detailed error messages (information disclosure).
4. Check HTTP methods: an endpoint that should support only GET must not accept PUT or DELETE.
5. Check the security headers of the responses: Content-Security-Policy, X-Content-Type-Options, Strict-Transport-Security.

Professional API penetration testing from SecureOn.cz includes full coverage of the OWASP API Security Top 10, manual application logic testing, and a detailed report with prioritised findings and remediation recommendations. Contact us for a non-binding consultation.

Conclusion: API security as a continuous process

API security is not a one-off project; it is a continuous process involving secure design, code review, automated testing in CI/CD, and regular penetration tests. The most dangerous vulnerabilities are those that do not require technical sophistication from an attacker: BOLA and excessive data exposure can be exploited by anyone with a browser and basic HTTP knowledge.

By incorporating the OWASP API Security Top 10 as a checklist into your development process, implementing proper authentication and authorisation, rate limiting and regular testing, you will significantly reduce the likelihood of a successful attack. Investing in API security is always cheaper than dealing with a data breach.