This blog explains how API dependencies can change the security risk of a CERT-In audited application. It covers different types of API dependencies, changes in API versions, authentication and authorization risks, cloud and infrastructure connections, sensitive data flows, and changes that may affect the CERT-In audit scope.
It also explains how organizations can identify API dependencies, assess critical API connections, collect suitable audit evidence, and reassess API security after major application or integration changes.
What Are API Dependencies in a CERT-In Audited Application?
API dependencies are the APIs that an application uses to exchange data, perform functions, verify information, process transactions, or connect with other systems. A CERT-In security audit should account for these APIs because they can form part of the application architecture, data flow, and security scope.
1. Internal APIs Used by the Application
Internal APIs connect different application components, such as the web application, mobile application, databases, microservices, and transaction services. Even when an API is not directly exposed to the internet, it should be reviewed for authentication, authorization, input validation, and access between internal services.
2. Third-Party APIs
Third-party APIs allow an application to use services provided by another organization. These APIs may handle customer information, payments, identity checks, notifications, analytics, or other application functions, so their role and exchanged data should be identified during the audit.
3. Payment and Banking APIs
Payment and banking APIs can connect an application with banks, payment processors, payment gateways, or financial service providers. Testing should examine authentication, transaction data, authorization, response handling, callback security, and controls around payment status changes.
4. Identity and Authentication APIs
Identity APIs may support login, MFA, KYC, identity verification, account recovery, or single sign-on. If the application relies on an external identity service, the audit should examine how authentication results are received, validated, and mapped to application users and roles.
5. Cloud Service APIs
Cloud APIs can control storage, computing resources, databases, identity services, networking, and other cloud functions. Incorrect permissions or exposed cloud API credentials can give access to services that support the audited application.
6. Data and Verification APIs
Applications may use external APIs for address checks, identity verification, fraud checks, credit information, document validation, or other data services. The audit should identify what information is sent, what information is returned, and how the application processes the response.
7. Partner and Vendor APIs
Partner and vendor APIs can connect the application with business partners, service providers, logistics platforms, technology vendors, or other systems. Their access should be reviewed according to the data exchanged, permissions provided, authentication method, and business function supported.
How Can API Dependencies Change the Security Risk of an Application?
Adding an API dependency can introduce another system, endpoint, authentication method, data flow, or service account into the application environment. OWASP identifies risks such as broken authentication, authorization failures, improper API inventory, security misconfiguration, and unsafe consumption of APIs.
1. New External Attack Surfaces
A new external API can add endpoints that need to be secured and monitored. Old API versions, exposed test endpoints, and poorly protected API hosts can create additional entry points into the application environment.
2. Additional Data Flows
An API dependency can cause customer, financial, authentication, or business information to move between systems. Each additional data flow should be identified and reviewed to determine what information is shared and where it goes.
3. New Authentication Dependencies
An application may depend on API keys, OAuth tokens, service accounts, certificates, or other credentials to communicate with another system. Weak credential handling or incorrect token validation can affect the security of the application.
4. Additional Authorization Requirements
API dependencies require decisions about which users, services, and applications can access specific API functions. A failure to apply proper object-level or function-level authorization can allow access to information or operations outside the user’s permission.
5. Dependency on Third-Party Security Controls
The application may depend on another service for authentication, payment processing, identity checks, data validation, or other functions. This creates a need to understand the security controls applied to that dependency and how the application responds if those controls or services fail.
6. New API Endpoints and Services
Adding an API can introduce new hosts, endpoints, API versions, gateways, service accounts, and supporting infrastructure. OWASP recommends maintaining an inventory of API hosts, versions, environments, endpoints, authentication methods, and integrated services.
7. Changes to the Application Architecture
An API dependency can change how different application components communicate. A previously direct process may become dependent on an external service, creating new communication paths and additional components that should be considered during security testing.
Why Should API Dependencies Be Included in the CERT-In Audit Scope?
CERT-In’s 2025 audit guidelines specifically state that the audit scope should include APIs along with applications, cloud architecture, databases, hosting infrastructure, and other parts of the cyber infrastructure. The scope should also be derived from an updated asset inventory.
1. APIs Can Support Critical Application Functions
APIs may control functions such as login, payments, transactions, account management, reporting, or data processing. If a critical application function depends on an API, that dependency should be considered during the audit.
2. APIs Can Process Sensitive Information
APIs may transfer personal information, financial information, authentication data, account details, or business information. The audit should examine whether access to this information is properly controlled.
3. External Services Can Affect Application Security
A third-party service can influence application decisions through the data it sends back. OWASP warns that applications may trust data received from third-party APIs without applying the same security checks used for user input.
4. API Failures Can Affect Application Workflows
If an application depends on an API for payment confirmation, identity verification, transaction processing, or another important step, API failure can affect the application’s workflow. The audit should examine how the application handles unavailable, delayed, invalid, or unexpected API responses.
5. New APIs Can Change Existing Data Flows
When an API is introduced, information may begin moving between systems that were not previously connected. The audit scope should account for these new connections and the information exchanged through them.
6. API Changes Can Expand the Audit Scope
Adding a new API, changing an API provider, introducing a new API version, or changing the information exchanged can affect the application’s architecture and security scope. These changes should be reflected in the asset inventory and audit planning.
How Should Third-Party APIs Be Identified Before a CERT-In Security Audit?
Before testing begins, the organization should identify the APIs that the application depends on and document their role, environment, access method, data flow, and owner. This helps ensure that important API dependencies are not left outside the audit scope.
1. Creating an API Dependency Inventory
Create a list of internal and external APIs connected to the application. The inventory should include API hosts, endpoints, versions, environments, owners, and the function each API performs.
2. Identifying API Owners
Each API should have a clearly identified owner or responsible team. This helps establish who manages the API, who approves changes, and who handles security issues.
3. Identifying External API Providers
Record the organization providing each third-party API. This is particularly important for APIs handling customer, financial, authentication, or other sensitive information.
4. Mapping API Endpoints
Document the endpoints used by the application and the functions they perform. Older, unused, development, staging, and test endpoints should also be identified.
5. Identifying Data Shared With Each API
Document the information sent to and received from each API. OWASP recommends documenting integrated services, their role, exchanged data, and data sensitivity as part of API inventory management.
6. Recording Authentication Methods
The inventory should record whether each API uses API keys, OAuth, certificates, service accounts, tokens, or another authentication method. Credential storage and access should also be reviewed.
7. Tracking API Versions
Record the API version used by the application and identify older versions that may still be active. OWASP notes that outdated API versions can have weaker security controls and may expose sensitive data.
What API Security Controls Should Be Tested During a CERT-In Audit?
API testing should examine the controls that protect authentication, authorization, data, resources, endpoints, and API operations. OWASP’s API Security Top 10 provides specific areas such as broken authentication, object-level authorization, function-level authorization, resource consumption, security misconfiguration, inventory management, and unsafe API consumption.
1. API Authentication
Test whether APIs correctly verify the identity of users, applications, and services. Invalid, expired, revoked, or modified authentication credentials should not provide access.
2. API Authorization
Authentication should be followed by permission checks. Testing should verify whether the requesting user or service is allowed to access the specific API function and resource.
3. Object-Level Access Control
Test API requests containing identifiers such as customer IDs, account IDs, transaction IDs, or document IDs. Changing an identifier should not allow access to another user’s object.
4. Input Validation
API parameters, headers, request bodies, uploaded data, and other inputs should be validated on the server. Testing should check whether unexpected or manipulated values are accepted.
5. Output Validation
API responses should be reviewed to ensure that they contain only the information that the requesting user or service is authorized to receive. Sensitive fields should not be returned unnecessarily.
6. Rate Limiting
Sensitive APIs should control how frequently requests can be made. OWASP notes that unrestricted resource consumption can affect availability and can also increase costs when APIs depend on paid external services.
7. API Error Handling
API errors should not expose credentials, internal paths, database details, stack traces, service information, or other sensitive technical information. Error responses should provide only the information needed by the client.
8. API Logging
Important API activity should be recorded so that access, failed authentication, sensitive operations, administrative actions, and transaction activity can be reviewed. Logs should support investigation of security events involving API dependencies.
How Can Unsafe Third-Party API Consumption Increase Application Risk?
An application can become exposed when it trusts data from a third-party API without validating the response. OWASP identifies this as unsafe consumption of APIs and notes that attackers may target an integrated service instead of directly attacking the primary application.
1. Trusting Data From External APIs
The application should not automatically treat every response from an external API as safe. Responses should be validated before they are used in sensitive application decisions.
2. Missing Response Validation
An external API response should be checked for expected structure, data type, value, and security conditions. Missing validation can allow unexpected data to affect application processing.
3. Unsafe Data Processing
Data received from an external API may later be used in database queries, HTML output, commands, files, or other application functions. The application should apply suitable validation and encoding before using that data.
4. Unvalidated Redirects
If an external API provides a URL that the application later uses for redirects or other navigation, that URL should be validated. The application should not automatically redirect users to an untrusted destination.
5. Missing Request Timeouts
API calls should have suitable timeout controls. Without them, a slow or unavailable dependency can keep application processes waiting and affect service availability.
6. Weak Third-Party Authentication
The application should use appropriate authentication when communicating with external APIs. API keys, tokens, certificates, and service credentials should be protected and should have only the permissions they require.
7. Uncontrolled External API Responses
Unexpected responses, excessive response sizes, invalid data, repeated responses, and service errors should be handled safely. The application should not assume that an external service will always return the expected result.
How Can API Dependencies Affect Sensitive Data Protection?
API dependencies can create additional locations where sensitive information is transmitted, processed, or stored. The audit should identify what information crosses each API connection and whether that exchange is required.
1. Customer Data Sent to External APIs
Customer information sent to a third-party API should be identified and reviewed. Only the information required for the intended function should be shared.
2. Authentication Information Shared With Vendors
Authentication tokens, identity attributes, account identifiers, or verification information may be shared with identity providers and other services. Their use and protection should be reviewed carefully.
3. Financial Data Sent to Third Parties
Payment amounts, account information, transaction details, and other financial data may pass through external APIs. The audit should examine access, transmission, storage, and response handling for this information.
4. Personal Information in API Requests
API requests should be reviewed for personal information that may not be required for the service. Unnecessary information sharing increases the amount of data handled by external systems.
5. Sensitive Data Returned by APIs
An API may return more information than the application needs. The application should restrict which response fields are stored, displayed, logged, or passed to other services.
6. Data Stored by External Services
Where a third-party API stores application data, the organization should identify what information is retained by that service and how it is accessed. This dependency should be reflected in the audit scope where applicable.
7. Unnecessary Data Sharing
API integrations should be reviewed to determine whether each data field being exchanged is required for the intended function. Unnecessary data transfers should be identified during the security assessment.
How Should API Authorization Be Tested When External Services Are Involved?
Authorization testing should cover both the application user and the systems communicating with external APIs. The goal is to verify that every API request has the correct identity, role, object permission, and function permission.
1. User-to-API Authorization
Test whether a logged-in user can access only the API functions and information assigned to that user’s account. Changing IDs or request parameters should not provide access to another user’s resources.
2. Application-to-API Authorization
Test how the application authenticates and authorizes itself when communicating with an external service. The external API should receive only the permissions required for the intended application function.
3. Service Account Permissions
Service accounts used for API communication should have limited permissions. Testing should check whether a service account can perform functions beyond what the application requires.
4. Object-Level Authorization
Object-level authorization should be tested for customer accounts, transactions, documents, payments, and other resources accessed through APIs. OWASP recommends authorization checks whenever an API function accesses a data source using an identifier supplied by the user.
5. Function-Level Authorization
The API should verify whether the user or service is permitted to perform the requested function. This is particularly important for administrative, financial, account-management, and transaction-related operations.
6. Cross-System Access Controls
When multiple systems communicate through APIs, each connection should have defined access permissions. A trusted connection between two systems should not automatically provide unrestricted access to every function or dataset.
7. Privileged API Operations
Sensitive operations such as account changes, payment processing, transaction approval, administrative actions, and configuration changes should require appropriate authorization. Testing should verify that lower-privileged users and services cannot invoke these operations.
How Can API Version Changes Affect a CERT-In Audited Application?
Changing an API version can change the security controls, endpoints, authentication methods, data formats, and authorization rules used by an application. During a CERT-In security audit, API versions should therefore be identified and checked as part of the application and API inventory.
1. Deprecated API Versions
Deprecated APIs may continue to operate even after the application has moved to a newer version. The audit should identify whether these endpoints are still accessible, what data they handle, and whether they have the same security controls as the current API.
2. Older Security Controls
An older API version may use weaker authentication, authorization, validation, rate limiting, or error-handling controls. Testing should compare older and current versions to identify security differences that could expose the application.
3. Unpatched API Endpoints
An API endpoint that remains active after its supported version has changed may not receive current security updates. The audit should verify whether old endpoints are patched, monitored, protected, or properly retired.
4. Different Authentication Methods
Different API versions may use different authentication methods, such as API keys, OAuth tokens, certificates, or session tokens. Each method should be tested to confirm that expired, invalid, revoked, or incorrectly issued credentials cannot provide unauthorized access.
5. Different Authorization Rules
Authorization rules can change between API versions. Testing should verify that an older endpoint does not allow access to functions or data that are restricted in the newer version.
6. Legacy API Hosts
Older API versions may operate on separate hosts or infrastructure that is not included in the current application inventory. These hosts should be identified and checked for exposure, security configuration, access restrictions, and active dependencies.
7. Undocumented API Versions
Undocumented API versions can create gaps in security testing and asset management. The audit should identify API versions that are active but missing from application documentation, inventories, or architecture records.
What Security Risks Can API Authentication Dependencies Create?
API authentication dependencies determine how applications, users, and services prove their identity when communicating with APIs. Weak credential management or excessive permissions can allow unauthorized access to application functions or connected systems.
OWASP identifies broken authentication as a major API security risk because compromised or incorrectly implemented authentication mechanisms can allow attackers to assume another user’s identity.
1. Shared API Credentials
The same API credential should not be unnecessarily shared across multiple applications or services. If one system is compromised, shared credentials can allow access to other systems using the same identity.
2. Long-Lived API Keys
API keys that remain valid for long periods increase the impact if they are exposed. The audit should review key lifetime, storage, usage, revocation, and replacement procedures.
3. Weak Service Accounts
Service accounts used for API communication should have clearly defined permissions. Testing should check whether a service account can access functions or information beyond what its application requires.
4. Exposed Access Tokens
Access tokens may appear in application code, configuration files, logs, URLs, browser storage, or API responses if they are not handled properly. The audit should check where tokens are stored, transmitted, and exposed.
5. Improper Token Validation
The application should properly validate API tokens, including their validity, issuer, audience, expiry, and required claims where applicable. Testing should check whether modified, expired, revoked, or incorrectly scoped tokens are accepted.
6. Missing Credential Rotation
API credentials should have a defined process for replacement when required. The audit should review whether old credentials remain active after replacement and whether exposed credentials can be revoked quickly.
7. Excessive API Permissions
An API credential should have only the permissions required for its intended function. Excessive permissions can allow a compromised service account or token to perform sensitive operations that it does not need.
How Can API Dependencies Affect Cloud and Infrastructure Security?
API dependencies often connect applications with cloud services, databases, storage systems, identity platforms, and other infrastructure. CERT-In’s audit guidance covers broader cyber infrastructure rather than limiting assessment to only a website or application.
1. Cloud Service APIs
Cloud APIs may control computing resources, storage, databases, networking, identity services, and other cloud functions. The audit should review how these APIs are authenticated and which permissions are assigned.
2. API Gateway Configuration
API gateways may control authentication, routing, rate limits, access rules, and traffic filtering. Incorrect gateway settings can expose endpoints or allow requests to bypass expected controls.
3. Cloud IAM Permissions
Cloud identity and access management controls should be checked for API users, service accounts, roles, and applications. Excessive permissions can give an API dependency access to cloud resources beyond its required function.
4. Serverless API Functions
Serverless functions may process API requests, transaction data, authentication events, or other application operations. Testing should examine function permissions, input handling, exposed endpoints, secrets, and access to connected cloud resources.
5. API-Based Storage Access
APIs may provide access to cloud storage containing documents, reports, backups, customer data, or application files. Testing should verify authentication, authorization, object-level access, and storage permissions.
6. Internal Cloud Service Communication
Cloud applications may use APIs to connect different internal services. These connections should be reviewed for authentication, authorization, network access, service identities, and data exposure.
7. Internet-Facing API Services
Internet-facing APIs should be identified in the audit inventory and tested for authentication, authorization, exposed endpoints, configuration issues, rate controls, and sensitive data exposure. OWASP notes that API environments can expose more endpoints and hosts as applications use microservices and cloud infrastructure.
How Should Data Flows Between the Application and APIs Be Audited?
API data flows should be mapped to understand what information leaves the application, where it goes, what comes back, and how the application uses the response. OWASP recommends documenting integrated services, exchanged data, data sensitivity, API hosts, versions, and endpoints.
1. Application-to-API Data Flow
Document the information sent from the application to each API. This should include customer information, transaction data, authentication information, identifiers, and other sensitive fields where applicable.
2. API-to-Third-Party Data Flow
Identify information passed from one API or service to another external provider. The audit should determine whether the transfer is authorized and whether the receiving service requires all the information being sent.
3. Sensitive Data Transmission
Sensitive information transmitted through APIs should use suitable transport protection. The audit should also check whether sensitive values are unnecessarily included in URLs, logs, error messages, or API responses.
4. Data Transformation Between Systems
API data may be converted, combined, filtered, or reformatted before reaching another system. Testing should check whether security attributes, permissions, identifiers, or sensitive fields are changed incorrectly during this process.
5. API Response Processing
The application should validate information received from external APIs before using it. OWASP specifically warns that applications may trust third-party API responses too much and fail to apply adequate validation or sanitization.
6. Data Storage After API Processing
The audit should identify whether API responses are stored in databases, logs, files, caches, or other systems. Sensitive information should not be retained unnecessarily or made accessible to users who do not require it.
7. Data Retention at External Services
Where an external provider stores information received through an API, the organization should identify what information is retained and for what purpose. This dependency should be documented where it forms part of the application’s data flow.
How Can API Dependencies Change the Scope of a CERT-In Security Audit?
A change in API dependencies can introduce new systems, endpoints, data flows, authentication mechanisms, or infrastructure. CERT-In’s 2025 audit framework is intended to support audit planning through reporting and follow-up, making accurate scope definition important throughout the audit process.
1. Adding a New Third-Party API
Adding a new external API can introduce a new service provider, endpoint, data flow, credential, and dependency. The API should be added to the relevant inventory and assessed according to its role in the application.
2. Replacing an Existing API Provider
Changing an API provider can change authentication, data handling, endpoints, response formats, infrastructure, and security controls. The new integration should therefore be reviewed rather than assuming that the previous assessment remains sufficient.
3. Adding New API Endpoints
New endpoints can expose additional application functions or information. They should be included in API documentation, inventory, security testing, and relevant audit evidence.
4. Moving APIs to the Cloud
Moving an API from on-premises infrastructure to cloud infrastructure can introduce new cloud accounts, IAM roles, storage services, network controls, API gateways, and management interfaces. These components should be considered when defining the audit scope.
5. Changing API Authentication
Changing from one authentication method to another can introduce new token handling, credential storage, identity mapping, or access-control requirements. The new authentication flow should be tested before it becomes part of the audited application.
6. Changing Data Shared With APIs
If an API begins receiving additional customer, financial, authentication, or business information, the application’s data flow has changed. The updated flow should be documented and reviewed as part of the applicable audit scope.
7. Introducing New Business-Critical APIs
An API supporting payments, authentication, transactions, account management, or other important functions should receive appropriate security testing. A new dependency supporting a critical workflow can affect the security assessment of the application.
What Evidence Should Be Collected for API Dependencies During a CERT-In Audit?
API-related evidence should show what APIs exist, how they connect to the application, what security controls protect them, and what testing was performed. Evidence should correspond to the defined audit scope and support the findings recorded in the audit report.
1. API Inventory
Maintain records of API hosts, endpoints, versions, environments, owners, exposure levels, and supported functions. OWASP recommends an updated API inventory to reduce the risk associated with forgotten or deprecated endpoints.
2. API Architecture Diagrams
Architecture diagrams should show important connections between the application, APIs, third-party services, cloud services, databases, and other supporting systems.
3. Data Flow Documentation
Document what data moves between the application and each API. Sensitive data flows should be clearly identified so that their access and protection can be reviewed.
4. API Authentication Details
Evidence may include authentication methods, token configuration, API key controls, service account details, certificate configuration, and related security settings, subject to appropriate protection of secrets.
5. API Authorization Rules
Document which users, applications, roles, and service accounts can access particular API functions and resources. Testing evidence should show whether these authorization rules are correctly enforced.
6. Third-Party Integration Records
Maintain records of external API providers, integration purposes, connected services, data exchanged, API versions, and responsible owners.
7. API Security Testing Results
Security testing records should identify tested endpoints, authentication methods, authorization checks, input validation, sensitive data handling, rate controls, configuration issues, and other relevant findings.
8. API Logs and Monitoring Records
Where applicable, logs should support verification of API access, authentication events, administrative actions, errors, transaction activity, and other important security events.
How Should a CERT-In Auditor Assess the Risk of a Critical API Dependency?
A critical API dependency should be assessed based on what function it supports, what data it handles, how it is accessed, and what could happen if its security controls fail. The assessment should also consider the application’s reliance on the external service.
1. Identify the API Function
First identify what the API does for the application. Authentication, payment, transaction processing, customer data, administrative functions, and other important services require closer review.
2. Identify the Data Being Exchanged
Determine what information is sent to and received from the API. The sensitivity of that information helps determine the security controls that should be reviewed.
3. Identify the API Owner
Identify the internal owner and, where applicable, the external service provider. Clear ownership helps establish responsibility for API security, changes, monitoring, and incident response.
4. Review Authentication and Authorization
Review how the application authenticates with the API and how access is authorized. Testing should include credentials, tokens, service accounts, roles, and resource-level permissions.
5. Assess Third-Party Security Controls
Where an external service is involved, review the security controls relevant to the dependency and the information exchanged. The application should not assume that a third-party API response is safe without appropriate validation.
6. Test Failure and Abuse Scenarios
Test how the application responds to API timeouts, unavailable services, invalid responses, repeated requests, unexpected data, authentication failures, and authorization failures.
7. Review the API’s Effect on Application Security
Finally, determine how the API dependency affects the security of the application as a whole. A weakness in a connected API can affect data access, authentication, transactions, or other application functions depending on the integration.
Why Should API Dependencies Be Reassessed After Major Application Changes?
API dependencies can change when applications are updated, migrated, integrated with new services, or moved to different infrastructure. Reassessment helps verify that the API inventory, data flows, authentication, authorization, and security testing still match the current application environment.
1. Adding New APIs
Every new API should be reviewed for its function, data access, authentication, authorization, endpoint exposure, and relationship with existing services.
2. Changing API Providers
Changing providers can introduce different infrastructure, authentication methods, API versions, data processing practices, and security configurations.
3. Changing API Permissions
Changes to API roles, service accounts, IAM policies, or application permissions can increase access to sensitive resources. These changes should be reviewed and tested.
4. Adding New Data Exchanges
When new information starts moving between the application and an API, the updated data flow should be documented and assessed.
5. Changing API Authentication
A new authentication mechanism can introduce different token handling, credential storage, identity mapping, and authorization requirements. The complete authentication flow should be retested.
6. Updating API Versions
Moving to a new API version should include checks for changes in endpoints, authentication, authorization, request parameters, responses, and security controls. Older versions should also be identified and retired where they are no longer required. OWASP specifically recommends assessing the risks of older API versions when newer versions introduce security improvements.
7. Changing Critical Application Workflows
If an API becomes part of a payment, authentication, transaction, account-management, or administrative workflow, its security role becomes more significant. The changed workflow should be included in appropriate security testing and audit scope reviews.
Conclusion
API dependencies can change the security profile of a CERT-In audited application by introducing new endpoints, authentication mechanisms, data flows, cloud services, third-party providers, and business-critical connections. An application may therefore have a different security scope after APIs are added, replaced, updated, or given access to new information.
A complete assessment should maintain an updated API inventory, map data flows, review API versions, test authentication and authorization, examine third-party API handling, and document the evidence supporting the audit. OWASP specifically recommends tracking API hosts, versions, integrated services, exchanged data, and API security controls, while CERT-In’s 2025 audit framework provides the broader structure for planning, conducting, reporting, and following up on cybersecurity audits.
Want to discuss your cybersecurity priorities for this quarter? Schedule a free scoping call with our team today.