SAP's Destination service manages routing and authentication information used by a cloud application to reach a remote service. For an on-premise system, SAP says the Destination service can work with the Connectivity service, while Cloud Connector controls the exposed systems and resources. A security assessment therefore needs to follow the entire customer-configured route, not just confirm that the tunnel is online. SAP, Destination Service SAP, Configure Accessible Resources
Quick answer. An SAP BTP Cloud Connector and destination security assessment should pair each in-scope destination with its proxy type, virtual host and port, internal system mapping, permitted URL paths and authentication method. Test one approved and one prohibited resource for each important route using customer-owned applications and synthetic data. Stingrai can scope human-led cloud, application, API and network testing around those named boundaries and report which control decided each result.
SAP says a newly installed Cloud Connector exposes no network systems or resources until an administrator configures them. Its HTTP access control documentation then describes strict resource allowlists: paths not explicitly granted are denied. That design makes the configured exception set the meaningful test surface. The buyer should ask whether each mapping and path still matches its current business purpose. SAP, Configure Accessible Resources SAP, Configure Access Control for HTTP
The route is the asset
Start with one business transaction: a cloud application reads a bounded set of purchase orders, sends a controlled status update, or queries a named internal API. Record the SAP BTP subaccount, application, destination name, destination URL, ProxyType, Cloud Connector instance, virtual host and port, internal host and port, allowed resource path, authentication mode and backend owner. If several routes share a connector, each still needs its own expected-access statement.
An inventory of destinations without Cloud Connector mappings is incomplete. A mapping without the consuming application is equally hard to judge. The buyer needs to know which route the application actually calls, which internal system receives it and what that system returns for a permitted and a prohibited operation. Keep separate the cloud application authorization, the Cloud Connector allowlist and the backend authorization. A failure at one layer cannot prove the others are safe.
SAP's HTTP Destinations documentation identifies Internet, OnPremise and PrivateLink as proxy types. It says ProxyType is a destination property and that Internet is the default. The test plan should verify that a destination intended for an internal system is actually configured for the expected route, and that a similarly named Internet destination is not being mistaken for it. This is configuration review, followed by selected customer-owned application observations. SAP, HTTP Destinations
The virtual host is another key. SAP says the Cloud Connector virtual host matches the host in the destination URL. It can be a fictional name, while the internal host and port identify the real backend. A security report should show both sides of that mapping. A fictional virtual host is not an error; an unexpected internal target, overly broad mapping or outdated route is the concern. SAP, Configure Access Control for HTTP
A buyer's route matrix
This matrix is an editorial assessment model. Substitute named systems and synthetic records before testing. The business owner should agree on the expected result for every positive and negative case. A blocked request is useful evidence only when the route and expected policy are known.
Gate | Configuration evidence | Controlled observation | Business decision | Owner |
|---|---|---|---|---|
Consuming application | App identity and destination name | Approved app invokes selected route; unrelated app is denied by its own control | Which app may use the route? | BTP application owner |
Destination | URL, ProxyType, authentication type, subaccount | Named destination resolves to intended virtual target | Is this the current approved target? | BTP platform owner |
Connector mapping | Virtual host and port to internal host and port | Allowed synthetic call reaches only the intended backend | Does the mapping expose the right system? | Network and backend owners |
Resource path | Exact path or path with subpaths | Approved path succeeds; nearby prohibited path is denied | Which endpoint paths are required? | API owner |
Principal trust | Trusted identity provider and propagation setting | Approved user maps correctly; unrelated identity does not gain the same backend access | Whose identity is allowed through? | Identity and backend owners |
Audit evidence | Log level and change records | Controlled denial and configuration change can be correlated | Can operations explain the outcome? | Security operations |
Figure 1: An editorial planning path for attributing a call to its destination, connector and backend controls, 2026. Source: SAP, HTTP destinations; SAP, Configure accessible resources.
The matrix prevents a common scoping error: testing an HTTP endpoint through the application and calling the work a complete Cloud Connector review. A dynamic request can show the observed route and result. It does not reveal every exposed path, trust setting or alternate destination. Conversely, a configuration screenshot can show an allowlist but does not prove which application and principal use the route in practice.
Test the resource boundary precisely
SAP documents that an HTTP mapping exposes a host and port only after specific URL paths are granted as resources. It also documents a choice that can include a path and all its subpaths. That choice can be appropriate for a versioned API, but it may expose endpoints added later under the same prefix. Ask the API owner to name the required path family, then compare the configured path and subpath choice with the actual operations the application needs. SAP, Configure Access Control for HTTP
For a controlled test, choose a benign allowed request and a benign adjacent request that the owner says should be unavailable. Do not probe arbitrary internal hosts or enumerate a backend. Use a synthetic object and a request budget. Record the destination, virtual host, path, expected response class, observed response class and Cloud Connector log entry. If the adjacent request succeeds, verify whether it was reached through a broad resource prefix, another mapping or the backend's own routing before assigning cause.
SAP says the HTTP path decision is based on the path portion before a possible query string. Query parameters may still matter to the backend application's authorization and data selection, but they are not a substitute for Cloud Connector resource scoping. A buyer should make the path allowlist question separate from the backend API's own object-level and query validation tests. SAP, Configure Access Control for HTTP
Path case and redirect behavior also deserve design review. SAP's HTTP access control documentation calls path names case sensitive and discusses redirect locations that need corresponding internal-host configuration. A successful initial request can therefore cross into another route after a redirect. Include only the redirect chain required by the selected business workflow, and ask the backend owner to confirm every target. Do not treat an untested redirect destination as covered merely because the first request passed. SAP, Configure Access Control for HTTP
SAP recommends limiting access to backend services and resources explicitly required by cloud applications. The assessment should translate that into a removal decision. For every broad prefix, ask the owner whether a narrower path set would preserve the transaction. Where an application imports a packaged scenario, review the imported resources against current use rather than assuming the package remains least privilege. SAP, Configure Accessible Resources
Separate principal propagation from tunnel reachability
The connector tunnel and host mapping define a network path. They do not settle which user the backend believes is acting. SAP's principal propagation guidance says Cloud Connector does not trust a token-issuing entity by default; trusted identity providers are configured per subaccount and synchronized with the connector. The buyer should name the IdP, propagated identity, backend user mapping and business permission expected for the chosen flow. SAP, Set Up Trust
This matters for a call that appears to work only under one administrator's account. A test with an administrative principal may demonstrate the route but obscure whether ordinary users or a technical identity are mapped correctly. Use a permitted test principal and an intentionally narrower principal. Observe the backend decision for synthetic records. Record the cloud identity, connector trust entry and backend identity mapping without copying tokens or certificates into the report.
SAP says updates to an IdP configuration on the cloud side require synchronization of trusted entities in Cloud Connector. A stale trust configuration can produce a failure that looks like an application outage. The report should distinguish a failed identity validation from a denied backend authorization and from a blocked resource path. These lead to different owners and remediation steps. SAP, Set Up Trust
For HTTPS principal propagation, SAP documents a backend trust relationship and user mapping after Cloud Connector forwards the user identity. That makes the backend part of the scope if the buyer wants to conclude anything about user-level access. If the engagement stops at connector configuration, say so plainly. The assessor can confirm that propagation is configured, but cannot certify that every backend user maps to the intended authorization without exercising the backend's customer-owned control. SAP, Set Up Trust
Technical user authentication needs a separate expected-access statement. A service identity may legitimately call an internal API without a human principal, but its privileges should match the service's business job. Do not silently count a technical-user success as proof of per-user authorization. Note which identity model each destination uses and whether the backend applies its own role check.
Keep destination authentication and backend permissions distinct
SAP says the Destination service manages routing and authentication details and can perform authentication flows from its configuration. HTTP destinations support different authentication choices. The buyer should review the selected mode, connection target and secret or certificate ownership without placing sensitive material in evidence. A destination with correct credentials can still call too many backend paths; a narrow path allowlist can still deliver data to an application whose users have overly broad rights. SAP, Destination Service SAP, HTTP Destinations
Trace a synthetic transaction end to end. Capture the application action, destination used, connector mapping, allowed resource, backend user or technical identity and sanitized result. If a failure occurs, preserve the response class and the relevant audit event instead of replaying the request with stronger credentials until it succeeds. The first result may show that a boundary is working as intended.
The application may expose its own API to callers. That is a separate security boundary: a user could invoke an overly broad backend action through an application that is allowed to use the connector. A complete engagement may include the customer-built front end or API and the internal service it calls. An API penetration testing scope can cover that application behavior, while a cloud penetration testing scope addresses the BTP identity and routing configuration. Name both surfaces explicitly in the statement of work.
Audit logs as evidence, not as a substitute for tests
SAP says Cloud Connector's default Security audit level records blocked requests and critical configuration changes, including exposed backends and allowed resources. Its All level records allowed requests as well. These are different evidence options. The security team should decide the log level for the engagement, retention handling and who can export sanitized entries. A lack of allowed-request logs under the default level is not necessarily a monitoring failure; it may be the documented setting. SAP, Manage Audit Logs
For each selected denial, correlate the application request time, virtual host, resource path and connector audit entry. Where a resource or mapping was recently changed, preserve the relevant BackendMapping or AllowedResource audit category. A good report can then show what was configured, what changed and what happened under a controlled request. Avoid storing credentials, raw personal data or full production payloads in an evidence bundle.
Audit evidence is especially useful when an assessment finds an unexpected success. A path may be allowed by an older mapping that the integration team no longer remembers. A configuration export, dated change record and runtime result give the owner a route to fix it. If the logs cannot uniquely attribute the request, the report should say so and recommend a practical logging or correlation change rather than inventing certainty.
Choose a safe test envelope
The approved boundary should list BTP subaccounts, customer-owned applications, destinations, connector instances, virtual hosts, backend systems and permitted protocols. Define whether the engagement includes HTTP only or also RFC, LDAP or TCP mappings. Those protocols have different request semantics and logging. A proposal that says “test Cloud Connector” without the protocol list is too vague for an enterprise buyer.
Use a representative non-production route for state-changing requests. If production must be observed, choose read-only operations or explicitly approved synthetic records, set a request budget, agree an owner who can stop the test and document the rollback plan for any change. Exclude SAP-managed infrastructure, other tenants and provider-controlled services from dynamic testing unless separately authorized. The customer can supply configuration exports for broader review without requiring broad request generation.
Inventory review should precede any probe. Some routes may be business critical, such as financial posting or identity synchronization. Mark them review-only unless the business owner provides a safe synthetic transaction. A denied path check can be low impact, but an allowed path may invoke a backend action. The tester should know both before sending the request.
Also ask whether a Cloud Connector configuration was imported from another subaccount. SAP's access-control documentation describes copying settings and including resources during import. An imported mapping can be technically valid yet broader than the receiving subaccount needs. Compare the receiving application purpose with every imported resource. SAP, Configure Access Control
How to judge and remediate a finding
The outcome should be classified by the boundary that failed. An unintended destination target is different from a broad connector resource path. A correctly allowed path with excessive backend data is a backend authorization issue. A cloud application that exposes an approved route to unauthorized callers is an application issue. The report should identify the exact control and owner rather than labeling every result a “Cloud Connector vulnerability.”
Each finding should include the business purpose, affected destination and subaccount, virtual and internal mapping, path pattern, identity mode, controlled request, observed result and evidence limit. Prioritize by what the route can reach and which actor can invoke it. If the assessor observed only a configuration, label the risk as configuration exposure until a safe runtime check confirms impact.
Remediation can narrow a resource prefix, remove an unused mapping, correct a destination's target or proxy type, repair trust synchronization, or reduce backend privileges. A retest should repeat the original cloud actor, destination, path and synthetic record. If the owner changes only the backend authorization, verify that the connector still routes the legitimate request and that the prohibited business action now fails.
Stingrai is a global CREST-accredited penetration testing services company founded in Toronto, Canada in 2021, trusted by companies from startups to enterprises to meet audit requirements for SOC 2, ISO 27001, CMMC, PCI DSS and HIPAA. OSCE³, OSWE, OSEP, CREST CRT certified pentesters, who are also world-class security researchers and bug bounty hunters. Choose from fully human-led or hybrid (AI agents plus human penetration testers) engagements across web, API, mobile, AI and LLM, cloud, network, Active Directory and social engineering penetration tests and red team engagements.
For this scope, Stingrai's human-led testers can align the customer-owned BTP route, internal API and cloud application with the business owner's approved access model. Two named penetration testers work on each human-led engagement, with review by a team lead and engagement partner. Findings can be delivered during a one-time or annual assessment or a continuous program through the PTaaS portal, with retesting of remediated findings. The resulting evidence can support the customer's compliance program and audit preparation.
Procurement questions that make the scope reviewable
Ask each provider to list the required inputs: destination export, Cloud Connector mapping and resource inventory, subaccount list, authentication design, backend owner and a set of synthetic transactions. Require a statement of which surfaces will be dynamically tested and which will receive configuration review. Ask whether principal propagation and backend user mapping are included, since a connector-only assessment cannot answer the per-user authorization question.
Ask how the provider will preserve evidence without collecting secrets. A route record can name the destination and mapping while redacting credentials. A request record can show the operation and a synthetic object without exposing production payloads. The report should keep timestamps and correlation IDs so administrators can find the corresponding events.
For commercial comparison, count routes and boundaries rather than only destinations. One destination that reaches a broad internal API may require deeper testing than several read-only destinations with narrow resources. A network penetration testing service may be relevant when the customer-owned internal segment is explicitly in scope. Request a quote against the exact routes, protocols and allowed test methods.
FAQ
What should an SAP BTP Cloud Connector security assessment include?
It should join each destination to its proxy type, virtual host and port, internal mapping, allowed resources and authentication method. The assessment should compare approved and prohibited customer-owned requests, then identify which control produced each result.
Does an active Cloud Connector tunnel prove the backend is protected?
No. Tunnel reachability does not show whether a resource path is too broad, whether principal propagation maps the right user, or whether the backend enforces its own permissions. Those decisions need separate configuration evidence and controlled observations.
What is the difference between a destination and a Cloud Connector resource?
A destination supplies connection and authentication details for an application. A Cloud Connector resource defines a URL path allowed through a particular virtual-to-internal mapping. Both need to be reviewed for an on-premise route.
Can the assessment use production traffic?
Yes, within an approved test envelope. Prefer read-only requests and synthetic records, name the systems and identities, set a request budget and monitoring contact, and reserve state-changing operations for a representative non-production route or a separately approved window.
Related reading
Talk to Stingrai
Stingrai can scope a human-led review of the BTP destinations, Cloud Connector mappings and customer-owned backends that support your business flows. Get a Quote or book a free discovery call to map the routes and safe test cases.
