A mobile security team should evaluate progressive web app protection by first drawing where the app actually runs: in the user’s browser, installed from the browser to the home screen, or inside a native wrapper shipped through Google Play or the App Store. Then ask which of those layers each control can reach, and verify distribution, origin and update behaviour before launch. This guide is for enterprise and product teams that deliver a web app to phones. Otukan protects the native wrapper and gives your backend evidence about it. Web content running in a standalone browser is secured with web controls such as content security policy and server-side checks.
The wrapper controls are covered on progressive web app protection. Other workforce app controls are on enterprise application protection.
Architecture: browser, web content and native wrapper
Three runtimes
| Runtime | Who controls the code that runs | Where protection can act |
|---|---|---|
| Browser tab or home-screen install | The browser vendor; your content runs inside it | Web content policy and your server |
| Web view inside a native app | You ship the native shell; web content loads into it | Native shell, bridge and server |
| Browser-backed wrapper | The browser renders your content on behalf of a thin native app | Native shell and server; the rendering stays with the browser |
On Android, a browser-backed wrapper hands rendering to the user’s browser, so the web content does not run in your app’s process. On iOS, apps that display web content use the system web view, and home-screen web apps run on the same engine as Safari.
- Which of these runtimes do you ship today, per platform?
- Does the wrapper expose a JavaScript bridge to native functions such as storage, biometrics or payments?
- Which data is held by the web layer and which by the native layer?
Protection limits: the component Otukan influences
The useful question is not “is the app protected?” but “which part?”. Otukan protects the native layer you sign and ship, and the bridge where web content meets it.
Where Otukan acts
- Native shell integrity. Is the store app the one you published, or a repackaged copy that loads your content with extra code?
- Runtime conditions. Is the wrapper running under hooking, a debugger, root on Android or jailbreak on iOS?
- Bridge exposure. Can a tampered shell call native functions that the web layer trusts?
- Backend evidence. Can your server tell the genuine wrapped app from a script that calls the same web endpoints?
Where web controls act
- Content security policy, subresource integrity and secure cookie settings on your web origin.
- Server-side session checks for users who never install the wrapper.
How Otukan answers. Otukan protects the native shell of your wrapped web app on Android and iOS with obfuscation, anti-tampering and runtime checks. It detects injected code in the bridge functions that pass data between web content and the native layer, and can close native functions such as file access or device features to the page when the bridge is tampered with. Debuggers and inspectors attached to the release wrapper and its embedded web view are detected. App attestation lets your backend recognise requests from the genuine wrapper, and runtime signals from the wrapper can inform the web session your server manages.
Release: distribution, origin and updates
Distribution
- Which stores and channels carry the wrapper, and who signs each build?
- Do users also reach the same service through a plain browser, and is that path held to the same backend checks?
Origin and network behaviour
- Which origins may the wrapper load, and is navigation to any other origin blocked or opened outside the app?
- On Android, does your site’s digital asset links file confirm the relationship between your web origin and the wrapper?
- Does the wrapper load content only over TLS from origins you control?
Updates
- Web content changes on your server without a store release. Who reviews those changes for bridge calls?
- Wrapper updates follow the store cycle. How do you retire old wrapper versions?
- Test an update of each layer on its own and confirm protection still holds.
- Record which team signs off a web content change that alters what the bridge exposes, and how quickly a risky change can be rolled back on the server.
How Otukan answers. Every protected wrapper release checks itself: code, resources and signing identity must match the build you published, and a re-signed copy is stopped before it loads your web content. You set a response per flow in the wrapper: observe, warn, restrict or terminate. Otukan fits the wrapper’s existing build and release pipeline, while your team keeps its signing keys.
Build and release fit is covered on build and release integration.