WKWebView: This is the appropriate choice for extending app functionality, controlling displayed content.
The hasOnlySecureContent property can be used to verify resources loaded by the WebView are retrieved through encrypted connections.
WKWebView implements out-of-process rendering, so memory corruption bugs won't affect the main app process.
SFSafariViewController: Itshould 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.
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, SFSafariViewControllers may not be hidden or obscured by other views or layers.
let webPreferences = WKPreferences()
If only having the compiled binary you can search for this in it:
In contrast to UIWebViews, when using WKWebViews it is possible to detect mixed content (HTTP content loaded from a HTTPS page). By using the method hasOnlySecureContent it can be verified whether all resources on the page have been loaded through securely encrypted connections.
In the compiled binary:
Several default schemes are available that are being interpreted in a WebView on iOS, for example:
WebViews can load remote content from an endpoint, but they can also load local content from the app data directory. If the local content is loaded, the user shouldn't be able to influence the filename or the path used to load the file, and users shouldn't be able to edit the loaded file.
WKWebView: It can use the methods loadHTMLString:baseURL: or loadData:MIMEType:textEncodingName:baseURL: to load local HTML files and loadRequest: for web content. Typically, the local files are loaded in combination with methods including, among others: pathForResource:ofType:, URLForResource:withExtension: or init(contentsOf:encoding:). In addition, you should also verify if the app is using the method loadFileURL:allowingReadAccessToURL:. Its first parameter is URL and contains the URL to be loaded in the WebView, its second parameter allowingReadAccessToURL may contain a single file or a directory. If containing a single file, that file will be available to the WebView. However, if it contains a directory, all files on that directory will be made available to the WebView. Therefore, it is worth inspecting this and in case it is a directory, verifying that no sensitive data can be found inside it.
If you have the source code you can search for those methods. Having the compiledbinary you can also search for these methods:
Universal access from file:// URLs is always enabled.
If you retrieve the effective origin from a UIWebView where baseURL is also set to nil you will see that it is not set to "null", instead you'll obtain something similar to the following: applewebdata://5361016c-f4a0-4305-816b-65411fc1d780. This origin "applewebdata://" is similar to the "file://" origin as it does not implement Same-Origin Policy and allow access to local files and any web resources.
Look out for code that maps native objects to the JSContext associated with a WebView and analyze what functionality it exposes, for example no sensitive data should be accessible and exposed to WebViews.
In Objective-C, the JSContext associated with a UIWebView is obtained as follows:
let userContentController = wkWebViewConfiguration.userContentController
In iOS webviews, messages passed to console.log() are not printed to the Xcode logs. It's still relatively easy to debug web content with Safari's developer tools, although there are a couple of limitations:
Debugging iOS webviews requires Safari, so your dev computer must be running macOS.
You can only debug webviews in applications loaded onto your device through Xcode. You can't debug webviews in apps installed through the App Store or Apple Configurator.
With those limitations in mind, here are the steps to remotely debug a webview in iOS:
First, enable the Safari Web Inspector on your iOS device by opening the iOS Settings app, navigating to Settings > Safari > Advanced, and toggling the Web Inspector option on.
iOS Safari settings
Next, you must also enable developer tools in Safari on your dev computer. Launch Safari on your dev machine and navigate to Safari > Preferences in the menu bar. In the preferences pane that appears, click on the Advanced tab and then enable the Show Develop menu option at the bottom. After you do that, you can close the preferences pane.
Mac Safari settings
Connect your iOS device to your dev computer and launch your app.
In Safari on your dev computer, click on Develop in the menu bar and hover over the dropdown option that is your iOS device's name to show a list of webview instances running on your iOS device.
Mac Safari develop menu
Click the dropdown option for the webview that you wish to debug. This will open a new Safari Web Inspector window for inspecting the webview.