Yes. Under the API penetration testing scope requirements 2-11-3, APIs are expressly identified as technical components that support externally provided online services and must therefore be included in the penetration-testing scope where relevant. The common belief that APIs are optional because they are “back-end” services is incorrect: ECC – 2:2024 control 2-11-3 requires coverage of Internet-facing services and their supporting technical components, and its implementation guidance specifically lists API.
What is the myth about API penetration-testing scope?
The myth is that a penetration test can meet ECC requirements by testing only the public website, mobile application screens, VPN portal, and email gateway. Under this approach, APIs may be treated as an application-development concern, tested only through a code review, or excluded because they do not have a user-facing interface.
This interpretation creates a material compliance and security gap. An API can expose customer records, employee information, payment functions, business workflows, or administrative actions even when the organisation’s website appears secure. A tester who checks only browser-based pages may never assess broken object-level authorisation, weak token validation, excessive data exposure, insecure rate limiting, or undocumented API endpoints.
For Saudi organisations, this distinction is particularly important when services are delivered through government-facing portals, customer applications, cloud-hosted platforms, mobile apps, partner integrations, or externally accessible business systems. The API may be the principal attack surface, not merely a supporting element.
Why is this misconception so widespread?
First, many procurement statements of work still describe a “web penetration test” rather than a test of the full Internet-facing service. If the contracted scope names only a website URL, the provider may test the web interface and avoid API discovery, mobile traffic analysis, or separate API gateway testing unless these are explicitly included.
Second, organisations often have fragmented asset ownership. Digital teams own the website, mobile teams own the application, infrastructure teams own load balancers and web servers, and integration teams own API gateways. No single owner may maintain a complete view of how an external service is delivered. As a result, the penetration-testing scope can mirror the organisation chart rather than the actual service architecture.
Third, some teams assume that APIs are automatically covered when a mobile app or website is tested. That assumption is unsafe. A test may intercept and inspect selected API calls, but this does not demonstrate that all versions, methods, authentication flows, administrative endpoints, and externally reachable API hosts were assessed. Coverage must be defined and evidenced, not inferred.
What do API penetration testing scope requirements 2-11-3 actually say?
ECC – 2:2024 practice 2-11-3 requires cybersecurity requirements for penetration-testing processes to include specific minimum elements. Under sub-control 2-11-3-1, the requirement is:
“Scope of penetration tests which must cover Internet-facing services and its technical components including infrastructure, websites, web applications, mobile apps, email and remote access.”
The accompanying implementation guidance removes any ambiguity. Organisations are expected to identify and document all services provided online and identify the technical components supporting those external services. The listed components include websites and web applications, smartphone and tablet applications, API, servers used for external services, remote-access servers, email servers, and network devices used to provide external services.
The word including matters. It means the listed assets establish the minimum expected coverage categories; it is not a reason to limit testing to only a homepage or a single public IP address. If an API gateway, API management platform, reverse proxy, cloud load balancer, authentication service, or exposed integration endpoint supports an Internet-facing service, it should be evaluated during scoping.
Sub-control 2-11-3-2 adds the periodicity requirement. The organisation must document penetration-testing procedures and develop and implement an action plan that shows the annual penetration-testing schedule for relevant information and technology assets. A one-time API test conducted during initial deployment does not, by itself, satisfy the requirement for ongoing testing.
Does every API endpoint have to be tested separately?
Not necessarily as an isolated engagement, but every relevant externally accessible API service and endpoint category must be accounted for in the defined scope and testing approach. ECC 2-11-3 does not prescribe a fixed number of API requests, URLs, or test cases. It requires the organisation to scope Internet-facing services and their technical components properly, then conduct penetration tests periodically.
A defensible approach is to maintain an API inventory and group endpoints by risk, authentication method, data sensitivity, privilege level, and technical stack. For example, an authenticated customer API, a partner API using mutual TLS, and an administrative API behind an API gateway should not be treated as one interchangeable test target merely because they share the same domain name.
| External service component | Example test focus | Evidence to retain |
|---|---|---|
Customer REST API at api.example.sa |
Object-level authorisation, JWT validation, rate limiting, input validation, data exposure | Endpoint inventory, Burp Suite Professional project file, test report, remediation evidence |
| Mobile application API | Intercepted traffic, certificate-pinning controls, insecure direct object references, session handling | Mobile build identifier, API request samples, test report and retest results |
| API gateway and reverse proxy | TLS configuration, exposed methods, routing bypass, security-header controls, access policy enforcement | Gateway configuration reference, host list, approved scope and report findings |
| Partner integration API | Authentication segregation, tenant isolation, IP allow-list enforcement, excessive privileges | Partner endpoint register, rules of engagement, test evidence and risk acceptance where applicable |
How should a Saudi organisation scope API testing correctly?
- Start with the online-service inventory. Identify every service provided externally, not only the corporate website. Include customer portals, mobile applications, e-commerce functions, SaaS portals, partner integrations, public DNS services, VPN access, webmail, and cloud-hosted services.
- Map each service to its technical components. For every service, document domains, IP addresses, API base URLs, API gateways, load balancers, web servers, identity providers, cloud services, mobile application packages, email infrastructure, and remote-access infrastructure. This mapping is where APIs are often missed.
- Classify API exposure and business risk. Record whether the API is public, authenticated, partner-accessible, mobile-only, or intended for internal use but reachable from the Internet. Identify data types, privileged functions, and dependencies on identity and payment services.
- Write the penetration-testing requirements document. State that Internet-facing APIs supporting external services are within scope, define authorised testing windows and contacts, and specify exclusions only where formally justified. The document should be approved by the head of the organisation or delegated representative.
- Convert the inventory into an annual action plan. Set testing dates, responsible owners, third-party coordination requirements, retest deadlines, and reporting expectations. New high-risk APIs should trigger a scope review rather than waiting automatically for the next annual cycle.
- Require meaningful API test evidence. The final report should identify tested hosts, API versions, authentication roles, endpoint groups, test limitations, findings, severity ratings, and retest status. A report that says “web application tested” without naming the API assets is weak evidence for ECC 2-11-3.
A practical scope statement could read as follows:
Scope includes all Internet-facing services and supporting components: www.example.sa, portal.example.sa, api.example.sa/v1 and /v2, the customer mobile application APIs, Azure API Management gateway, public load balancers, VPN gateway, Microsoft 365 email access configuration, and externally reachable remote-access infrastructure. Testing includes authenticated and unauthenticated API assessment using approved accounts with customer, partner, and administrator roles.
What related misconceptions should GRC teams address?
“Our API is behind a mobile app, so it is not Internet-facing.”
If the mobile application communicates with an API over the Internet, that API supports an Internet-facing service even if users do not type its URL into a browser. Restricting access through a mobile application does not remove the need to identify and assess the API.
“A vulnerability scan is enough for API compliance.”
Automated scanning can support the process, but it is not equivalent to a penetration test. API authorisation flaws, business-logic weaknesses, and role-segregation failures commonly require authenticated, contextual testing by skilled personnel. The API penetration test scope should therefore distinguish scanning activities from manual validation and exploitation within approved rules of engagement.
“Our cloud provider tests the infrastructure, so we can exclude the API.”
A cloud provider may secure elements of the underlying platform under a shared-responsibility model, but the organisation remains responsible for the API design, gateway configuration, authentication model, exposed endpoints, and application logic. Provider assurance does not evidence testing of the organisation’s Internet-facing service.
Next step: Ask each Saudi client to reconcile its external-service register against its latest penetration-test scope and formally add every supporting API that has not been explicitly identified.
