Skip to Content

SAP Cloud Platform Integration (Cloud Integration) allows quite some flexibility when developing integration flows which are executed on runtime nodes of Cloud Integration. This includes for example:

  • Modifying messages
  • Connecting to external systems
  • Encrypting/decrypting messages
  • Executing custom scripts
  • Developing custom adapters
  • etc.

These tasks are part of the daily work of an integration developer.


While this flexibility is desirable to solve complex integration problems, it comes with the drawback that such functions could also be (accidentally or maliciously) misused by a developer. For example:

  • Send decrypted messages to a compromised server (which may be under control of an attacker)
  • Access credentials of the tenant
  • Crash the runtime node via misbehaving scripts


This is a generic conflict between flexibility and security and it is near impossible for the integration runtime to distinguish between intended valid usages and mis-usages. So, how do we solve this conflict?

  • SAP Cloud Platform Integration does its best to isolate tenants from each other. This is protecting different customers of Cloud Integration as well as different tenants (e.g. test vs productive) of the same customer.
    • Each tenant can configure it’s own user/role assignments thus controlling the access.
    • Integration flows are executed on tenant isolated VMs. I.e. a malicious integration flow can only access data from or impact its own tenant where the integration flow was deployed. Strong sandboxing (see isolates his VM from other VMs.
  • SAP Cloud Platform Integration protects secrets (like passwords or private keys) from external access
    • Secrets are stored encrypted
    • Secrets are not visible in UI nor downloadable
    • Secrets are not exposed via external APIs

    But note that during runtime an integration flow needs to access these secrets, so internal access from the integration flow is possible.

  • The tenant owner is responsible for deciding which content (e.g. integration flows or custom adapters) he or she is deploying in the tenant. Be aware that this content can have internal access to your tenant and you should only deploy trusted content.
    • The integration developer (and anybody with deploy permissions) is a very powerful persona.



  • Think about the actual security requirements of your tenants and be aware of the potential risks.
  • Be careful who you grant deployment permissions on your productive systems.
  • Consider having reviews of CPI content before it is deployed. Be especially aware of scripts as these have very powerful capabilities.
  • Don’t deploy content from untrusted sources.
  • Don’t share the same secret credentials between between tenants with different security levels (e.g. test tenant & productive tenant).
  • Prefer client certificate based authentication over basic authentication (In this case the private key stays in the sender system and no secret password is transmitted via network).



Integration flows offer great flexibility to integration developers which could also be misused. While SAP Cloud Platform Integration ensures strict security between different tenants, the tenant owner is responsible for security inside his own tenant and should be aware of potential risks and how to mitigate them.

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

    1. Ariel M. Bravo Ayala

      Hi Eng Swee,

      It might not be the case, but it feels like it is. Also, this confirms that in a development CPI account, there isn’t even a single secure credential. Worrisome.

      As I´ve mentioned, I’ve found that it is possible to capture the credentials of an individual consuming a CPI endpoint.




      1. Eng Swee Yeoh

        Hi Ariel


        Regarding credentials that are stored in CPI’s so-called “secure store”, to be honest I’m not too worried about it. As I mentioned in my comment on your post, from my experience in various organisations, someone with developer access to the PI/CPI system would already have a very high likelihood to know those credentials via other means. Those that need to worry would be the CPI developers storing their personal Gmail credentials (like you pointed out), if they use CPI to play around.


        As to your other concern about sniffing the details of users consuming a CPI endpoint (I’ll try to verify this), that might indeed be a little more worrisome, but only just a little. In the past with PI, a PI developer would already know the credentials of a PI system user since they have to provide it to an external system who wants to consume a PI endpoint. It’s just that now, CPI’s identity management is based on SAP Cloud Identity Management, so it is possible that an external system registers their own user directly on SAP Cloud without the CPI developer knowing those credentials. But I feel to be able to extract such details for production systems would require quite a coordinated effort – a CPI developer would need to deploy malicious code on the specific integration flows on the production tenant. Not to say that the risk is not there, but not sure what’s the likelihood of it happening. And what would a CPI developer gain with those credentials, if he/she already has more powerful access to deploy such malicious code?


        Anyway, to mitigate this, we have been enforcing certificate-based authentication for external systems consuming our CPI endpoints – this eliminates the requirement to have a P/S-user (and their credentials).



        Eng Swee


Leave a Reply