OWASP Mobile Application Security Testing Guide: MASTG KNOW 0076

---
masvs_category: MASVS-PLATFORM
platform: ios
title: WebViews
---

WebViews are in-app browser components for displaying interactive web content. They can be used to embed web content directly into an app's user interface. iOS WebViews execute JavaScript and render HTML, and therefore can execute injected scripts when untrusted content is rendered.

## Types of WebViews

There are multiple ways to include a WebView in an iOS application.

### WKWebView

[`WKWebView`](https://developer.apple.com/reference/webkit/wkwebview "WKWebView") was introduced with iOS 8 and is the appropriate choice for extending app functionality, controlling displayed content (i.e., prevent the user from navigating to arbitrary URLs) and customizing.

`WKWebView` comes with several security advantages over `UIWebView`:

- JavaScript is enabled by default but it can be completely disabled using the `javaScriptEnabled` property of `WKWebView`, which helps mitigate script injection attacks by preventing injected scripts from executing.
- The `javaScriptCanOpenWindowsAutomatically` property can be used to prevent JavaScript from opening new windows, such as pop-ups.
- `WKWebView` implements out-of-process rendering, so memory corruption bugs won't affect the main app process.

A JavaScript Bridge can be enabled when using `WKWebView` and `UIWebView`. See Section ["WebView-Native Bridges"](#webview-native-bridges) below for more information.

### SFSafariViewController

[`SFSafariViewController`](https://developer.apple.com/documentation/safariservices/sfsafariviewcontroller "SFSafariViewController") is available starting on iOS 9 and should be used to provide a generalized web viewing experience. These WebViews can be easily spotted as they have a characteristic layout which includes the following elements:

- A read-only address field with a security indicator.
- An Action ("Share") button.
- A Done button, back and forward navigation buttons, and a "Safari" button to open the page directly in Safari.

<img src="Images/Chapters/0x06h/sfsafariviewcontroller.png" width="400px" />

There are a couple of things to consider:

- JavaScript cannot be disabled in `SFSafariViewController` and this is one of the reasons why the usage of `WKWebView` is recommended when the goal is extending the app's user interface.
- `SFSafariViewController` also shares cookies and other website data with Safari.
- The user's activity and interaction with a `SFSafariViewController` are not visible to the app, which cannot access AutoFill data, browsing history, or website data.
- According to the App Store Review Guidelines, `SFSafariViewController`s may not be hidden or obscured by other views or layers.

This should be sufficient for an app analysis and therefore, `SFSafariViewController`s are out of scope for the Static and Dynamic Analysis sections.

### UIWebView (DEPRECATED since iOS 12, don't use)

[`UIWebView`](https://developer.apple.com/reference/uikit/uiwebview) was deprecated by Apple in iOS 12 and has since been superseded by `WKWebView` and `SFSafariViewController` for embedding web content. Reasons commonly cited include its older security model, the lack of support for disabling JavaScript, and the availability of more modern configuration and isolation controls in its successors.

## WebView Network Security

The engine behind iOS WebViews is WebKit, which is also used by the Safari browser. This means that WebViews are subject to the same network security policies as Safari, including App Transport Security (ATS) and mixed content restrictions. However, developers can configure these policies differently for WebViews than for the rest of the app, which can lead to security issues if not done carefully.

### ATS

iOS WebViews are subject to the same App Transport Security (ATS) policies as the rest of the app. ATS has a specific policy for WebViews, which allows developers to relax security for web content while keeping the rest of the app secure. This is controlled by the [`NSAllowsArbitraryLoadsInWebContent`](https://developer.apple.com/documentation/bundleresources/information-property-list/nsapptransportsecurity/nsallowsarbitraryloadsinwebcontent) key in the app's Info.plist file. If this key is set to `true`, it allows WebViews to load content over insecure HTTP connections, even if the rest of the app is restricted by ATS.

### Mixed Content

WebViews can load both HTTP and HTTPS content, which may lead to [mixed content](https://web.dev/articles/fixing-mixed-content) situations. Mixed content occurs when an HTTPS page attempts to load resources such as scripts, images, or iframes over HTTP. This weakens the security guarantees of the HTTPS page because the insecure resource could be modified by an attacker. You can learn more about mixed content in the ["Mozilla Docs for Mixed Content"](https://developer.mozilla.org/en-US/docs/Web/Security/Defenses/Mixed_content) and in the ["web.dev article for Fixing mixed content"](https://web.dev/articles/fixing-mixed-content).

Mixed content is typically divided into **active** and **passive** types. Active mixed content includes resources that can execute or modify the page, such as scripts, stylesheets, or iframes. Passive mixed content includes resources such as images, audio, or video that are displayed but do not directly execute code. In modern browsers and WebKit, **active mixed content is blocked**, while **passive mixed content is often automatically upgraded to HTTPS if possible**, or otherwise blocked and reported with a warning.

In `WKWebView`, active mixed content such as HTTP scripts loaded by an HTTPS page is generally **blocked by WebKit itself**, even if the application relaxes App Transport Security. For example, setting `NSAllowsArbitraryLoadsInWebContent` allows insecure network requests from WebViews from the ATS perspective, but it **does not disable WebKit's mixed content protections**. As a result, an HTTPS page that tries to load an HTTP script will typically have that resource blocked. See ["WebKit Features in Safari 18.0" (September 2024)](https://webkit.org/blog/15865/webkit-features-in-safari-18-0/#https).

The API [`hasOnlySecureContent`](https://developer.apple.com/documentation/webkit/wkwebview/hasonlysecurecontent) can be used after a page finishes loading to determine whether the WebView ultimately loaded only secure resources. However, it is **informational rather than preventive**. It reflects the final security state of the page, not whether the page attempted to load insecure resources that were blocked.

Because WebKit enforces these protections and they cannot be disabled through public `WKWebView` APIs, active mixed content can only be loaded when the page itself is requested over HTTP, regardless of ATS settings such as `NSAllowsArbitraryLoadsInWebContent`.

## Loading Content

### Loading Remote URLs

iOS apps can load remote URLs into a WebView using the [`load(_:)`](https://developer.apple.com/documentation/webki