Security Guidelines

Our customers rely on us to keep their data safe. That's why we attach great importance that the Apps offered on the d.velop cloud platform meet the corresponding security standards to protect against unauthorized access and data loss.

Because you as an App Builder, are the only person who knows the logic and source code of your App, only you can ensure that your App is secure.
But we support you in this task by defining security standards and check them with you. For this check we commission an external company, which performs the penetration test of your app in the d.velop cloud.

Please keep in mind that these requirements change over time because new attack vectors arise and corresponding countermeasures are invented.
So please check at regular intervals, whether changes to your app are necessary.

Security standards

Below is a brief list of the information security requirements your organization and app must meet.
Please follow the corresponding link to get more detailed information for the requirement.

Organizational

Data protection officer
A company data protection officer has been appointed in accordance with Art. 37 GDPR.
Obligation to maintain data secrecy
All persons involved are bound by data secrecy (§ 53 BDSG (Federal Data Protection Act)).
Communication of security incidents
Security relevant events, which can have negative consequences for d.velop and its customers (e.g. suspicion of malware or information theft), are logged and immediately reported to d.velop (incidents@d-velop.de).
Retirement of employees
If employees leave the company, all accounts must be withdrawn immediately. All passwords of which the employee was aware must be changed immediately. All data and devices made available to the employee must be collected. This is documented in a security policy.
Access control
It is ensured that only authorized persons have access to relevant workstations. Access is logged.
Password protection
There is a corresponding password policy (e.g. with a maximum number of login errors and a defined complexity) and passwords are only stored securely. This is documented in a security policy.
Device security
All devices regularly receive security patches and have always up-to-date virus protection, an activated operating system firewall, activated drive encryption and a screen saver policy with password protection. This is documented in a security policy.
Spam filter
To protect against malware, a company-wide protection solution has been installed that automatically checks and, if necessary, blocks all incoming e-mails.
Separation of development and production environments
Software development and testing takes place on separate non-productive environments with separate data sets.

Application security

Restrict Redirection
Redirections that are externally controllable must be restricted to the Origin (scheme, domain and port) originally requested.
If this is not feasible for your particular business case your App must provide the means to define a whitelist.
If you don't restrict redirections it would be possible for an attacker to lure the user to an evil site e.g. by using a special crafted URL.
Respect semantics of HTTP methods
HTTP Methoden must be used according to their specified semantics.
In particular the server-side state must not be changed if Safe Methods like GET are used.
Otherwise certain security measures that we have implemented in the d.velop cloud would probably not work.
Secure transport encryption
The multitenant HTTPS endpoint must support only TLS versions 1.2 and 1.3.
Masking user input and values from other sources before display
When user input or values from other sources are displayed in the browser, without these values having previously been formatted for display in a browser, it is possible to execute any JavaScript code in the browser.
Data minimization and storage limitation
Only data that is absolutely necessary for the function of the app may be processed and stored. After processing, data that is no longer required (e.g. personal data) must be deleted immediately.
Signature of tenant header values
Before a request can be processed by an app, the signature must be verified (HTTP header "x-dv-sig-1").
Requests with invalid or missing signatures must not be processed, as it cannot be ensured that these requests originate from the Approuter.
Check for current versions of the components used
None of the components used must contain a known vulnerability with a high or critical CVSS value (>= 7.0).

Data security and operation

Data center
The data center in which the app is operated is ISO/IEC 27001 or equivalent certified.
Encryption
All persistent data is stored encrypted (at file level) or stored on encrypted storage media (e.g. drive encryption).
Firewall
Only the necessary ports (e.g. HTTPS) of the app are accessible directly from the Internet. Access to other ports (e.g. SSH for administration) is restricted to IP addresses or only accessible via VPN.
Authorization assignment
The assignment of authorizations for access to app-relevant IT systems is restrictive, person-related and documented. Users only receive the rights required for their activities.
Patch management
All app-relevant IT systems and software components used receive regular security updates.
Monitoring
The accessibility and functionality of the app is continuously monitored. Relevant events trigger alarms (e.g. in the form of e-mail notifications).
Deletion concept
In case of termination of the App by the customer, the App must respond to appropriate notifications in order to delete all stored data of the customer.
Data protection concept
Backups are created at least once a day (RPO: 24 hours). Even if the customer cancels the app, the backups are kept for 30 days. The recovery process is documented and is tested and protocoled every six months. The protocol also includes measures derived from the results. Technical measures are in place to protect backups from accidental or deliberate deletion.
Disaster recovery plan
A disaster recovery plan describes the recovery of the app if essential components fail. The deployment of the app should therefore be fully automated and/or the individual steps documented to minimize the time to recovery (RTO).

Detailed information about the corresponding requirement

Restrict redirection

Attack scenario: Unsafe redirect

In this scenario the user is redirected unnoticed (e.g. via a special crafted URL) to the attacker's site.
The user is then prompted to enter confidential information such as user name and password. Since the redirect originates from a d.velop cloud App, i.e. the clicked or entered URL which belongs to a trustworthy origin and the browser automatically follows the redirect, it looks to the user like the prompt comes from a trusted App.
After all most users don't check if the URL in the browser changes and if they are on a completely different origin when entering confidential data.
For this attack it is necessary that the attacker can directly or indirectly manipulate the target of a redirect.

Countermeasures

Redirections that are externally controllable must be restricted to the Origin (scheme, domain and port) originally requested.
If this is not feasible for your particular business case your App must provide the means to define a whitelist.

Technical implementation

If your business case must support redirects to abolute URLs you must provide the means to define a whitelist and you have to check the requests against this list.

It's sufficient to check the structure of the redirection URL if you only support relative URLs. Relative URLs always start with a forward slash / 0x2F.
However the HTTP spec defines that an URL beginning with 2 forward slashes followed by http(s):// is also a valid notation for an absolute URL.
Therefore it's not enough to check if the URL string starts with a forward slash.
Furthermore forward slashes might be URL-hex-encoded (%2F) so it isn't sufficient to check is the URL string starts with two forward slashes either.

The following absolute URLs might be characterized as relative URLs if the check is not implemented correctly:

//https://evil.com
/%2Fhttps://evil.com
%2F/https://evil.com
%2F%2Fhttps://evil.com

Respect semantics of HTTP methods

If the HTTP methods are used incorrectly, this will result in a variety of potential problems. For example HTTP proxies cache the responses to GET requests under certain circumstances so that subsequent GET requests to the same resource may no longer reach the original App.
It is obvious that this is problematic if you use GET incorrectly, to change server-side state and subsequent requests don't reach the server due to the cache.
As an App Builder, you cannot know which intermediate proxies an HTTP request passes through before it reaches your App. For example, the above proxy could be part of the customer's infrastructure. For this reason it is important to adhere to the HTTP specification.

In addition, we have implemented some basic security measures that serve as a 1st line of defense and are based on the HTTP methods being used correctly.

Basic countermeasure against CSRF

One of these security measures tackles Cross-Site Request Forgery (CSRF) attacks and is centrally implemented by the HttpGateway App.

For HTTP methods which change the server side state (POST, PUT, PATCH und DELETE) the HttpGateway App checks if the Origin Header of the request matches the invoked target origin and blocks the request with 403 Forbidden if this is not the case (cf. OWASP Cheat Sheet).

By the way, this is the reason why the Origin header has to be set programmatically if the API of an app is invoked directly, i.e. not via the browser.
However, this only applies if POST, PUT, PATCH or DELETE are used when calling the API.

Masking user input and values from other sources before display in the browser

Countermeasures

All values displayed in the browser must be masked, regardless of the source from which they originate.

The following list shows many, but not necessarily all, sources for values that must be masked:

Configurations
Databases
User input
URL parameters
Document contents
API interfaces
Web Storage

Further information can be found on the page Cross-site Scripting (XSS).

Technical implementation

Apps that render their web pages in the backend have to insert already masked values when rendering.
All common programming languages offer masking functions.
Modern frontend JavaScript frameworks usually do this automatically.
However, it must be ensured, that only the functions of the frameworks intended for this purpose are used and that no content is inserted otherwise.

Signature of tenant header values

Before a request can be processed by an app, the signature must be verified (HTTP header "x-dv-sig-1").
Requests with invalid or missing signatures must not be processed, as it cannot be ensured that these requests originate from the Approuter.

When checking the signature, you must use a function whose runtime does not allow any conclusions about the correctness of the signature. In this way, you prevent third parties from finding a valid value for a signature by varying different values and thus making requests to your app that were not sent by the Approuter.
d.velop provides examples for the use of such so-called Constant Time Compare functions. Some programming languages already contain the required secure comparison functions.
C#: https://github.com/d-velop/dvelop-sdk-cs/blob/master/dvelop-sdk-tenant/TenantMiddleware/TenantMiddleware.cs#L117
Node.js: https://github.com/d-velop/dvelop-sdk-node/blob/main/packages/app-router/src/validate-request-signature/validate-request-signature.ts#L35
Go: https://github.com/d-velop/dvelop-sdk-go/blob/master/tenant/tenantmiddleware.go#L126
Java: https://github.com/d-velop/dvelop-sdk-java/blob/master/dvelop-sdk-tenant/src/main/java/com/dvelop/sdk/tenant/validation/TenantHeaderValidator.java#L79

Technical implementation

Under the Basics for d.velop cloud apps you can find all information how to implement the signature verification.

Check for current versions of the components used

To prevent the system and users from being attacked via security vulnerabilities in the components used, no security vulnerabilities must be known for the versions of these components used.
If new security vulnerabilities become known in the components used, updated versions of the corresponding components must be used promptly.

Automated check of SBOM files

d.velop provides a Dependency-Track instance in which you can import the SBOM files of your apps. Dependency-Track checks the components of your app for known vulnerabilities. You can view the analysis results and update the corresponding components if the results are positive.
Contact your Solutions Architect at d.velop to get access to the API of the Dependency-Track instance. You can then use the Dependency-Track API to create projects, import and analyze SBOM files and view the analysis results. The projects are isolated from each other so that you can only see the projects that you have created yourself.

Dependency-Track API

To be able to use the Dependency-Track API, e.g. from your CI/CD pipeline, your Solutions Architect at d.velop creates user accounts for you and your team in Dependency-Track. The following information is required for each person in your team who shall be granted access to Dependency-Track:

Username
Display name
Email address

After your user accounts and your team have been created in Dependency-Track, you will receive one-time passwords for the first login to Dependency-Track and an API key for your team, which can be used to access the Dependency-Track API.
The Dependency-Track API is a REST API.

Apps are managed in projects in Dependency-Track.
Each project contains an overview of the components used and the results of the analysis for known vulnerabilities in the components.
If you access Dependency-Track in the browser, the URL is https://sbom.d-velop.de.
To access the API interface, the URL is https://api.sbom.d-velop.de.

The following examples show the use of the Dependency-Track API.
The Dependency-Track API offers significantly more endpoints than are described in the following examples. Only the delivery and checking of SBOM files is shown here using examples.

Create a project

Create one project per app in Dependency-Track. Multiple versions of the same app are automatically versioned within the project. Use the full name of your app as the project name, e.g. appbuildername-appname.
If you have several SBOM files for your app, e.g. if you have separated frontend and backend, extend the name (e.g. appbuildername-appname (frontend)).

Example (Create project):

PUT /api/v1/project HTTP/1.1
Accept: application/json
X-Api key: <API key>
Content-Type: application/json
Content-Length: 108

{
    "name": "appbuildername-appname",
    "version": "1.0",
    "classifier": "APPLICATION",
    "active": true
}

---

HTTP/1.1 201 Created
Content-Type: application/json
Content-Length: 162

{
    "name": "appbuildername-appname",
    "version": "1.0",
    "classifier": "APPLICATION",
    "uuid": "0f732d2b-839f-4a42-969f-f7ab1ad364e8",
    "properties": [],
    "tags": [],
    "active": true
}

The value of the object uuid is the ID of the created project and is required for subsequent requests.

Importing an SBOM file

Import an SBOM file for your app so that it can be checked by Dependency-Track.
Dependency-Track automatically starts the analysis after importing.

Example (Import SBOM file):

PUT /api/v1/bom HTTP/1.1
Accept: application/json
X-Api-Key: <API key>
Content-Type: application/json
Content-Length: ...

{
    "project": "<project ID>",
    "bom": "base64(SBOM file)"
}

---

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: ...

{
    "token":"<token>"
}

The value of the token object is the token for checking the progress of the analysis and is required for subsequent requests.

Viewing the analysis results

The components used are analyzed asynchronously for known vulnerabilities. Dependency-Track provides an endpoint that returns the status of the current analysis. After the analysis has been completed, you can view the results for the analysis of your app. You can either log in to Dependency-Track via browser and view the results or retrieve the results via API. We recommend using the API to retrieve the vulnerabilities.

Example (Query analysis status):

GET /api/v1/bom/token/{token} HTTP/1.1
Accept: application/json
X-Api-Key: <API key>

---

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: ...

{
    "processing": <boolean>
}

As long as the value of the processing object contains the value true, the imported SBOM file is still being processed. As soon as the analysis has been completed, the processing object contains the value false and you can retrieve the results of the analysis.
Dependency-Track offers various options for determining information about vulnerabilities.
We recommend the VDR format (Vulnerability Disclosure Report), as it contains information on all components and dependencies as well as on the vulnerabilities found in the project. In contrast to the API, Dependency-Track unfortunately does not provide a display in the browser as to whether the analysis has been completed.

Example (Retrieve VDR file):

GET /api/v1/bom/cyclonedx/project/{project ID}?format=json&variant=vdr HTTP/1.1
Accept: application/vnd.cyclonedx+json
X-Api-Key: <API key>

---

HTTP/1.1 200 OK
Content-Type: application/vnd.cyclonedx+json
Content-Length: ...

<VDR file>

The VDR file contains all the information required to analyze a vulnerability, e.g. the name of the affected component, the type of vulnerability, the assigned CVE number, a classification of the vulnerability according to CVSS and an explanatory text for a better understanding of the vulnerability.