> 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/pin-management/integrate-d1-sdk/deployment/security-guidelines/general-security-guidelines.md). # General security guidelines The following list shows the general security requirements the issuer application must follow. ### Use release variant of D1 SDK for publishing applications Prior to publishing the issuer application to iOS App Store and Google Play Store, ensure that the issuer application is configured to use the release variant of the D1 SDK. {% hint style="warning" %} Utilizing a debug SDK variant in a production issuer application can lead to serious security implications, potentially exposing sensitive data related to end user. {% endhint %} ### Removal of debug symbols The issuer 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 Careful Life Cycle Management (LCM) of the issuer 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 issuer application is restored to the foreground. Logging of any sensitive data should be avoided. ### Code obfuscation To enhance the difficulty of reverse engineering the issuer application: * For Android applications, they must undergo sufficient obfuscation to conceal class names, function names, and public APIs of D1 SDK. Additionally, sensitive strings used within the issuer application should be obfuscated. * For iOS applications, obfuscation is recommended, but not mandatory, due to less mature tooling in this area. ### Network communication It is strongly recommended that issuer application uses HTTPS for all network communications with issuer backend. 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 issuer 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 It is highly recommended that issuer 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 issuer application, debugging, application tampering and emulator detection. ### Limit log usage 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 end user sensitive information, to prevent attackers from exploiting them. Removing logs from the issuer 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 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 Conduct architecture and source code audits to thoroughly evaluate the security of the issuer application. Additionally, perform a penetration test to simulate attacks on the issuer application and device, as well as other system layers. This will aid in identifying vulnerabilities and assessing the overall security posture of the issuer application. ### Evaluate the resilience of application security 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 issuer 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: ``` GET https://docs.payments.thalescloud.io/pin-management/integrate-d1-sdk/deployment/security-guidelines/general-security-guidelines.md?ask= ``` The question should be specific, self-contained, and written in natural language. 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.