A handful of Android WebView settings control whether web content can reach the device's file system, and turning the wrong ones on can let a script read your app's private files. The dangerous pair lets JavaScript running in a local file context read other local files, or any origin, which combined with untrusted content becomes a local-file exfiltration hole. Modern Android defaults these to off, but developers sometimes enable them to make something work. Here is what the WebView file-access settings do, the risk, and how to keep them safe.
Short answer
Android WebView has several file-access settings: setAllowFileAccess controls whether the WebView can load file:// URLs, and setAllowFileAccessFromFileURLs and setAllowUniversalAccessFromFileURLs control whether JavaScript running in a file:// context can read other local files or content from any origin. Per Android's WebView settings documentation, the latter two are dangerous and default to false on modern Android, because enabling them lets a script in a local page read other local files, such as your app's private data, which is a local-file exfiltration risk. Keep those two disabled, avoid loading untrusted content with file access enabled, and do not turn these on for convenience.
What you should know
- Several settings control file access: file URL loading and cross-file or universal access.
- The cross-file settings are dangerous: JS in a file context reading other files.
- Modern defaults are off: the risky settings default to false.
- Enabling them risks exfiltration: a script could read your app's private files.
- Do not enable for convenience: keep the dangerous settings disabled.
What are the WebView file-access settings?
A set of WebSettings flags that decide how much of the file system WebView content can touch. setAllowFileAccess controls whether the WebView can load file:// URLs at all, which you might use to display local HTML. setAllowFileAccessFromFileURLs controls whether JavaScript running in a page loaded from a file:// URL can access other file:// resources, and setAllowUniversalAccessFromFileURLs controls whether such a script can access content from any origin, effectively bypassing the same-origin policy for a local page. There is also setAllowContentAccess for content:// URLs. The two cross-origin file settings are the security-sensitive ones, because they govern whether a local page's JavaScript can reach beyond itself, and they default to false on modern Android precisely because enabling them is risky.
What is the risk?
Local-file exfiltration when those settings are on and content is not fully trusted. The table shows the exposure.
| Setting | Risk if enabled with untrusted content |
|---|---|
| setAllowFileAccess | The WebView can load local files; broader file reach |
| setAllowFileAccessFromFileURLs | A local page's JS can read other local files |
| setAllowUniversalAccessFromFileURLs | A local page's JS can read any origin, bypassing same-origin |
| Loading untrusted content with these on | Injected script can read and exfiltrate your app's files |
The dangerous scenario is a WebView that loads local HTML with these cross-file settings enabled and then somehow renders attacker-influenced content, through injection, a loaded remote resource, or user-supplied data, so that JavaScript in that local context reads your app's private files and sends them out. Because a file:// page with universal access can reach other files and origins, the same-origin protection that normally contains a page is gone, which is why these settings are off by default and why enabling them is a real risk rather than a convenience.
How do you configure WebView file access safely?
Keep the cross-file settings disabled and do not mix file access with untrusted content. Leave setAllowFileAccessFromFileURLs and setAllowUniversalAccessFromFileURLs set to false, which is the secure default on modern Android, since almost no app has a legitimate need to let a local page's JavaScript read other local files or any origin. Only enable setAllowFileAccess if you genuinely need the WebView to load local files, and when you do, make sure the content is yours and trusted, not remote or user-influenced, so there is no untrusted script to abuse the access. Better still, avoid loading untrusted content in a WebView at all, and prefer serving content from your backend over HTTPS or bundling trusted local assets. The principle is that file access plus any untrusted content is the dangerous combination, so keep them apart and keep the cross-file settings off.
What to watch out for
The first trap is enabling setAllowUniversalAccessFromFileURLs or setAllowFileAccessFromFileURLs, often to make a local page work, which opens a local-file exfiltration path; keep them false. The second is loading remote or user-influenced content into a WebView that has file access enabled, which gives injected script the reach to read your files. The third is leaving file access on when the WebView no longer needs it. A pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled APK or AAB against OWASP MASVS and surfaces your WebView configuration, including file-access settings, so you can confirm the dangerous ones are disabled before you ship. The settings you configure on the WebView.
What to take away
- WebView file-access settings control whether content can load
file://URLs and whether a local page's JavaScript can read other local files or any origin. - The cross-file settings,
setAllowFileAccessFromFileURLsandsetAllowUniversalAccessFromFileURLs, are dangerous and default to false on modern Android. - Enabling them with untrusted content allows local-file exfiltration, where injected script reads your app's private files, so keep them disabled.
- Enable
setAllowFileAccessonly for trusted local content, avoid untrusted content in WebViews, and use a pre-submission scan such as PTKD.com to confirm your settings.
