API Security is the set of practices and controls that protect application programming interfaces (APIs — the way programs „talk” to each other over a network) against unauthorized access, business logic abuse, data exposure, and attacks. It covers checking who is making a call and whether they are allowed to (authentication and authorization), encrypting data in transit, validating input, limiting traffic, keeping an inventory of every endpoint, and monitoring for unusual behavior at the application layer (usually HTTP/HTTPS traffic).

APIs are now the main attack surface of modern applications. Mobile apps, modern web front-ends (SPAs), IoT devices, microservices, and business-to-business integrations all communicate through APIs that expose application logic and sensitive data (including personal data, or PII). Unlike traditional website protection, API security has to handle threats specific to „machine-to-machine” communication, where there is no person clicking in a browser on the other side.

Why are APIs a frequent attack target?

APIs expose server-side operations and data directly — often without an app screen that would limit the available actions. An attacker can see what requests and responses look like, change them, and repeat them thousands of times automatically. The main reasons for the risk:

Visible logic and data – endpoints return objects with identifiers and fields that are easy to guess one by one or to manipulate.
No UI as a barrier – hiding a button in the app protects nothing; only server-side control matters.
Shadow and zombie APIs – undocumented or forgotten, unpatched endpoint versions are still running and nobody watches them.
Easy automation – API calls are simple to script, which opens the door to credential stuffing (mass logins with stolen passwords), large-scale data scraping, and business logic abuse.
Complex integrations – traffic between microservices inside the system (east-west) is often less controlled than traffic from the internet (north-south).

What are the main API threats? (OWASP API Security Top 10)

The industry reference is the OWASP API Security Top 10 (2023 edition) — a list of the most common weaknesses specific to APIs:

API1: Broken Object Level Authorization (BOLA) – the server doesn’t check whether the requester is allowed to access a given object. Just changing an identifier in the request (e.g., /orders/123 to /orders/124) reveals another user’s data. The most common and most severe weakness.
API2: Broken Authentication – weak or poorly implemented login: susceptible to credential stuffing, password guessing (brute force), or accepting expired or improperly validated tokens.
API3: Broken Object Property Level Authorization – the response returns too many fields (excessive data exposure) or lets a client write fields it should not be able to change (mass assignment).
API4: Unrestricted Resource Consumption – missing limits (on the number of requests, their size, pagination) that lead to a service overload (DoS) or unexpected costs.
API5: Broken Function Level Authorization – a regular user can call administrative functions because the permission check at the operation level is missing.
API6: Unrestricted Access to Sensitive Business Flows – abuse of key processes (e.g., purchase, sign-up) through automation that nobody restricts.
API7: Server Side Request Forgery (SSRF) – forcing the server to send a request to internal resources itself, based on an unvalidated URL supplied by the attacker.
API8: Security Misconfiguration – wrong settings: bad headers, overly open CORS, default settings, missing TLS encryption, overly detailed error messages.
API9: Improper Inventory Management – no current list of endpoints and versions (hence shadow/zombie APIs and exposed development versions).
API10: Unsafe Consumption of APIs – trusting responses from third-party APIs too readily, without validating and sanitizing them.

Beyond the OWASP list, classic attacks are still dangerous when input reaches an engine that executes commands: SQL injection, NoSQL injection, command injection, and JWT token manipulation (e.g., forcing the none algorithm or a weak secret).

How does security differ across REST, GraphQL, and SOAP?

The type of API shapes where the risk hides and how to defend against it:

REST – operations on resources via HTTP methods (GET, POST, PUT, DELETE). The main risks are BOLA/IDOR (swapping an identifier in the path) and returning too many fields in JSON responses.
GraphQL – a single endpoint and very flexible queries. Here you watch out for expensive, deeply nested queries (which can overload the server), for introspection that reveals the whole data structure, and for permission checks that have to be done separately for each field.
SOAP – messages in XML format with WS-Security; typical weaknesses are XML parser attacks (XXE), oversized payloads, and flaws in handling signatures and encryption.

How are APIs secured? (mechanisms and controls)

Effective protection combines controls at three levels: in the application design itself, at the API gateway, and in monitoring:

Authentication (who is asking) – OAuth 2.0/OpenID Connect tokens, JWT with correct checking of the signature and expiry, API keys for system-to-system integrations, and mTLS where both sides must verify each other.
Authorization (whether it’s allowed) – checked server-side for every object (protects against BOLA) and every function (protects against broken function level authorization); least privilege.
Encrypting data in transit – TLS (HTTPS) for all traffic, including internal traffic between services.
Input and output validation – checking requests against a pattern (e.g., OpenAPI/JSON Schema), filtering returned fields, protection against mass assignment.
Resource limiting – limits on the number of requests (rate limiting), slowing down excessive traffic (throttling), request size limits, pagination, and quotas.
API gateway and WAAP – an API gateway brings authentication, routing, and limits together in one place; WAAP/WAF adds application-layer filtering, but on its own it won’t detect business logic abuse.
Inventory and discovery – continuously finding endpoints and versions and removing shadow/zombie APIs.
Security testing – analysis of the code and the running application (SAST/DAST), API fuzzing, penetration tests, and reviews wired into the deployment pipeline (CI/CD), i.e., a shift-left / DevSecOps approach.

Why does API security matter for monitoring and detection?

Many API attacks are not single break-ins but business logic abuse that looks like normal traffic — gateways and WAFs let such requests through because they are formally valid. Detecting them therefore requires telemetry and behavioral analysis at the application layer:

Full call telemetry – logs and data about requests and responses (endpoint, method, status code, identity, volume, timing) as the basis for detection.
Enumeration detection – reaching for many object identifiers one after another is a typical sign of BOLA/IDOR; bursts of 401/403 responses signal attempts to bypass authorization.
Volume and rate anomalies – sudden spikes in calls to a single endpoint, mass data scraping, credential stuffing (many logins with different credentials).
Correlation with network traffic – in a microservice architecture, watching internal east-west traffic (flow telemetry, NetFlow/IPFIX, service mesh logs) helps spot an attacker’s lateral movement and unusual service-to-service connections.
Shadow API discovery – passively observing traffic reveals endpoints that are not in the documentation and that slip past existing controls.

For SOC teams and NDR / network monitoring solutions, APIs are a layer where the attack signal is most often a behavioral pattern (who reaches which objects, and how often) rather than a single malicious request.

Learn more

REST API — REST APIs are common API Security targets because they expose data and actions over HTTP.
OWASP Top 10 — OWASP Top 10 includes common web risks that often affect API Security controls.
Cloud Access Security Broker (CASB) — CASBs help enforce policy and visibility for cloud app and API Security.
Application Layer Attack (L7) — API Security protects against L7 attacks that abuse request content and logic.
Asset Discovery — Asset discovery identifies APIs that must be inventoried and secured.

API Security

Practices and controls protecting APIs against unauthorized access, business logic abuse, and data exposure: authentication, authorization, encryption, and monitoring.