The endpoints your fragments call are the same Lava Application endpoints a browser calls, so the Helix security guidance applies unchanged: Execute verbs are the real boundary, never modify data on a GET, never treat an IdKey or Guid as the authorization mechanism, and sanitize anything you interpolate into SQL. Read that page first. This page is only the part that is different because the client is an app. Granting Edit on an Application is a privileged grant This is the one to internalize before you open Application editing to a wider group. On the web, a fragment is HTML rendered in a browser. On mobile, a fragment is XAML, and XAML can invoke the app's commands. So anyone who can edit a Lava Application can run app commands for anyone who opens the screen that hosts it. That is the same trust model the Content block has always had, where server-supplied XAML is trusted. What Helix changes is who can author it: not just a block developer, but anyone with Edit on an Application. The mitigations are the security defaults that already ship: deny-all View on Applications, and the RSR - Lava Application Developers role. Leave them in place, and treat adding someone to that role the way you would treat giving them a code deploy. Fragments can call more than Lava Application routes A verb is not limited to ^ routes. Any absolute server path is sent as-is, carrying the signed-in person's credentials: <ContentView Hx.Post="/api/v2/some-endpoint" Hx.Trigger="load" /> This is not privilege escalation. The request is still authorized as that person, and they cannot reach anything they could not already reach. What it does mean is that a fragment can make an authenticated request on their behalf without them tapping anything, since a load trigger fires as soon as the screen renders. Reading data back out is awkward, because a JSON response fails to parse as XAML and lands as an error notification, but writes go through fine. It is the same trust model as the section above: anyone with Edit on the Application can author it. Worth knowing explicitly when you decide who gets that grant. X-Helix-Client and ClientType are hints, never inputs The app sends X-Helix-Client: RockMobile, and the server derives the ClientType merge field from it. Any caller can send that header with curl. Branch presentation on it. Never gate data access on it. {% comment %} Fine. Chooses markup. {% endcomment %} {% if ClientType == 'Mobile' %}...{% endif %} {% comment %} Not fine. This is not a security check. {% endcomment %} {% if ClientType == 'Mobile' %}{% sql %}SELECT ...{% endsql %}{% endif %} Values gathered from the screen are still untrusted Automatic value inclusion collects values from controls by name, which makes it easy to forget that what arrives is just an HTTP request. A caller can send whatever Form and QueryString values they like, and the IsRequired and ValidationExpression rules you configured are a UX feature, not enforcement. Validate on the server regardless of what the shell "should" have sent.