By NHI Mgmt Group Editorial TeamDomain: Cyber SecuritySource: NowSecurePublished November 19, 2025

TL;DR: A Safari extension can gain broad page-level visibility, inject code across sites and collect browsing signals, while the app also weakens default transport protections and attempts to fingerprint installed apps, according to NowSecure. The pattern reinforces that app approval now needs stronger privacy governance, runtime scrutiny and identity-aware access controls, not just functional review.


At a glance

What this is: NowSecure examined the Phia iOS shopping app and found that a bundled Safari extension can inject code across sites, monitor browsing activity and collect device signals beyond what many users would expect.

Why it matters: This matters because mobile app permissioning, extension scope and device-level data collection now intersect with privacy, compliance and identity governance, creating exposure that AppSec, IAM and GRC teams need to assess before approval.

👉 Read NowSecure's analysis of the Phia iOS app and Safari extension data overreach


Context

Mobile app data overreach happens when an app collects more browsing, device or behavioural data than is necessary for its stated function. In this case, the concern is not just privacy creep, but the governance gap between what users approve and what an extension can do once it is granted broad website access. For identity and access teams, that gap matters because delegated permissions can become persistent visibility into user activity without meaningful ongoing review.

The article is also a reminder that mobile apps increasingly behave like embedded platforms rather than simple consumer tools. When an app can inject scripts, observe cookies, access page context and disable transport safeguards, the security question shifts from feature usefulness to control boundaries. That is a familiar problem in identity programmes too, where broad grants often outlast the original business justification.


Key questions

Q: How should security teams assess mobile apps that request broad browser access?

A: Treat broad browser access as a privileged permission rather than a routine mobile feature. Review whether the app can inject code, observe page context, read cookies or communicate with native components. If the requested access is wider than the business use case, the app should fail security review or be constrained before deployment.

Q: What breaks when a mobile app extension runs in the page context?

A: Page-context execution removes a major isolation boundary. The extension can interact with the same DOM and JavaScript environment as the website, which increases the chance of data capture, content modification and credential exposure. That is why page-context access needs tighter approval and monitoring than standard isolated extension behaviour.

Q: Why do mobile app privacy issues matter to IAM and GRC teams?

A: Because the permissions that enable overcollection are themselves access decisions. If an app can observe browsing activity, device signals or network metadata, the organisation has granted a form of delegated access that should be governed, reviewed and revoked like any other privileged capability. Privacy and identity governance overlap at the permission boundary.

Q: How can organisations reduce risk from consumer apps used on managed devices?

A: Set a higher review bar for apps that touch managed devices, shared credentials or employee browsing. Require dynamic testing, transport-hardening checks and clear owner accountability before approval. If the app’s behaviour cannot be explained in operational terms, treat it as a risk to both privacy and enterprise control.


Technical breakdown

Safari Web extension permissions and page-context injection

Safari Web extensions use a permissions model that can grant access across many or all websites, depending on what the user allows. When an extension runs scripts in the page context, it can share the same JavaScript environment as the website itself, which is materially different from isolated browser tooling. That makes DOM inspection, network observation and content modification possible on every granted page. In this case, the combination of broad match patterns, MAIN world execution and host-app communication creates a high-trust path from the browser into the native app. The security issue is not just visibility, but the breadth of control once permission is granted.

Practical implication: treat browser-extension permissions as a privileged access decision, not a routine app permission.

Persistent tracking through extension and native app bridges

The extension model described in the article uses event-driven background handling and a native bridge, which means activity can continue to flow even when Safari is not visibly open. That architecture matters because it extends the effective lifetime of access beyond a single browsing session. Combined with cookies, webRequest visibility and broad site permissions, the extension can observe both navigation and network metadata. This is a classic boundary problem: once a consumer app can bridge web content to native code, the app inherits much more of the device trust surface than users usually realise. The result is durable telemetry collection with limited user visibility.

Practical implication: review whether the native bridge and background behaviour are justified for the app’s business purpose.

Mobile app privacy overreach and transport-hardening gaps

The app also exposes a second risk layer: device and network hardening. Disabling App Transport Security removes default iOS protections for secure transport, while app fingerprinting logic that probes installed URL schemes can reveal more about the device environment than the user expects. Together, these choices show how privacy and security failures often cluster. A consumer-facing app can still create enterprise risk if it processes employee devices, shared accounts or business browsing activity. The governance challenge is to assess both the declared feature set and the operational behaviour under the hood.

Practical implication: validate transport settings and app fingerprinting behaviour during mobile security review, not after deployment.


NHI Mgmt Group analysis

Data overreach is now an access-control problem, not just a privacy problem. When a mobile app can read page context, network metadata and device signals, the real issue is whether the requested access matches the business purpose. That is an IAM-style governance question applied to mobile software behaviour, and it should be reviewed with the same discipline used for privileged applications. Practitioners should treat permission scope as a control boundary, not a consent checkbox.

Browser extensions are functionally high-trust identity endpoints. Once an extension can run in the page context and talk to native code, it behaves less like a utility and more like a delegated control plane. That creates a need for tighter entitlement review, stronger runtime inspection and clearer owner accountability. For teams managing identity and device trust together, this is a reminder that delegated access is still access. Practitioners should map extension privileges into their wider access governance model.

Permission drift: consumer apps often accumulate capabilities that were never obvious at approval time. The article shows how a shopping app can become a browsing observer, a device fingerprinting tool and a network visibility point through a small number of broad grants. That is the kind of silent expansion that weak governance misses. Practitioners should assume that feature growth can outpace review cycles unless controls are tied to runtime behaviour.

Mobile security review needs to include privacy intent, transport defaults and identity-aware monitoring. Disabling transport protections or probing installed apps may not look dramatic in isolation, but together they show a programme willing to weaken baseline safeguards for data collection. That combination should trigger a higher bar for approval, especially where employee devices or managed identities are involved. Practitioners should treat these findings as evidence that app trust must be continuously revalidated, not signed off once.

What this signals

Mobile app governance is moving closer to identity governance because app permissions increasingly determine what data a tool can observe, modify or relay. That shift means security teams need a control model that evaluates not just installation risk, but delegated runtime access, page-context visibility and persistence. In practice, this is where browser extensions, device posture and consent review converge.

Permission scope drift: the core issue is not that an app has one invasive capability, but that a seemingly narrow feature set can expand into broad behavioural collection over time. That pattern is familiar in identity programmes, where access granted for one purpose is later reused for another. Teams should build review processes that inspect runtime behaviour, not just app store descriptions.


For practitioners

  • Review extension permissions as privileged access Require explicit review for any mobile app extension that requests broad website access, page-context execution or native bridge capability. Map those permissions to business justification and remove approvals that are wider than the stated use case.
  • Test for runtime data collection beyond declared function Use dynamic mobile app analysis to observe what the app and its extension actually collect across real browsing sessions, including cookies, URL parameters and page content. Static manifest review alone will miss the behaviour that creates privacy exposure.
  • Validate transport and fingerprinting controls before release Check whether App Transport Security is disabled, whether the app probes installed URL schemes and whether the network stack allows unsafe behaviour. These findings should block release unless there is a documented, risk-accepted reason.
  • Align mobile app governance with identity and device trust Feed mobile app findings into IAM, GRC and privacy review so that app permission scope, device signals and user consent are assessed together. This is especially important for managed devices and employee browsing contexts.

Key takeaways

  • The Phia analysis shows how a mobile shopping app can become a broad browsing and device observability channel once extension permissions are granted.
  • The governance gap is not only privacy related, because broad page-context access behaves like privileged delegation and should be reviewed that way.
  • Security teams should test real runtime behaviour, transport settings and native bridge use before approving mobile apps for employee or managed-device use.

Standards & Framework Alignment

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

NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 and GDPR define the regulatory obligations.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0PR.AC-4Broad app permissions and extension scope map to access control governance.
NIST SP 800-53 Rev 5AC-6Least privilege is directly implicated by the app's broad browsing and device access.
ISO/IEC 27001:2022A.8.2Information classification and handling controls are relevant to data collected from browsing activity.
GDPRArt.5The app's collection of browsing and device signals raises data minimisation concerns.

Apply Art.5 principles to limit collection to what is necessary and document lawful purpose for each data type.


Key terms

  • Browser Extension Page-Context Access: A permission model that lets an extension run code inside the same page environment as the website a user is visiting. This can expose page content, session data and network interactions to the extension, which is why it should be treated as a high-risk delegated access decision.
  • Mobile App Data Overreach: Collection of device, browsing or behavioural data that exceeds what is required for an app's stated function. The risk is not only privacy harm, but also governance failure when broad permissions persist without meaningful review or user understanding.
  • Native App Bridge: A communication path between web content or an extension and the underlying mobile application. It can be useful for functionality, but it also expands trust boundaries because browser activity may flow into native code with fewer user-visible controls.
  • Transport Hardening: Configuration choices that preserve secure network communication defaults on a device or application. Weakening those defaults can expose traffic to unnecessary risk, especially when an app already collects sensitive browsing or device signals.

What's in the full report

NowSecure's full analysis covers the operational detail this post intentionally leaves for the source:

  • Static and dynamic analysis artifacts for the iOS Safari Web extension, including manifest behaviour and page-context execution details.
  • The whitelist and exclusions model used by the app, with practical examples of how broad collection still occurs.
  • Observed app behaviour around URL scheme probing and transport-hardening choices.
  • Technical comparison points between the iOS and Chrome extension behaviour that inform mobile AppSec review.

👉 The full NowSecure post covers the extension behavior, manifest details and mobile privacy implications in more depth.

Deepen your knowledge

NHI Mgmt Group’s NHI Foundation Level course, the industry’s only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps practitioners connect identity controls to broader access and lifecycle decisions across modern security programmes.
NHIMG Editorial Note
Published by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org