> 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/classic-push-provisioning/developer-guide/security-guidelines/general.md). # General The following list shows general security requirements your application must follow. ### Use Release Variant of Thales SDK for Publishing Applications Before publishing to the Apple App Store or Google Play, ensure the application uses the release variant of the SDK. > > > #### Warning > > Utilizing a debug SDK variant in a production application can lead to serious security implications, potentially exposing sensitive data related to end users. ### Removal of Debug Symbols 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 Careful life cycle management is required to prevent sensitive data leaks while the application is in the background. Remove any sensitive data from the UI before backgrounding. Wipe or encrypt sensitive data until the application returns to the foreground. Avoid logging sensitive data. ### Code Obfuscation To enhance the difficulty of reverse engineering the application: * For Android applications, use sufficient obfuscation to conceal class names, function names, and public APIs of the Thales SDK. Also obfuscate sensitive strings used within the application. * For iOS applications, obfuscation is recommended, but not mandatory, due to less mature tooling in this area. ### Network Communication It is strongly recommended that the application uses HTTPS for all network communication with its servers. Avoid self-signed certificates. Use these 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 SHA-256 hash of the root CA or leaf certificate matches the hardcoded hash within the application. For confidential data containing personally identifiable information (PII), use an additional layer of encryption and authentication when sending data over TLS. ### RASP Protection It is highly recommended that the application uses commercial tools for Runtime Application Self Protection ([RASP](https://en.wikipedia.org/wiki/Runtime_application_self-protection)). This helps detect rooting or jailbreaking, hooking attempts, debugging, application tampering, and emulator usage. ### Limit Log Usage Be careful when writing on-device logs. Logs can provide useful information to attackers. Avoid logging critical information such as PII or other sensitive end user data. Remove logs in production builds by using obfuscation tools or conditional logging flags. On Android, logs are a shared resource accessible with the `READ_LOGS` permission. Inappropriate logging of sensitive end user data can lead to unintended leaks to other applications. ### 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 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 The OWASP Mobile Application Security Verification Standard ([MASVS](https://github.com/OWASP/owasp-masvs)) establishes 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 posture 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/classic-push-provisioning/developer-guide/security-guidelines/general.md?ask=&goal= ``` `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.