Short Summary
- APIs connect mobile apps, web front ends, microservices, partners, SaaS and AI services. They expose business logic and sensitive data directly, making API security a core part of enterprise application security.
- This guide covers the risks enterprises should test, based on the OWASP API Security Top 10 (2023), plus injection, GraphQL and AI/LLM API risks.
For each risk it explains what to test, the attack context (mapped to MITRE ATTACK where relevant) and the telemetry the SOC needs, followed by compliance mapping and a testing checklist.
1. The Problem
APIs are now the main way enterprise applications exchange data. One customer journey may call many REST and GraphQL endpoints, gRPC services between microservices, payment webhooks, partner integrations and APIs that connect applications to LLMs and AI agents. Security testing has not always kept pace:
- APIs expose logic and data directly: attackers can call them with modified parameters, skip client-side controls and automate requests at scale.
- Authorization is decided per object and per function: the most damaging API flaws are logic errors that automated scanners rarely detect, because the requests look valid.
- Incomplete inventory: shadow APIs, old (zombie) versions and test endpoints stay reachable without review, expanding the attack surface.
- Limited visibility: API traffic is encrypted, high volume and machine to machine. Without API aware logging, the SOC cannot tell normal use from scraping or account takeover.
2. Why It Matters
APIs often give direct access to customer records, payments, health data and internal systems. MITRE ATTACK documents Exploit Public Facing Application (T1190), which covers internet facing APIs, as an initial access technique.
| Impact | How API weaknesses cause it |
|---|---|
| Data exposure at scale | One authorization flaw lets an attacker loop through object IDs and extract many records with legitimate looking requests. |
| Account takeover | Weak authentication enables credential stuffing (T1110.004), token theft and session abuse leading to Valid Accounts (T1078). |
| Cloud compromise and ransomware | SSRF can reach cloud metadata services and retrieve credentials (T1552.005), opening a path to lateral movement and, in some cases, ransomware staging. |
| Fraud and availability | Automated abuse of business flows and resource exhaustion affect revenue and uptime without a classic vulnerability. |
| Zero trust | APIs must authenticate and authorize every call trusting internal network location or unvalidated tokens breaks zero trust. |
| Compliance | Exposed personal or payment data triggers obligations under GDPR, India's DPDP Act, PCI DSS and sector rules. |
3. Technical Explanation
Risks 3.1 to 3.10 follow the OWASP API Security Top 10 (2023). Section 3.11 adds injection, GraphQL and AI/LLM APIs, and 3.12 covers monitoring.
3.1 Broken Object Level Authorization (API1)
BOLA occurs when an API returns or changes an object based on an ID in the request, such as /accounts/{id}, without checking that the caller may access it. It is the top ranked API risk.
What to test: swap object IDs between two accounts of the same role in paths, query strings, bodies and headers, including bulk and export endpoints.
Attack context: T1190; object ID enumeration and data scraping.
Telemetry: high volumes of varied object IDs from one token; spikes in 403/404 responses.
3.2 Broken Authentication (API2)
Common issues include missing rate limits on login and password reset, weak JWT validation (“none” algorithm, weak secrets, missing expiry, audience or issuer checks), long lived tokens and API keys used as the only user authentication.
What to test: brute force protections; token signature, claims, expiry and revocation; OAuth 2.0 redirect URI validation, PKCE and scopes against RFC 9700 (OAuth 2.0 Security Best Current Practice); MFA on sensitive actions.
Attack context: T1110 Brute Force, T1528 Steal Application Access Token, T1078 Valid Accounts.
Telemetry: authentication failure bursts and token use from new IPs or devices, correlated with identity provider logs in the SIEM.
3.3 Broken Object Property Level Authorization (API3)
This covers excessive data exposure (returning internal or sensitive fields) and mass assignment (accepting fields the user should not set, such as “role”: “admin” or “price”: 0).
What to test: compare API responses with what the UI shows; add or modify properties in requests confirm responses are filtered server side.
Telemetry: response size anomalies and unexpected fields in requests.
3.4 Unrestricted Resource Consumption (API4)
APIs without limits on request rate, payload size, pagination, uploads or costly operations can be abused for denial of service or high cloud and third party costs, such as SMS or email charges.
What to test: rate limits per user, token and IP; page size and query complexity limits; upload limits; cost-generating operations.
Attack context: T1499.003 Application Exhaustion Flood.
Telemetry: rate-limit events, latency spikes and abnormal per-client volumes.
3.5 Broken Function Level Authorization (API5)
BFLA lets regular users call privileged functions, for example by changing GET to DELETE or calling /admin/ endpoints directly.
What to test: build a role × endpoint × HTTP method authorization matrix and test every combination, including hidden endpoints found in JavaScript, mobile apps and documentation.
Attack context: privilege escalation through administrative functions.
Telemetry: non admin identities calling admin endpoints.
3.6 Unrestricted Access to Sensitive Business Flows (API6)
Flows that are legitimate individually, such as purchasing limited stock, creating accounts or redeeming offers, become harmful when automated by bots.
What to test: identify high value flows and verify device fingerprinting, bot detection, per account limits and step up verification.
Telemetry: behavioral analytics on flow completion rates, request timing and client characteristics.
3.7 Server-Side Request Forgery (API7)
SSRF occurs when an API fetches a user supplied URL (webhooks, file imports, link previews) without validating the destination. In the cloud, attackers use it to reach instance metadata and internal services.
What to test: internal IP ranges, cloud metadata addresses, alternative IP encodings and redirects to internal hosts.
Attack context: T1552.005 Cloud Instance Metadata API.
Telemetry: outbound requests to metadata or internal ranges; cloud audit logs showing instance credentials used from unexpected locations.
3.8 Security Misconfiguration (API8)
Examples include verbose errors and stack traces, permissive CORS, weak TLS or missing security headers, unnecessary HTTP methods, default credentials and exposed debug or GraphQL introspection endpoints.
What to test: error handling, CORS, TLS, enabled methods, gateway configuration and the cloud resources hosting the API. CSPM and Infrastructure as Code scanning keep cloud posture aligned.
3.9 Improper Inventory Management (API9)
Many enterprises lack a current inventory of APIs, versions, environments and data flows. Old versions and non production APIs connected to production data are common entry points.
What to test: discover APIs from gateway logs, traffic, DNS and certificate records, mobile apps and code repositories, and compare with the documented inventory.
Attack context: Active Scanning, including Wordlist Scanning (T1595.003), to find undocumented endpoints.
Telemetry: traffic to endpoints not in the inventory.
3.10 Unsafe Consumption of APIs (API10)
Applications often trust third party API data more than user input. A compromised partner API can deliver malicious data that is processed without validation.
What to test: validation of third party responses, TLS enforcement, redirect limits, timeouts, and inclusion of third party APIs in vendor risk assessments.
3.11 Additional Areas: Injection, GraphQL and AI/LLM APIs
Injection: fuzz parameters and JSON bodies for SQL, NoSQL, command and template injection; verify parameterized queries and input validation.
GraphQL: introspection exposure, query depth and complexity limits, batching that bypasses rate limits, and authorization on every resolver.
AI / LLM APIs: direct and indirect prompt injection, sensitive information disclosure, improper output handling and excessive agency (OWASP Top 10 for LLM Applications). Agent tool calls should use the requesting user’s permissions. This is a growing part of AI security and LLM security testing.
3.12 API Telemetry and Detection Engineering
API gateways, WAF/WAAP platforms and application logs should record caller identity, token or client ID, endpoint, method, object IDs, response codes and sizes, and rate limit events. Correlated in the SIEM with identity provider logs, EDR telemetry from API hosts and cloud audit logs, this data supports detection engineering for enumeration, credential stuffing, token misuse and data exfiltration. Per client behavioral baselines help the SOC detect misuse that uses valid credentials and well formed requests.
4. Compliance Impact
| Framework | Relevant requirements |
|---|---|
| PCI DSS v4.0 | Req. 6.2.4 software engineering techniques against common attacks, including business logic abuse through APIs; Req. 6.4 public facing web application protection; Req. 10 logging and monitoring; Req. 11.4 penetration testing |
| ISO/IEC 27001:2022 | Annex A 8.26 Application security requirements, 8.28 Secure coding, 8.29 Security testing in development and acceptance, 8.15 Logging, 8.16 Monitoring activities |
| SOC 2 | Logical access controls, vulnerability management and system monitoring |
| GDPR | Art. 25 data protection by design and default (limit API responses to necessary data); Art. 32 regular security testing; Art. 33 breach notification within 72 hours where feasible |
| DPDP Act, 2023 / CERT-In | Reasonable security safeguards and breach reporting to the Data Protection Board of India; CERT-In April 2022 directions require reporting specified incidents within six hours |
| HIPAA Security Rule | Access control, audit controls and transmission security (45 CFR 164.312) for APIs handling ePHI |
| DORA / NIS2 | DORA digital operational resilience testing for EU financial entities; NIS2 Art. 21 security in development and vulnerability handling |
5. Example Use Case
An insurance enterprise runs a mobile app and partner portal on REST APIs and a GraphQL layer in a public cloud. A new AI assistant answers policy questions through an LLM API connected to a document retrieval pipeline.
| Finding | Risk | Remediation |
|---|---|---|
| Claims API returns documents for any claim ID | API1 BOLA | Server side ownership checks; automated per-role authorization tests in CI/CD |
| Policy update accepts a hidden "premiumDiscount" field | API3 mass assignment | Allowlist writable properties; server side schema validation |
| Unused v1 customer API still reachable without rate limits | API9, API4 | Retire v1; gateway rate limits on all versions; API inventory with owners |
| GraphQL introspection enabled; no depth limits | API8 | Disable introspection in production; enforce depth and complexity limits |
| Document import fetches any URL, including cloud metadata | API7 SSRF | Outbound allowlist; IMDSv2 or equivalent metadata protection |
| AI assistant follows instructions hidden in uploaded documents | Indirect prompt injection | Entitlement aware retrieval, input/output guardrails, prompt logging |
Outcome: gateway, application, identity and cloud logs flow to the SIEM with detections for enumeration, mass assignment and metadata access; fixes are retested and evidence is mapped to ISO/IEC 27001, GDPR and DPDP Act obligations.
6. API Security Testing Checklist
| ☐ | Area | What to test |
|---|---|---|
| ☐ | API inventory | Discover all APIs, versions and environments; confirm owners and data classification. |
| ☐ | Specifications | Maintain OpenAPI or GraphQL schemas and test against them. |
| ☐ | Object level authorization | Swap object IDs between users of the same role on every endpoint. |
| ☐ | Function level authorization | Test each role against each endpoint and HTTP method. |
| ☐ | Property level authorization | Check for excessive data in responses and mass assignment in requests. |
| ☐ | Authentication | Brute force protection, token validation, expiry, revocation and MFA on sensitive actions. |
| ☐ | OAuth 2.0 / OIDC | Redirect URIs, PKCE, scopes and token audience. |
| ☐ | Rate limiting | Limits per user, token and IP; payload and pagination limits. |
| ☐ | Business flows | Automated abuse of high value flows and anti bot controls. |
| ☐ | SSRF | URL inputs against internal ranges and cloud metadata endpoints. |
| ☐ | Injection | Fuzz parameters and JSON bodies for SQL, NoSQL, command and template injection. |
| ☐ | Configuration | CORS, TLS, error handling, HTTP methods and debug endpoints. |
| ☐ | GraphQL | Introspection, depth and complexity limits, batching and resolver authorization. |
| ☐ | Third-party APIs | Validate inbound third party data; assess vendor API risk. |
| ☐ | AI / LLM APIs | Prompt injection, data leakage, output handling and agent tool permissions. |
| ☐ | Logging and detection | API logs reach the SIEM; detections exist for enumeration and token misuse. |
| ☐ | Retesting and evidence | Retest fixes; map results to PCI DSS, ISO/IEC 27001 and other frameworks. |
7. How ServQual and SUSAN Help
ServQual SUSAN (ServQual Unicorn Security Assessment Nexus) is a GenAI powered cybersecurity, privacy and GRC automation platform built on AWS. With ServQual’s testing and managed security services, it helps enterprises find API risks and manage them against compliance obligations.
| Capability | How it supports API security |
|---|---|
| API and application testing | VAPT and application security evaluations covering the risks in this guide, plus AI security assessments including LLM security testing and RAG security assessment. |
| Asset and cloud visibility | Asset inventory, automated data discovery and classification, and multi cloud security validation support API inventory and cloud configuration checks. |
| AI risk scoring | Connects data, evidence, assets, controls, vulnerabilities and regulatory context to produce risk scores, recommendations and compliance dashboards. |
| Continuous compliance | Automated assessments across ISO 27001, SOC 2, GDPR, NIST CSF, DORA and India's DPDP Act; ServQual also supports PCI DSS and HIPAA programs. |
| SOC and incident response | Managed SOC and SOCaaS for monitoring and threat detection; Incident Response Planning (IRP) module with built-in templates. |
| Third-party risk | Vendor risk assessment to govern partner and supplier APIs. |
“API security requires more than automated scanning. The most serious weaknesses often sit in authorization, business logic, identity, inventory and telemetry.”
Himanshu Warulkar
Front-End Developer | ServQual
FAQ
Most frequent questions and answers
The article follows the OWASP API Security Top 10 (2023), including BOLA, broken authentication, broken object property level authorization, unrestricted resource consumption, BFLA, sensitive business-flow abuse, SSRF, security misconfiguration, improper inventory management and unsafe consumption of APIs.
Because many serious API weaknesses are authorization and business-logic errors in valid, authenticated requests. Effective testing requires multiple roles, users and business-context understanding.
Broken Object Level Authorization occurs when an API uses an object identifier without properly verifying whether the caller is authorized to access that object.
Testing should include brute-force protections, token signature and claim validation, expiry, revocation, OAuth 2.0 redirect URI validation, PKCE, scopes and MFA for sensitive actions.
SSRF can let attackers force an API to reach internal services or cloud metadata endpoints, potentially exposing temporary cloud credentials and opening paths to further compromise.
Shadow APIs, zombie versions and forgotten non-production endpoints expand the attack surface. Enterprises should discover APIs from gateway logs, DNS, traffic, mobile apps and code repositories, then compare them with the documented inventory.
In addition to standard API testing, enterprises should test direct and indirect Prompt Injection, sensitive information disclosure, improper output handling and excessive agency, with agent tool calls constrained to the requesting user’s permissions.
Relevant telemetry includes caller identity, token or client ID, endpoint, method, object IDs, response codes, response sizes and rate-limit events, correlated with identity, EDR and cloud audit logs in the SIEM.
ServQual provides VAPT and application security evaluations, including AI Security Assessment, LLM Security Testing and RAG Security Assessment. SUSAN supports asset visibility, AI Risk Scoring, Continuous Monitoring & Evidence, compliance mapping, SOC integration and Third-Party Risk.
Strengthen Your API Security Posture
Identify authorization flaws, business logic abuse, shadow APIs, SSRF, GraphQL weaknesses and AI/LLM API risks with ServQual API Security Assessment and VAPT.
Disclaimer: This article is provided for general API Security and Cybersecurity guidance. Testing scope, controls and remediation priorities should be adapted to the organisation’s architecture, business logic, data sensitivity, threat model and applicable regulatory requirements.
