All requirements related to modifying existing features, fixing bugs, or developing new features are recorded in Jira. After implementation, a code review is performed by a developer who did not perform the original implementation. Subsequently, the change is accepted by another person and manually tested.
The SDK is regularly automatically tested using unit tests and screen tests. Builds delivered to banks on SFTP are automatically created using a Jenkins job, thus minimizing the possibility of manual error.
We use tools for static code analysis (e.g. Sonar), for detecting memory leaks and for dependency vulnerabilities scanning.
Source code is maintained in a private repository, which is only accessible to authorized personnel. All workstations have antivirus software and up-to-date OS versions.
Each user input is validated in the SDK (and subsequently validated on Dateio BE side). Errors within the SDK are processed and displayed to the user in a readable format. No parts of the code (methods, variables, line numbers, etc.) are displayed in errors. The SDK contains only the necessary code for its function.
Serious errors and security findings are prioritized for fixing. Both types are recorded, and the bank is immediately informed of their occurrence.
The SDK is regularly subjected to external penetration tests, which are primarily based on the OWASP Mobile Top 10. Findings of all severity levels, including low, are addressed, with remediation timelines based on severity. Dateio will provide results of these penetration tests upon request. We will provide the bank assistance in case it wants to conduct its own penetration testing of the SDK implementation in its banking application.
Since its creation, the SDK has undergone annual external penetration testing by different independent security teams. It has also undergone multiple additional bank-led penetration tests. Across both the annual external penetration tests and the additional bank-led assessments, the highest-severity finding was medium.
Selected excerpts from recent independent penetration test reports:
“The penetration test of the Dateio mobile SDK revealed no major security flaws when assessed against the OWASP Mobile Top 10. The SDK demonstrates a high level of security maturity, with all critical areas effectively addressed. The assessment concludes that the SDK is well protected against the most common and severe security threats, providing a secure foundation for applications using it.”
“During the test, we identified no vulnerabilities or security issues. As no security issues were found, we have no objections to production use of the application.”
If the SDK calls another application (e.g., email, maps), an "app chooser" is used instead of a specific application.
WebView is not used anywhere in the SDK. We considered its use as problematic, among other things, for security reasons.
Requests/responses are not cached in the SDK.
When implementing the SDK into banking application, banking app should already ensure following, as the SDK does not provide it further:
The SDK uses third-party libraries. List of currently used third party libraries is available here.
Before we plan upgrade to new version or add a new library, we will notify you in advance to agree on further steps and timeline.
Libraries are regularly checked for security vulnerabilities. If any such vulnerability is found, the library will be prioritized for an update to a version without the vulnerability.
The SDK only stores offer images on the device to reduce the amount of transferred data. No user identifiers (such as IDs, tokens, etc.) are stored permanently on the device or is in source code of the SDK. These identifiers are only stored in non-persistent memory after the SDK is configured.
The bank application is responsible for obtaining, storing, or modifying user identifiers or tokens.
The SDK requires minimal permissions for its functionality and uses these following permissions:
Any further permissions will be communicated and consulted before implementation into SDK.
In release build debugging is disabled. Shrinking is enabled and development logs are also disabled.
Next, check our SDK overview, or start with implementation for Android or iOS.