Flatpak is an application packaging and distribution technology that makes it possible to develop an application that can be run in a sandbox across Linux distributions. Being distribution agnostic, a Flatpak application that you install in Debian can also be installed as-is in Fedora. Because it runs in a sandbox, a Flatpak app needs permissions to access and use system resources like sound, network, files, and Bluetooth.

Flatpak’s sandbox can be a strong starting point, but it is not a magic shield you can forget about. Real-world risk comes from the places where convenience quietly expands access: broad file mounts “just to make it work”, network permissions left on by habit, and long-lived portal grants you approved once and never revisited, especially when people and businesses avoid automation solutions.

This article focuses on what works on a normal desktop, not in theory: how to inspect the permissions a Flatpak app actually has, how to validate what it does with that access, and how to shrink the “blast radius” if the app misbehaves. The goal is not paranoia. It is choosing sensible defaults, then making intentional exceptions only where they truly help.

Auditing network behavior with a controlled endpoint

Permissions tell you what an app is allowed to do. Network behavior tells you what it actually tries to do. If you want to connect those two, a well-scoped proxy setup is one of the most practical moves you can make, because it turns “network access” from a yes or no switch into something you can observe and shape.

One smart trick is to give one Flatpak app its own private path to the internet through a dedicated proxy, instead of letting it use the same connection as all your other apps. Doing that lets you see clearly which websites (domains) it talks to, how often it connects, and at what times. With that information, you can decide if the app really needs to connect to the internet at all or if it only needs it for a few specific things.

How proxy works

A proxy sits between the Flatpak app and the internet. In a forward proxy setup, the app sends its request to the proxy, which then forwards it to the real, or target, website. With Flatpak, you can often point just one app to this proxy: for example, you can set HTTP_PROXY and HTTPS_PROXY only for that app. That way, the host system and other apps stay the same, but you get a clean log of traffic for that one app.

Why proxies help here

With an app proxy, you:

  • see where the app connects (visibility)
  • can say “yes” or “no” to certain sites (simple allow/deny rules)
  • and keep different apps using different identities/IPs.

If all apps share the same proxy, the traffic is mixed together, but if an app has its own proxy, the signal is much clearer and easier to undo if something breaks.

A permission audit that scales with how Flatpak is used

A simple permission audit starts with Flatpak’s built-in tools. For example, to see what a Flatpak app is allowed to do by default, run the following command:

# Command to view a Flakpak app's default permissions

flatpak info --show-permissions <app-id>

 

And the following command lets you see what permissions you have changed for that app on your system:

# Command to see changes to an app's permissions

flatpak override --show <app-id>

 

If you haven’t checked in a while, don’t try to make everything perfect on the first pass. Just look for the big, important things, like:

  • Does the app have broad access to your files (like your whole home folder or the host filesystem)?
  • Does it have powerful access to system services (like the message bus)?
  • Does it have access to devices (like USB, webcam, etc.)?

Those are the high-impact areas to check first.

This matters because Flatpak is not a niche packaging format anymore. Flathub’s own public numbers show total downloads in the billions and thousands of desktop apps in the catalog, which means permission habits, good or bad, get repeated at scale.

It is also useful to look at usage momentum, because it explains why “default permissions” alone are not the whole story. Many users install more apps this way each year, so the long tail of “apps you tried once” grows, and so does the pile of permissions you forgot you granted. Flathub’s Year in Review pages show steady yearly download volume and very large update counts:

YearTotal Downloads (millions)App updates (millions)Download growth vs prior year
2023322.7480.9+117.1%
2024360.4613.8+11.7%
2025438.2727.4+21.6%

The figures above come from Flathub’s Year in Review pages for 2023 – 2025.

Once you see how often apps update, it is easier to justify a quick re-check after major updates, especially for apps that handle sensitive files or integrate with online accounts. The audit loop is simple: inspect permissions, decide what you really need, apply a small change, then re-test the workflow you care about.