Application security for your industry

Superapps application security

Otukan protects superapps where one login opens payments, mobility, commerce and partner mini-apps, and gives each service backend evidence it can trust.

  • Android
  • iOS
  • Flutter
  • React Native
  • One host, many services

    Otukan protects the host app that every service depends on, so payments, rides, orders and messaging all start from a trusted client.

  • Policy per service

    Each service sets its own response. A wallet can restrict on a compromised device while browsing and chat stay open.

  • Shared evidence, separate decisions

    Attestation and integrity results reach every service backend, and each team decides what to do with them.

How Otukan handles superapp threats

Pick a threat to see what Otukan detects, how the host app responds and what each service receives.

Account takeover

  1. Detect

    Otukan flags new app instances, unbound devices and remote access when a session signs in or recovers access.

  2. Respond

    Wallet and payment services step up while low-risk services continue.

  3. Report

    Binding and session context reach the shared identity service.

Incentive farming

  1. Detect

    Emulator, automation and multi-instance signals link registrations coming from farms.

  2. Respond

    Bonuses and cashback are withheld pending review, per each service's rules.

  3. Report

    Farm indicators go to the growth and fraud teams of every affected service.

Cloned superapp

  1. Detect

    Integrity checks notice foreign signing certificates and modified code; attestation proves the result to your servers.

  2. Respond

    Service backends refuse requests that carry no valid attestation.

  3. Report

    Attestation outcome is available to every service behind the host.

Hooked host app

  1. Detect

    Runtime checks detect hooking, debugging, emulators, root and jailbreak in the host process.

  2. Respond

    Observe, warn, restrict or terminate, chosen by each service for its own screens.

  3. Report

    Integrity status travels with each service call, including mini-app requests.

Traffic interception

  1. Detect

    Certificate pinning detects connections that present certificates the host does not trust.

  2. Respond

    The call is refused before any service data is sent.

  3. Report

    Pinning failures are logged centrally for the security team.

Superapp threats and the Otukan controls that meet them

Each card matches a risk that grows with a superapp's reach to the Otukan control that addresses it.

  • One takeover, every service

    Takeover signals at login, recovery and new device sign-in protect the single identity that unlocks wallet, orders and saved addresses.

  • Mass sign-up for incentives

    Onboarding evidence exposes emulator farms and scripted registrations chasing sign-up bonuses and cashback across services.

  • Clients posing as the host

    Attestation verified by each service backend separates the genuine superapp from cloned clients and scripts.

  • Hooked host runtime

    Runtime checks detect hooking and debugging of the host app, which would otherwise undermine every mini-app it runs.

  • Embedded partner code

    SDK protection keeps the environment for embedded partner components intact and checks it has not been altered.

  • Intercepted service calls

    Certificate pinning refuses connections to your service endpoints that present certificates the host does not expect.

How Otukan works with a superapp team

  1. Inventory the services

    We list every service and mini-app, who owns it and which backend trusts its requests.

  2. Protect the host

    Host hardening runs through your existing build and release pipeline, and signing keys remain yours.

  3. Share the evidence

    Attestation and integrity results are made available to each service backend through the host.

  4. Set service policies

    Each service team chooses its own responses, tested first in observe mode.

  5. Retest on change

    New mini-apps and partner updates trigger a retest of the protected host build.

Free for app publishers

Check your app's exposure

A passive review of your published app by an Otukan engineer. No files, no access to your systems. Findings go by email to the verified publisher.

You finish the request on the next page.

Superapps application security comes down to two questions: can the one app everything runs through be trusted, and can each service behind it verify that for itself? Otukan protects the host app with obfuscation, integrity and runtime checks. It defends the single login that unlocks wallet, rides, orders and messaging, exposes incentive farming across services, and passes attestation and integrity evidence to every service backend. Each service team then sets its own response, so a strict wallet policy does not shut down chat. Mini-app code stays with its owners. Scope is documented for Android and for iOS separately, control by control.

Flows and trust boundaries in a superapp

A superapp concentrates risk in a way single-purpose apps do not. One account and one host binary sit in front of many services, each with its own backend and its own idea of what is sensitive.

FlowTrust boundaryWhy it matters in a superappOtukan evidence
Sign-in and recoveryShared identity serviceOne takeover exposes every service at onceDevice binding, takeover signals, attestation
Registration and incentivesGrowth and onboarding servicesBonuses across services reward farmingOnboarding evidence, automation signals
Wallet and paymentsPayment backendStored value and saved cards sit next to low-risk featuresRuntime integrity, attestation, device binding
Mini-app requestsEach partner or service backendPartner code runs inside your host with your users’ sessionIntegrity status passed through the host
Service trafficYour API endpointsMany endpoints, many teams, one network pathCertificate pinning

The shared identity is the highest-value target. Whoever holds it holds every service. Incentive farming comes next: when several services each run their own sign-up bonus, one farmed account can collect all of them. For the takeover chain, see mobile account takeover prevention.

Control fit: app, operating system and backend

The host app, protected by Otukan

Otukan protects the binary every service depends on. It obfuscates code, checks integrity while the app runs, and detects hooking, debugging, emulators, root and jailbreak in the host process. Because mini-apps run inside that process, a trusted host is the precondition for trusting anything they report. Otukan also keeps the environment for embedded partner components intact.

The operating system

Android and iOS supply the building blocks, and they differ. Play Integrity gives verdicts on the app, the device and the installing account. App Attest proves that a key belongs to a genuine instance of your app on an Apple device. Keys used for device binding live in the Android Keystore and the iOS Keychain. Otukan uses each platform on its own terms. How the server verifies that proof is covered on app attestation.

Service backends

This is where a superapp differs most. Otukan makes attestation and integrity results available to every service behind the host, and each backend verifies them independently. The payments team, the mobility team and a partner mini-app can each apply their own rules to the same evidence. For registration abuse, see KYC fraud prevention.

Evaluating superapp security

Supported platforms

Ask for scope per control on Android and on iOS, and for how the host framework is handled. Otukan documents each platform separately and protects hosts built natively or with Flutter and React Native. Mini-app runtimes and web views inside the host are scoped with you during onboarding.

Evidence each service can use

A signal is useful only when the right team reads it. Otukan agrees with the platform team and each service team which result reaches which backend, what a failure means for that service, and who responds.

User impact across services

Superapp users switch between services within a single session. Otukan starts every signal in observe mode and measures, service by service, how often it would fire on genuine users. Responses then apply only to the screens that need them, so a restriction on transfers does not lock someone out of a ride home. Policy changes take effect without a new store release, which matters when many teams share one release train.

The underlying Otukan product is described on mobile app security. A superapp already published in the stores can have a free App Exposure Check run on its public release.

Common questions

  • Does Otukan protect the mini-apps themselves?

    Otukan protects the host app that loads and runs them, and checks that the environment they run in has not been hooked or altered. Mini-app code delivered by partners remains the partner's responsibility, reviewed through your own onboarding process. What Otukan adds is evidence each mini-app's backend can check: that the request came through your genuine, unmodified host.

  • How do we stop one service's security rules from breaking the others?

    Responses in Otukan are scoped. A restriction on a compromised device can apply to wallet transfers and saved cards without closing messaging, maps or browsing. Each service team chooses its own response in observe mode first, sees how often it would fire on genuine users, and only then switches it on for its screens.

  • Who owns security decisions in a superapp?

    Usually a central platform team owns the host and identity, while service teams own their own backends and risk. Otukan fits that shape. The platform team manages host protection and shared evidence; each service team reads that evidence and sets its own policy. We agree the split with you during onboarding so every signal has an owner.

  • How does Otukan handle frequent host releases?

    Superapps ship often because many teams contribute to one binary. Otukan runs inside your existing build and release pipeline, so every host build is protected without a separate step. Response policy changes without a new release, and new mini-apps or partner updates prompt a retest of the protected host build before it reaches users.

On the mobile engineering team?

How protection fits your build, signing and release, platform by platform.

Secure every service your app hosts

Tell us the platform, the app framework, which services and partner mini-apps run inside your app and the flow you most need to protect. We do not ask for binaries, signing keys, user data or production credentials.

Or request a technical demo