> For the complete documentation index, see [llms.txt](https://developer.vario-software.de/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.vario-software.de/app-store-guidelines/app-requirements/security-and-privacy-review.md).

# Security and Privacy Review

Security and privacy requirements for protecting customer data in VARIO App Store apps.

A Public App must protect VARIO customers, their users, and their data throughout the complete app lifecycle.

VARIO reviews whether the app's technical behavior, infrastructure, authentication, data processing, and external dependencies are consistent with the security and privacy information provided for the app.

{% hint style="info" %}
The contractual security and data protection obligations of the App Provider are governed by the Framework Agreement and the applicable App-Specific Agreement.

This page does not replace those obligations. It describes the practical security and privacy criteria VARIO may evaluate as part of the App Store review.
{% endhint %}

### Secure the complete app environment

Security requirements apply to the complete environment used to provide the app, not only to the code embedded in VARIO Cloud.

This includes, where applicable:

* the app frontend;
* the app backend;
* databases and storage;
* background workers;
* queues;
* administrative interfaces;
* external APIs;
* cloud infrastructure;
* deployment environments;
* monitoring and logging systems.

An otherwise secure VARIO integration is not sufficient if customer data can be accessed through an inadequately protected component of the App Provider's infrastructure.

### Use the documented VARIO authentication mechanisms

Requests between VARIO Cloud and the app must use the authentication mechanisms defined in the VARIO Developer Docs.

VARIO Cloud sends authenticated requests to an app using an `appToken`.

The app must verify authenticated inbound requests before processing them.

Where the VARIO App Framework is used, the framework provides the corresponding authentication handling.

Apps implementing authentication without the framework must provide equivalent validation.

See [App Authentication](https://developer.vario-software.de/documentation/apps/authentication) for the required implementation.

{% hint style="danger" %}
An app must not trust a request merely because it originates from a page embedded in VARIO Cloud.

Server-side actions must validate the authenticated app or user context independently.
{% endhint %}

### Protect credentials and secrets

Credentials and secrets must be stored and processed securely.

Examples include:

* VARIO `clientSecret`;
* `appJWK`;
* tenant-specific `offlineToken` values;
* external API keys;
* OAuth refresh tokens;
* database credentials;
* encryption keys;
* Webhook secrets;
* credentials for connected third-party systems.

Secrets must not be:

* embedded in frontend JavaScript;
* included in publicly accessible source files;
* exposed through URLs where avoidable;
* written to customer-facing error messages;
* stored in plain text logs;
* committed to public repositories.

Server-side secrets should be stored using an appropriate secret management mechanism such as protected environment variables, a secrets vault, or an equivalent secure storage solution.

The credentials generated when creating a VARIO App are described in [Create an App](https://developer.vario-software.de/documentation/apps/create-an-app).

### Keep tenant credentials separated

Tenant-specific credentials must be associated with the correct VARIO Cloud tenant.

An app must not:

* reuse one tenant's credentials for another tenant;
* use a global credential cache without tenant separation;
* expose credentials through frontend-controlled tenant identifiers;
* allow one installation to access another installation's connection information.

Tenant context must be derived from trusted authentication and installation information.

The general tenant isolation requirements are covered in **Permissions and Data Quality**.

### Protect administrative functionality

Administrative and configuration functionality must be protected according to its sensitivity.

Examples include:

* changing external API credentials;
* connecting or disconnecting an account;
* modifying synchronization behavior;
* changing mappings;
* starting large imports;
* deleting app data;
* managing other users' access.

An app must not rely solely on a hidden navigation item to protect such functionality.

Authorization must also be enforced when the corresponding backend operation is called directly.

### Use secure transport

App endpoints used by VARIO Cloud must use HTTPS with a valid TLS certificate.

Sensitive information must not be transmitted over unencrypted connections.

The same principle applies to communication between the app and external systems where credentials, personal data, or customer business data are transferred.

Mixed-content implementations or redirects to insecure HTTP endpoints are not acceptable for productive App Store releases.

### Validate untrusted input

Information received from users, VARIO Cloud, Webhooks, uploaded files, or external systems must be treated as untrusted input.

The app must validate data before using it in security-sensitive operations.

Depending on the implementation, this may include protection against:

* injection attacks;
* malicious file uploads;
* path manipulation;
* unsafe redirects;
* cross-site scripting;
* manipulation of identifiers;
* unsupported data types;
* unexpectedly large payloads.

Validation should take place on the server where the operation is executed.

Frontend validation may improve usability but must not be the only security control.

### Do not expose unnecessary technical information

Customer-facing responses must not disclose information that could unnecessarily assist an attacker or expose confidential information.

Avoid exposing:

* stack traces;
* internal file paths;
* database information;
* infrastructure credentials;
* complete authorization headers;
* access tokens;
* implementation secrets.

Technical information required for troubleshooting may be recorded in protected logs where appropriate.

The user-facing error should still provide enough information to understand what failed and what action can be taken next.

### Secure logging

Logs are an important operational tool but may themselves become a source of sensitive information.

Apps must avoid logging secrets such as:

* passwords;
* access tokens;
* refresh tokens;
* `offlineToken` values;
* API keys;
* authorization headers.

Customer data should only be included in logs where it is reasonably required for operation or troubleshooting.

Where request or response payloads may contain sensitive information, appropriate masking or filtering should be used.

Access to production logs must be restricted to authorized personnel.

### Separate development and production appropriately

Development tools and testing functionality must not create unnecessary security risks in the productive app.

Production deployments must not expose:

* development consoles;
* debug endpoints;
* test authentication methods;
* internal administration interfaces without protection;
* sample credentials;
* unnecessary diagnostic information.

Test and development credentials must not be used for productive customer installations.

Where separate environments are used, their data and credentials must also be separated appropriately.

### Keep dependencies maintained

Apps often depend on third-party libraries, frameworks, containers, operating system packages, or external services.

The App Provider must maintain these dependencies appropriately.

Apps submitted for review must not knowingly rely on components with unresolved vulnerabilities that create an unacceptable risk for VARIO customers.

The App Provider should have a process for:

* identifying vulnerable dependencies;
* evaluating relevant security advisories;
* applying security updates;
* replacing unsupported components where necessary.

The presence of a dependency alone is not a review issue. Its security relevance and the way it is maintained are what matter.

### Avoid unsupported software components

Production environments should not rely on software versions that no longer receive security updates where this creates a relevant security risk.

If an app depends on an unsupported component for technical reasons, VARIO may require an explanation or remediation before approving the app.

### Limit externally reachable functionality

Only endpoints and services required for the app should be publicly reachable.

Internal administration, database, debugging, monitoring, or infrastructure services should not be exposed directly to the public internet unless this is required and appropriately protected.

The app should follow common infrastructure security practices such as:

* restricting administrative access;
* limiting network exposure;
* protecting management interfaces;
* applying appropriate authentication;
* keeping infrastructure configuration up to date.

### Privacy information must match actual processing

The app's actual data processing must be consistent with the privacy information provided for the app.

In particular, the review may compare the app's behavior with the information contained in the applicable App-Specific Agreement and its app-specific privacy information.

The information should accurately reflect:

* which categories of VARIO data the app processes;
* why the data is processed;
* which external systems receive data;
* which service providers or subprocessors are involved where applicable;
* where relevant data is stored or processed;
* how long data is retained where this is relevant to the service.

{% hint style="warning" %}
An app must not process materially different customer data simply because the requested VARIO permissions technically make that data accessible.

The actual processing must correspond to the documented app purpose and the information provided for the app.
{% endhint %}

### Do not collect data without a functional purpose

The app should process only information required for its documented functionality.

For example, an app should not copy complete customer, article, document, or transaction datasets to its own infrastructure when only a limited subset is required for the intended process.

The technical permission and data minimization requirements are further described in **Permissions and Data Quality**.

### Be transparent about external services

If customer data is sent to another service as part of the app's functionality, this must not be hidden from VARIO or the customer.

Examples may include:

* marketplaces;
* shipping providers;
* payment providers;
* AI services;
* analytics services;
* communication platforms;
* accounting systems;
* cloud processing services.

The app's review materials and privacy information must represent the actual technical architecture.

An external service must not be introduced into customer data processing without updating the applicable information where required.

### Handle personal data intentionally

If the app processes personal data from VARIO Cloud, that processing must be connected to a defined app function.

The app should avoid unnecessarily copying or retaining personal data outside VARIO Cloud.

Where possible, data that is no longer required for the app's purpose should not be retained indefinitely.

The applicable contractual and privacy documentation determines the specific obligations for the respective app.

### Define data retention behavior

Where the app stores customer data outside VARIO Cloud, the App Provider must understand what happens to that data when:

* a record is deleted or changed in VARIO;
* an external account is disconnected;
* the app is uninstalled;
* the commercial relationship ends.

The behavior does not need to be identical for every type of data.

For example, operational records may need to be retained for legitimate or contractual reasons while credentials should no longer remain usable after an installation has ended.

The important requirement for review is that the behavior is intentional, technically controlled, and consistent with the applicable documentation.

### Uninstallation must stop unauthorized future access

After an app has been uninstalled, it must no longer use credentials or processes associated with that installation to access the customer's VARIO Cloud tenant.

Where applicable, uninstallation must ensure that:

* tenant-specific authentication credentials are no longer used;
* automated synchronization stops;
* background jobs stop;
* Webhook processing stops;
* external connections associated solely with the installation are handled appropriately.

The technical lifecycle requirements are covered in **Technical Integration and App Lifecycle**.

### Use production data carefully during review and testing

The App Provider should be able to provide VARIO with a suitable test environment and test data for review.

Real customer production data should not be required merely to demonstrate ordinary app functionality.

If a specific review scenario genuinely requires production-like data, the amount of data used should be limited to what is necessary for that scenario.

Test credentials supplied to VARIO must not provide unnecessary access to unrelated production systems or customer accounts.

### Security-relevant configuration must have safe behavior

Configuration options that materially affect security or data access must not default to unnecessarily risky behavior.

Examples may include:

* making information publicly accessible;
* transferring additional data categories;
* disabling verification;
* automatically executing destructive actions;
* allowing unrestricted administrative access.

Where a security-relevant option is required, its effect should be understandable to the administrator configuring the app.

### Security issues identified during review

If VARIO identifies a security issue during App Store review, the issue must be resolved or otherwise accepted by VARIO before publication.

The required response depends on the severity and potential impact.

VARIO may request:

* a technical explanation;
* a corrected app version;
* evidence of the implemented control;
* additional testing;
* further information about the affected infrastructure or data processing.

{% hint style="danger" %}
A critical vulnerability that could allow unauthorized access to customer data, cross-tenant access, credential compromise, or unauthorized modification of VARIO business data will prevent publication until the issue has been resolved.
{% endhint %}

### Security review depth

Not every app requires the same depth of security review.

VARIO may perform a more detailed review where an app:

* accesses sensitive or extensive customer data;
* modifies financially or operationally important business data;
* processes payments or other high-impact transactions;
* provides privileged administrative functionality;
* operates across multiple external systems;
* has a particularly broad permission scope;
* introduces other material security risks.

Depending on the app, VARIO may request additional technical information or evidence before approval.

### Information VARIO may request

To understand the security and privacy architecture of an app, VARIO may request information such as:

* a high-level architecture description;
* relevant data flows;
* authentication mechanisms;
* requested permissions and their purpose;
* storage locations for customer data;
* handling of secrets and credentials;
* external services involved in processing;
* relevant security controls;
* information about security testing;
* explanations of significant findings and their remediation.

The level of detail requested will depend on the functionality and risk profile of the app.

### What VARIO reviews

During the security and privacy review, VARIO may verify in particular whether:

* VARIO authentication mechanisms are implemented correctly;
* authenticated backend operations cannot be bypassed through the frontend;
* credentials and secrets are stored securely;
* tenant-specific credentials and data are separated;
* administrative functions are appropriately protected;
* sensitive communication uses encrypted transport;
* untrusted input is handled securely;
* technical errors and logs do not expose secrets;
* production deployments do not expose development functionality;
* relevant dependencies are maintained;
* externally reachable services are appropriately limited;
* the app's actual data processing matches its documented purpose;
* external services involved in processing are represented accurately;
* unnecessary data collection or retention is avoided;
* uninstallation stops further access for the affected installation;
* identified security issues have been resolved before publication.

VARIO may request additional security or privacy information where the functionality or risk profile of the app makes this necessary.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://developer.vario-software.de/app-store-guidelines/app-requirements/security-and-privacy-review.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.