Can we just obfuscate the app and call it secure?

Obfuscation raises the effort needed to read your code, and it does not change what a determined person can eventually see. Keys shipped in the binary stay extractable, and client-side checks can be patched out on a device the user controls. We use obfuscation as one layer and move the real decisions to the backend, where the client cannot reach them.

Will the audit need production credentials?

We work against a staging environment wherever one exists, with test accounts and test payment keys. If a finding only appears in production, we ask for scoped access with a short expiry rather than a permanent administrator account. Any credential you share is treated as exposed at the end of the engagement and rotated by us or by your team.

We built the app quickly with AI coding tools. Is that a problem?

It changes what we look for. Fast AI-assisted builds most often ship API keys and service tokens inside the bundle, expose backend endpoints that accept any request, and skip server-side permission checks because the screen already hid the button. None of that is a judgement on how the app was made, and all of it is fixable.

Does certificate pinning stop all interception?

Pinning stops the ordinary case where someone installs a proxy certificate and reads traffic, and it raises the bar for network-level attacks. On a rooted or jailbroken device an attacker can hook the pinning check itself, so pinning buys time rather than certainty. The backend still has to treat every request as untrusted.

What do we actually receive at the end?

A written report with each finding, its severity, the file or endpoint involved, the reproduction steps, and a recommended fix. We score findings by what an attacker can reach remotely and without authentication first. The report includes a prioritised remediation plan, and we can implement the fixes as a follow-on phase.

Mobile App Security Audit & Hardening

Mobile app security audits and hardening: insecure storage, exposed API keys, weak tokens, pinning, tampering, and fixes prioritised by risk.

See our work:

Voice VPN - Fast VPN. Vasilkoff Ltd in-house project→ONLINEPAY WALLET→COINAGE WALLET→

A user joins a cafe network, and an interception proxy sits between their phone and your API. A researcher downloads your APK from a mirror, unpacks it in an afternoon, and finds a production payment key sitting in a string constant. Someone with a rooted Android device rewrites the price in a checkout payload and sends it again.

An app ships with everything it needs to reach your backend, which means anything in the bundle is available to whoever downloads it. Encryption on the device, obfuscation, and hidden checks raise the cost of tampering, and they all run on hardware the attacker controls. The real gate is your server deciding what a request may do, regardless of what the client claims about itself.

What the audit looks for

The work is a structured review of the app, its traffic, and the API it talks to. We test on real devices, including a rooted Android build and a jailbroken iOS build, and we read the compiled artifacts rather than only the source.

Local storage is where a lot of findings sit: session tokens in plain preferences, cached personal data left behind after logout, sensitive screens saved to the gallery, and clipboard copies that outlive their purpose.

Hardcoded secrets come next: API keys, service tokens, signing keys, and third-party SDK secrets in the bundle, in a config file, or in a commit someone assumed was private. A key inside an app is public the moment the app is published.

Authentication and token handling covers how sessions are issued, stored, refreshed, and revoked. Tokens that never expire, logout that clears the screen but leaves the session alive on the server, and password reset flows that reveal whether an account exists.

Transport and pinning checks whether the app accepts any certificate, falls back to cleartext for some hosts, and implements certificate pinning correctly. We also watch what it sends: fields that leak more than the screen shows, and errors that return stack traces.

Reverse engineering and tampering looks at what a modified build can do: debug flags left on, root and jailbreak detection that misses hooked builds, integrity checks a patched app satisfies, and business rules enforced only on the client.

Permissions and platform settings cover what the app asks for and whether it needs it: broad storage access, background location, camera permission at first launch, exported Android components other apps can call, and deep links that accept unvalidated input.

Unauthorised API access ties it together. We replay a valid token against endpoints it should not reach, call endpoints without a token at all, change an object identifier to read another user's record, and check whether the server enforces the rules the app pretends to enforce.

Who this is for

Teams preparing for a store release or an enterprise security review. Founders who built a first version quickly and want an honest picture before more users arrive. Fintech, wallet, VPN, and health products where a leak carries regulatory consequences. Companies taking over an app from another developer with no security documentation.

What the report contains

Each finding gets a severity, the file, screen, or endpoint involved, the reproduction steps on a real device, and the recommended fix. We separate what an attacker can do remotely without an account from what needs a valid account, and from what needs physical access to a device that is already open. That order drives the fix list, because a remote unauthenticated issue is worth more attention than a local one.

The report states what we could not test and why, so a gap is not read as a pass.

Where the project starts

The emphasis changes with the starting point.

A plain idea with nothing built yet turns the audit into a design review. We look at the planned architecture, the data the app will hold, and the flows where money or identity move, then write the security requirements the build has to meet. It is the cheapest moment to get authentication, storage, and role checks right.

An existing conventional codebase built by a team usually has structure we can trust. The review then focuses on the specific areas that cause incidents: how tokens are stored, whether the backend re-checks permissions on every call, and what the app leaves in logs and crash reports.

An AI or vibe-coded prototype compresses the usual timeline and the usual mistakes. Keys end up in the bundle, backend endpoints accept whatever the app sends, and screens enforce rules that the API does not. We treat the prototype as a working spec, keep what it proves about the product, and harden the parts that would leak data or revenue.

How the engagement runs

We start with a scoping call and a checklist of what you can share: a test build, a staging URL, test accounts, and any API documentation. Then we work through static review of the artifacts and dynamic testing on devices, keeping a running list of findings with evidence as we go.

You get a written update at the end of each phase. Findings that expose live customer data or payment credentials are reported the day we confirm them, before the report is finished, so you can decide on a hotfix without waiting for the document.

The remediation phase is optional and often worth taking. We fix in the order the report sets, ship the changes through your release process, and re-test each finding to confirm it is closed. Where a fix belongs on the server, it goes into the API rather than into a new client check.

What it costs

Mobile security work starts at our flat rate of $39 per hour, and scope is easier to describe in phases than in invented figures. A release-readiness review of a small app with a modest API is a short engagement. A wallet, a VPN, or a health app with native integrations, payments, and a large API surface takes longer, because testing every role and every endpoint is the slow part. Remediation is quoted separately from testing, so the audit stays a bounded piece of work.

For teams building the product rather than auditing it, the pricing page lists a mobile MVP typical order of $4,800 to $8,500 across four to six weeks, and a monthly capacity plan from $2,699 for a standing queue of development and security work.

Proof

OnlinePay Wallet was a native iOS and Android wallet for an enterprise payments company, built with biometric login, PIN fallback, encrypted local storage, OAuth2 and JWT on the API, KYC verification, and audit logging across multiple jurisdictions. It shows we can build and review to a standard set by regulators and auditors.

Voice VPN is our own Flutter product for restricted networks, with no accounts, no traffic logs, native VPN integrations on both platforms, and backend nodes that rotate when they are blocked. It shows we treat the client as untrusted by design and put resilience and access control in the infrastructure, which is the same posture a security audit pushes clients toward.

Coinage Wallet is an exchange platform built on the Peatio foundation, where we handled the security-focused implementation around balances, transactions, and client branding. It shows we know where an open-source base ends and where the engineering that protects funds has to start.

Related services

Mobile app development for the builds these audits are run against, native or Flutter, from first version to release
Website security audit and malware removal when the web side of the same product needs review, including leaked credentials and exposed admin access
Mobile app privacy compliance for the store declarations, consent flows, and data handling rules that sit alongside technical security
Vibe-coded mobile app rescue when a fast AI-assisted build needs hardening without discarding the product work that already exists
Secure AI backend and API proxy for moving model keys and provider calls behind a server that the app cannot read

Next step

Send us the app build, the platform it targets, and what worries you most, whether that is payments, user data, or store review. We will say what the first phase covers and what it would take.

Contact us with a link to the build or repository, or run the scope through the Vasilkoff.info estimator for a first estimate before you speak to anyone.