How should security teams assess the attack surface of .NET MAUI apps that share logic across iOS and Android?

Security teams should treat the shared C# layer as the primary review target, not the platform wrapper. Extract the assemblies from both builds, decompile them, and test the business logic, storage, networking, and authorization paths as one codebase. That approach exposes flaws once and applies the findings across both storefronts, which is the real risk of a write once, run anywhere architecture.

What security teams should inspect first in a shared .NET MAUI codebase

The right starting point is the shared application logic, because that is where one defect can become a cross-platform defect. Decompiling only the iOS or Android wrapper misses the code paths that actually govern data handling, API calls, token use, local storage, and feature gating. A good attack surface review asks which behaviors are truly common, then traces how each platform build exposes or constrains them.

That framing is especially important when the app uses one business layer for both storefronts. The same logic can be reachable through different UI flows, device permissions, and OS integrations, but the underlying flaw is still a single code issue. Security teams should therefore model the shared assemblies as the primary trust boundary and the platform shell as the delivery mechanism around it.

Good review targets include input handling, client-side authorization checks, secret handling, network destinations, offline caches, and any code that decides what a user can see or do. If a control or decision lives in shared code, it should be tested once as shared logic and then validated against each platform-specific entry path that reaches it.

How to test the shared assemblies as one attack surface

Extract the app packages from both platforms, decompile the assemblies, and compare the compiled outputs to confirm whether the same business logic was reused unchanged or compiled differently. Then review the shared classes for authorization decisions, serialization logic, cryptographic use, hard-coded endpoints, embedded keys, and error handling that may reveal internal state. The goal is not just source recovery, but understanding where a single weakness fans out across two mobile ecosystems.

Static review should be paired with runtime testing from both clients, because platform differences can change how a flaw is reached even when the code is shared. For example, one build may expose a path through Android intents while the other reaches the same method through iOS navigation or background sync. Treat those as distinct ingress paths into the same underlying codebase.

When the app depends on shared libraries, inspect those dependencies as part of the same surface. A vulnerable package, unsafe deserialization routine, or weak logging helper can become visible in both builds at once. In practice, this means the attack surface is larger than the UI footprint suggests and smaller than the combined storefront count implies.

Where the real risk concentrates in cross-platform MAUI apps

The highest-risk weakness is usually a control that was assumed to be platform-specific but is actually enforced in shared code. If token validation, role checks, or data filtering happen only in the client, both storefronts inherit the same trust failure. Shared storage and sync logic are also common concentration points because one bug can duplicate sensitive data exposure across devices and accounts.

There is also a disclosure risk when teams treat the wrapper as the main target and ignore the assemblies that contain the real business logic. If a reverse engineer can recover the shared layer, they can often enumerate endpoints, business rules, feature flags, and conditional access logic even without server access. That turns a mobile app review into a broader application review.

Shared code also raises the blast radius of any authorization mistake. A bypass in one code path may apply to both apps, while a mistake in one persistence routine may affect every user on every supported platform. The practical question is not “which storefront is weaker,” but “which shared assumption would fail everywhere if it were wrong once.”

Risk and Threat Considerations

When a shared codebase powers multiple mobile storefronts, one successful reverse engineering effort can expose business rules, data flows, and secrets in both ecosystems. The risk is not just code disclosure, but the compression of many app-specific attack paths into one reusable weakness.

Failure mechanism: Shared assemblies concentrate logic, so a single authorization error, unsafe storage decision, or leaked secret can be lifted from one build and applied against the other with minimal extra effort.

Impact: Attackers gain a larger blast radius from one flaw, defenders lose the benefit of platform separation, and remediation work must be applied consistently across every build that reused the same code.

Framework Alignment

Shared mobile logic that governs authentication, authorization, secrets, and client-side trust maps directly to application security verification. For broader controls, OWASP Top 10 remains a useful baseline for recurring app-layer failure patterns, while NIST SP 800-53 Rev 5 Security and Privacy Controls supports control selection for access, audit, and configuration review.

For mobile code review, OWASP Cheat Sheet Series is useful for authentication, secrets, and session handling guidance, and OWASP Non-Human Identity Top 10 can help when the shared client logic embeds or handles machine credentials, tokens, or API keys that widen the app’s exposure.

FIRST can support incident response coordination if the same shared flaw is found to affect both storefronts, and NCSC UK Advice and Guidance is a practical reference for mobile and software security operations.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP ASVS	V6 — Authentication	Shared MAUI logic often contains client auth decisions and token handling.
	V8 — Authorization	The shared layer may decide what data or actions the app permits.
	V14 — Data Protection	Shared code commonly stores, moves, or caches sensitive app data.
Recommendation — Review shared authentication paths and remove any client-side trust decisions. Verify shared authorization checks cannot be bypassed in either build. Inspect shared storage and data handling for leakage and weak protection.
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	Cross-platform reuse can amplify excessive access decisions in shared code.
	IA-5 — Authenticator Management	Shared apps often embed tokens, keys, or other authenticators.
Recommendation — Constrain client-side privileges to the minimum required by each function. Rotate and protect authenticators used by shared mobile code.

Practitioner Guidance

What to verify: Confirm which assemblies are identical across iOS and Android, which methods decide access or data visibility, and which secrets or endpoints are embedded in shared code. If the same method governs business logic on both platforms, test it as a single security control with multiple entry points.

What to prioritise: Start with authorization, storage, networking, and any code that handles tokens or credentials. Those paths usually determine whether a flaw is merely cosmetic or becomes a real compromise condition.

Common mistake: Teams often spend too much time on platform packaging and too little time on the decompiled shared logic. That reverses the risk model and leaves the most reusable attack surface under-reviewed.

Practitioner takeaway: In .NET MAUI, the shared C# layer is usually the security boundary that matters most, so assess it once, test it against both platform entry paths, and assume any weakness there scales to every build that reuses it.