What is API security? A comprehensive guide to API security for enterprises

1. What is API security?

API security is the set of measures, processes, and technologies designed to protect application programming interfaces from unauthorized access, vulnerability exploitation, and data leakage.

API security covers controlling who is permitted to call an API, what data may be transmitted, and what behavior is considered anomalous. Beyond protecting at the network layer, API security must also address application logic, per-object access control, and data integrity at every endpoint.

In a microservices architecture, each service communicates with others through APIs. A vulnerability at a single endpoint can allow an attacker to perform lateral movement across the entire system. In mobile apps, the API is the only bridge between the client and back-end data, making every API endpoint a potential attack surface. In third-party integrations, a single exposed API key can open unrestricted access to sensitive business data.

According to the Salt Security State of API Security Report (Q1 2023), more than 94% of organizations experienced API-related security incidents within a 12-month period. This demonstrates that API security is no longer the concern of a specialized security team alone; it is a strategic priority for the entire enterprise.

2. How does API security differ from web application security?

API security and web application security both fall under application-layer security, but they differ clearly in scope, attack surface, and applicable tools.

Web application security focuses on the user interface (UI) and browser interaction flows, whereas API security protects endpoints that transmit structured data in machine-to-machine communication. The most important distinction is that APIs have no visual interface for manual inspection, making logic vulnerabilities harder to detect and more likely to be overlooked in traditional testing processes.

Despite the different approaches, the two fields complement each other. A comprehensive security posture requires protecting both web applications and APIs simultaneously, particularly in Single Page Application (SPA) architectures where all logic is executed via API calls.

3. The most common API security threats

OWASP API Security Top 10 is the most widely used reference for identifying API security risks. Below are the most prevalent threats that IT managers, security engineers, and developers need to understand.

3.1. Broken Object Level Authorization & Broken Authentication

These two vulnerabilities frequently appear together and can be exploited in combination to achieve full privilege escalation within a system. BOLA occurs when an API fails to verify object ownership, allowing an attacker to access another user's resources simply by changing an ID in the request. Broken Authentication occurs when authentication mechanisms are implemented incorrectly, such as tokens with no expiry, exposed API keys, or missing multi-factor authentication. When combined, an attacker can bypass authentication and arbitrarily access data belonging to any other object without detection.

3.2. Excessive Data Exposure

Many APIs return an object's full data set and leave filtering to the client. This results in sensitive fields such as hashed passwords, internal tokens, or personal information being exposed in responses without any complex vulnerability being exploited. This error is common in APIs developed rapidly without a response-schema review process.

3.3. Injection attacks via API endpoints

Injection attacks via APIs include SQL injection, command injection, and NoSQL injection delivered through request parameters, headers, or JSON/XML payloads. Unlike traditional injection attacks through HTML forms, these attacks target back-end data-processing logic directly and are often harder to detect without strict input validation mechanisms.

3.4. Application-layer DDoS

Application-layer (Layer 7) DDoS attacks target API endpoints directly by sending large volumes of syntactically valid requests at a frequency that exceeds the server's processing capacity. Unlike volumetric DDoS attacks that target bandwidth, this approach exploits the business logic of APIs, such as computationally expensive endpoints, complex database queries, or authentication flows, to exhaust system resources. This vulnerability is common in APIs that lack rate limiting, anomaly detection, or a front-line protection layer.

4. API security solutions and principles

Effective API security does not depend on a single tool but on a combination of multiple protection layers, from architectural design through to day-to-day operations.

4.1. Authentication and authorization

Authentication verifies the identity of the caller; authorization determines what the caller is permitted to do. The two mechanisms must be implemented independently and are not interchangeable. Common standards include OAuth 2.0 for delegation, OpenID Connect for identity verification, and JWT (JSON Web Token) for transmitting authentication claims. For every sensitive endpoint, multi-factor authentication and authorization checks at the business logic layer must be added, not just at the gateway layer.

4.2. Data encryption and access control

All API traffic must be encrypted using TLS 1.2 or higher. In addition to transport-layer encryption, sensitive data fields in payloads must also be encrypted individually before storage. Access control must follow the principle of least privilege, granting each API consumer only the access rights required for their specific scope.

4.3. Rate limiting, throttling, and application-layer DDoS protection

Rate limiting restricts the number of requests a client can send within a given time window, preventing both brute-force attacks and Layer 7 DDoS. Throttling regulates traffic when the system approaches its resource limits. Both mechanisms must be configured individually for each endpoint based on its sensitivity level rather than applying a single threshold across all APIs.

4.4. Input validation and injection prevention

All input parameters from requests must be strictly validated for data type, format, and allowable value range. Beyond client-side validation, server-side validation must occur before processing. For APIs that receive complex data, JSON Schema validation ensures that payloads conform to the expected structure before entering business logic.

4.5. Logging, monitoring, and anomaly detection

Every API call must be fully logged, including timestamp, endpoint, HTTP method, response code, source IP, and user identity. The monitoring system must be capable of real-time anomaly detection, such as sudden spikes in request volume, unusual access patterns, or consecutive 401/403 errors from the same source.

4.6. WAF and API gateway - application-layer protection

A Layer 7 Web Application Firewall (WAF) filters and inspects HTTP/HTTPS traffic before it reaches the application, blocking malicious payloads such as SQL injection and XSS. An API gateway serves as an intermediary, enforcing authentication, rate limiting, routing, and centralized logging across all APIs. These two protection layers are commonly deployed together to form the first line of defense for web application and API security.

5. Legal requirements and API security standards

In addition to technical measures, enterprises deploying APIs must also satisfy mandatory compliance requirements from regulatory authorities and international standards bodies. The applicable level depends on the industry and the type of data the API processes, but the three standards below directly affect how APIs are designed and operated in Vietnam.

5.1. Circular 64/2024/TT-NHNN

Circular 64/2024/TT-NHNN, issued by the State Bank of Vietnam, establishes mandatory technical requirements for the information systems of credit institutions, including APIs that connect with core banking systems, e-wallets, and payment gateways. Requirements that apply directly to APIs include:

• Strong authentication for every API call that processes financial transactions; single-layer authentication is not accepted
• Encryption of all sensitive data in payloads before transmission, not only at the transport layer
• Full audit logging including the caller's identity, timestamp, endpoint, and processing result for all transaction-related APIs
• Periodic review and approval of the list of APIs permitted to connect to core systems

For fintech companies, digital banks, and payment intermediary service providers, Circular 64 is currently the highest-binding legal instrument for API security in Vietnam.

5.2. PCI-DSS

PCI-DSS (Payment Card Industry Data Security Standard) is the payment card data security standard issued by the PCI Security Standards Council. It applies mandatorily to all organizations that store, process, or transmit card data, including through APIs. PCI-DSS version 4.0 adds more specific technical requirements for API environments compared to previous versions:

• Least-privilege access control for every API endpoint that handles card data
• Field-level encryption of card numbers and CVVs in payloads; plaintext is not permitted even temporarily in memory
• Periodic API vulnerability scanning and scanning after every structural change to an endpoint
• Automated monitoring and alerting when anomalous access patterns are detected on APIs that handle payment data

E-commerce companies, e-wallets, and payment gateways that fail to meet PCI-DSS requirements may have their ability to process transactions suspended by international card organizations such as Visa and Mastercard.

5.3. NIST SP 800-204

NIST SP 800-204 (Security Strategies for Microservices-based Application Systems) is a technical document issued by the National Institute of Standards and Technology of the United States. It provides detailed guidance on API security in microservices architectures. Unlike Circular 64 and PCI-DSS, which are legally binding, NIST SP 800-204 is a technical reference framework that many organizations adopt voluntarily to improve their API security posture:

• Implement zero trust for all service-to-service communication via internal APIs; no implicit trust even for traffic originating within the internal network
• Use mutual TLS (mTLS) for bidirectional authentication between services in a microservices architecture
• Centralize API security policy management through an API gateway rather than distributed configuration at each service
• Apply a service mesh to monitor and control internal API traffic in real time

NIST SP 800-204 is best suited for developer and DevOps teams building or upgrading microservices architectures, especially in organizations with international compliance requirements or those working with overseas partners.

6. Comprehensive API protection with VNIS

VNIS (VNETWORK Internet Security) is an integrated application security and CDN platform. More than just a WAF, VNIS combines multiple layers of protection on a single platform, enabling enterprises to secure their entire API attack surface without operating multiple separate systems.

For organizations building or operating APIs at scale, VNIS provides:

• A Cloud WAAP with over 2,400 continuously updated rule sets that automatically block injection attacks, broken authentication, and the attack vectors listed in the OWASP API Security Top 10
• Per-endpoint rate limiting and throttling controls that prevent application-layer DDoS attacks and API brute-force attempts
• Real-time API traffic monitoring with an intuitive dashboard and instant anomaly alerts via email and webhook
• Global CDN integration that reduces API latency while increasing capacity, suitable for distributed microservices architectures
• Rapid deployment requiring no changes to existing infrastructure, ideal for enterprises that need to add an API security layer without disrupting running systems

VNIS is well suited for IT teams that do not want to manage separate security infrastructure while still requiring enterprise-grade API protection. The platform also enables developers to integrate custom security rules tailored to each API endpoint's specific characteristics through a centralized management interface.

7. Conclusion

API security is an indispensable foundation in the security strategy of any organization operating digital systems. From understanding the true nature of API security and identifying threats according to the OWASP API Security Top 10, to applying the right protection layer for each context, every step requires close collaboration between IT managers, developers, and the security team.

If your organization is looking for a comprehensive API protection solution that requires no additional infrastructure investment, VNIS delivers a multi-layered security posture ready to deploy immediately, covering Layer 7 WAF, per-endpoint rate limiting, and real-time anomaly monitoring.

Contact the VNETWORK team for expert consultation and a live demo:

• Hotline: 028 7306 8789
• Email: contact@vnetwork.vn

FAQ - Frequently asked questions about API security

1. Do small businesses need to implement API security?

Yes. Small businesses are often easier targets because they have fewer resources to patch vulnerabilities in a timely manner. If your system has APIs connected to a mobile application, online payments, or third-party integrations, API security is mandatory regardless of organizational size.

2. Is an API gateway sufficient to secure an API?

No. An API gateway handles authentication, routing, and rate limiting effectively but is not a comprehensive security solution. It must be combined with a Layer 7 WAF, application-level input validation, and a monitoring system to form a multi-layered defense.

3. How do you test for API security vulnerabilities?

An API security testing process typically includes: manual testing against the OWASP API Security Top 10 checklist, automated fuzz testing to detect errors in handling unexpected inputs, and schema validation testing to ensure the API only accepts the defined data structure. Testing should be performed regularly and especially before each new version release.

4. What is the OWASP API Security Top 10?

The OWASP API Security Top 10 is a list of the ten most common and dangerous API security vulnerabilities published by the Open Web Application Security Project (OWASP). The list is updated periodically based on real-world data from the global security community and serves as the standard reference for security teams, developers, and testers.

5. Is API security related to the ISO 27001 standard?

Yes. ISO 27001 requires organizations to establish access controls, data encryption, and information system monitoring, all of which apply directly to APIs. Properly implementing API security is part of the roadmap for achieving ISO 27001 certification, particularly in relation to the controls in Annex A covering access management and cryptography.