> For the complete documentation index, see [llms.txt](https://docs.payments.thalescloud.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.payments.thalescloud.io/merchant-tokenization/sdk-integration/security/general.md).

# General

The following list shows the general security requirements the application must follow.

## Use Release Variant of Thales SDK for Publishing Applications <a href="#use-release-variant-of-thales-sdk-for-publishing-applications" id="use-release-variant-of-thales-sdk-for-publishing-applications"></a>

Prior to publishing the application to iOS App Store and Google Play Store, ensure that the application is configured to use the release variant of the SDK.

{% hint style="danger" %}
Usage of a debug SDK variant in a production application can lead to serious security implications, potentially exposing sensitive data related to end users.
{% endhint %}

## Removal of Debug Symbols <a href="#removal-of-debug-symbols" id="removal-of-debug-symbols"></a>

The application must not contain any debug symbols. This practice increases the complexity of reverse engineering efforts and prevents the easy identification of sensitive variables, structures, and logic.

## Prevention of Sensitive Data Leaks <a href="#prevention-of-sensitive-data-leaks" id="prevention-of-sensitive-data-leaks"></a>

Careful life-cycle management of the application is necessary to prevent sensitive data from being leaked while in the background. It is advisable to remove any sensitive data displayed in the UI before moving to a background state. All sensitive data should be wiped or encrypted until the application is restored to the foreground. Logging of any sensitive data should be avoided.

## Code Obfuscation <a href="#code-obfuscation" id="code-obfuscation"></a>

To enhance the difficulty of reverse engineering the application:

* For Android applications, they must undergo sufficient obfuscation to conceal class names, function names, and public APIs of Thales SDK. Additionally, sensitive strings used within the application should be obfuscated.
* For iOS applications, obfuscation is recommended, but not mandatory, due to less mature tooling in this area.

## Network Communication <a href="#network-communication" id="network-communication"></a>

It is strongly recommended that application uses HTTPS for all network communications with their servers. Self-signed certificates should be avoided. These are the recommended guidelines for certificate pinning:

* Ensure the hostname matches the Subject name of the leaf certificate.
* Verify that each certificate in the certificate chain is not expired.
* Verify that the chain of trust is valid and the certificate chain is validated with the system trust store.
* Verify that the SHA256 of the root CA or leaf certificate hash matches the hardcoded hash within the application.

For confidential data containing personally identifiable information (PII), an additional layer of encryption and authentication mechanisms are employed when sending the data over TLS.

## RASP Protection <a href="#rasp-protection" id="rasp-protection"></a>

It is highly recommended that application utilizes commercial tools to enable Runtime Application Self Protection [RASP](https://en.wikipedia.org/wiki/Runtime_application_self-protection). This will help to detect root or jailbreak detection, hooking attempts at the application, debugging, application tampering and emulator detection.

## Limit Log Usage <a href="#limit-log-usage" id="limit-log-usage"></a>

Caution must be exercised when printing on-device logs as they can provide useful information to attackers. Avoid revealing critical information in logs such as PII or any user sensitive information, to prevent attackers from exploiting them. Removing logs from the mobile application can be achieved through various methods such as using obfuscation tools or conditionally encapsulating logs with build flags to ensure they are excluded in production builds.

On Android, logs are a shared resource that are accessible with the `READ_LOGS` permission, and inappropriate logging of user sensitive information can lead to unintended data leaks to other application.

## Adoption of Secure Coding Practices <a href="#adoption-of-secure-coding-practices" id="adoption-of-secure-coding-practices"></a>

Follow established secure coding practices such as input validation, proper memory management, use of secure C functions, and avoiding the use of immutable containers for storing sensitive data. It is recommended to refer to the [OWASP Secure Coding Practices Quick Reference Guide](https://owasp.org/www-project-secure-coding-practices-quick-reference-guide) for more details. These practices can be enforced using static code analysis tools such as PMD or HP Fortify.

## Audits and Penetration Testing <a href="#audits-and-penetration-testing" id="audits-and-penetration-testing"></a>

Conduct architecture and source code audits to thoroughly evaluate the security of the application. Additionally, perform a penetration test to simulate attacks on the application and device, as well as other system layers. This will aid in identifying vulnerabilities and assessing the overall security posture of the application.

## Evaluate the Resilience of Application Security <a href="#evaluate-the-resilience-of-application-security" id="evaluate-the-resilience-of-application-security"></a>

The OWASP Mobile application Security Verification Standard [MASVS](https://github.com/OWASP/owasp-masvs) establishes the baseline security requirements for mobile applications. It is highly recommended to use this [checklist](https://github.com/OWASP/owasp-mastg/releases/latest) to evaluate the security stature of your application.


---

# 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://docs.payments.thalescloud.io/merchant-tokenization/sdk-integration/security/general.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.