A 2019 security assessment reported code-level weaknesses in mobile financial-service apps after researchers decompiled the applications for inspection. The findings varied by category: retail-banking apps had the most critical vulnerabilities, while auto-insurance apps had the most severe findings and the most hard-coded keys and secrets. The account describes a historical sample—not the current security of any named bank, insurer or app.
What the 2019 assessment examined
Dark Reading published Curtis Franklin’s summary on April 2, 2019. It reported on research commissioned by Arxan and conducted by Aite Group. Aite researcher Alissa Knight reportedly decompiled the examined apps to recover their underlying code for vulnerability assessment.
Decompilation lets a tester inspect an application’s compiled logic, configuration and embedded data. In this case, the article presented code inspection as a way to identify weaknesses that an attacker could also look for. It discussed app shielding as a defense intended to make that inspection and subsequent tampering more difficult.
The accessible article does not name individual applications. It also does not provide the sample size, app-selection criteria, numerical vulnerability counts, percentages, scoring system or complete methodology from the underlying report.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →#1 Best Overall
Findings differed by financial-service category
| App category | Finding reported in the 2019 summary | What is not established |
|---|---|---|
| Retail banking | Reportedly had the greatest number of critical vulnerabilities in the assessment. | No numerical count, app list or current-version assessment is given. |
| Auto insurance | Reportedly had the greatest number of severe findings and the most hard-coded private keys, API keys and other secrets. | The summary does not identify insurers, versions, counts or exploitability for a particular app. |
| Banks offering and servicing health savings accounts | Described as the most secure group in the article’s account of the report. | No score, ranking formula or sample details are supplied. |
| Health-insurer mobile payment apps | Placed behind HSA bank apps in the reported relative ranking. | The article gives no quantitative comparison. |
| Credit-card issuers | Placed after health-insurer payment apps in the reported relative ranking. | The summary does not establish how many apps were assessed or how ranks were calculated. |
The distinction between “critical” findings in retail banking and “severe” findings in auto insurance matters. Those are category-level descriptions from the article, not proof that one named financial institution was less safe than another.
Weakness patterns found in code
Hard-coded credentials and secrets
The article says auto-insurance apps contained the most hard-coded private keys, API keys and secrets. Values embedded in an application can be extracted from a package or discovered through reverse engineering. If they grant access to backend services, certificates or signing systems, their exposure can extend beyond a single device.
Rank #2
Embedded SQL statements
Hard-coded SQL statements were described as common across sectors. Putting database logic directly in a client can reveal implementation details and, if inputs are handled poorly, increase the consequences of tampering or injection. The summary does not say that every cited statement was exploitable.
Private certificates
Private certificates were also described as common code weaknesses. A private key or certificate material that should remain under server-side control is not protected merely because it is inside a mobile package; an analyst with the package can attempt to extract it.
Rank #3
Why decompilation is relevant to app security
Mobile packages are distributed to user-controlled devices. Attackers can copy an installed package, run static-analysis tools, observe behavior and modify code. Obfuscation, runtime defenses and app-shielding controls can raise the cost of that work, but they do not turn client code into a trusted secret store.
The 2019 article’s practical message was to address these risks during development and DevOps rather than treating security as a final release check. Server-side authorization, short-lived credentials, careful certificate handling and removal of unnecessary secrets reduce what an extracted package can disclose or do.
What the article does—and does not—say about today’s apps
- It is an account of research produced in 2019 and summarized on April 2, 2019.
- It names app categories, not specific banking or insurance applications.
- It supplies no present-day retest, version information, numerical results or reproducible scoring details.
- It therefore cannot support a current safety ranking or a claim that a particular app is vulnerable now.
App code, backend controls, operating systems and development practices can all change. A current risk judgment requires a fresh assessment of the specific app version and its services.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How security leaders described the problem
The summary quoted Timur Kovalev, identified as chief technology officer at Untangle:
Recommended Free Tools
“Mobile apps in general lack the necessary security features to protect users data. Even with social engineering and mobile breaches occurring more often, app developers still are not developing apps with security in mind,”
Nathan Wenzler, identified as senior director of cybersecurity at Moss Adams, said:
“While users are comfortable using mobile apps for nearly anything and everything these days, the concerns for securing their money and financial information can make nearly anyone a little hesitant. And maybe with good reason,”
Wenzler also emphasized the development process:
“Making application security an integral part of the development and DevOps processes is critical to creating confidence within the customer base that their money and information is secure, no matter how they choose to manage their banking tasks,”
Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
Practical interpretation for organizations
- Keep API credentials, private keys and other high-value secrets out of distributed client packages.
- Review compiled releases, not only source repositories, because build steps can reintroduce sensitive material.
- Use code inspection, runtime testing and tamper-resistance measures as parts of the secure development lifecycle.
- Assume that anything shipped to a customer device can eventually be inspected, and enforce decisive authorization on the server.
- Document severity definitions and sample details so category comparisons can be independently understood.
These are security-engineering implications of the issues discussed in the 2019 account, not the result of a new independent audit.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
