WebView Hardening Prevention

Overview

WebView Hardening Prevention automatically secures WebView instances throughout your application by enforcing a robust set of security defaults and optionally applying aggressive restrictions to prevent common attack vectors including file-URL data exfiltration, JavaScript bridge abuse, and mixed-content downgrade attacks.

The control operates transparently on all WebViews while allowing host applications to opt specific WebViews into stricter configurations when needed for high-risk contexts.

How It Works

WebView Hardening Prevention applies a two-tier security model:

Default Hardening (Applied to All WebViews)

Every WebView created in your application receives safe-by-default security settings without any code changes required:

iOS:

• Blocks JavaScript-initiated window.open calls to prevent pop-under attacks
• Requires user gesture for all audio and video playback to prevent auto-playing media exploits

Android:

• Blocks file:// URL access to prevent local file system access
• Blocks cross-origin requests from file:// URLs
• Enforces HTTPS-only content loading (MIXED_CONTENT_NEVER_ALLOW)
• Enables Google Safe Browsing protection
• Disables WebView remote debugging process-wide

These defaults protect against common exploitation vectors while preserving normal web content functionality.

Aggressive Opt-In Hardening

For WebViews displaying untrusted or external content, you can request additional restrictions:

iOS:

WKWebViewConfiguration *config = [[WKWebViewConfiguration alloc] init];
[WebViewHardeningPrevention markConfigurationForHardening:config];
WKWebView *webView = [[WKWebView alloc] initWithFrame:frame configuration:config];

This applies:

• Complete JavaScript execution blocking
• Inline media playback prevention

Android:

Android applies consistent hardening to all discovered WebViews automatically. No explicit opt-in is required.

Threats Mitigated

• File URL Exfiltration: Prevents malicious web content from reading local files via file:// URLs
• JavaScript Bridge Abuse: Reduces unauthorized access to native capabilities made available through JavaScript interfaces
• Mixed Content Downgrade: Prevents downgrade attacks where HTTPS pages load insecure HTTP resources
• Pop-Under/Pop-Up Exploits: Stops JavaScript from spawning unwanted windows
• Auto-Playing Media Attacks: Requires user interaction for audio/video playback
• WebView Remote Debugging: Disables remote debugging to prevent runtime inspection

How to Enable the Control

Navigate to Preventative Controls from the AppTego portal, and expand the Runtime Environment Hardening section. Under this section you will find the WebView Hardening control. Click Enable to enable it for the next build or for it to be applied with a live push (if enabled).

API Configuration Example

{
  "WebViewHardeningPrevention": {
    "protection": true
  }
}

Configuration

iOS Opt-In Hardening

To apply aggressive JavaScript and media restrictions to a specific WebView:

#import <MobileDefender/MobileDefender.h>

WKWebViewConfiguration *config = [[WKWebViewConfiguration alloc] init];

// Mark this configuration for aggressive hardening
[WebViewHardeningPrevention markConfigurationForHardening:config];

// Create WebView with hardened configuration
WKWebView *webView = [[WKWebView alloc] initWithFrame:frame
                                        configuration:config];

Use this approach for WebViews displaying:

• User-generated content
• Third-party advertisements
• External web applications
• Untrusted or unverified URLs

Android Automatic Hardening

On Android, hardening is applied automatically to all WebViews attached to your activities when they resume. No configuration code is required.

Caveats and Compatibility

OAuth and Deep Link Flows

Aggressive hardening (iOS opt-in mode) may interfere with:

• OAuth authentication flows that rely on JavaScript redirects
• Deep linking mechanisms using window.open or JavaScript navigation
• Single-page applications that depend on JavaScript execution

Recommendation: Do not use aggressive hardening on WebViews hosting OAuth flows, authentication pages, or trusted first-party web applications.

JavaScript Bridge Requirements

Applications using addJavascriptInterface (Android) or WKUserContentController.add(_:name:) (iOS) to expose native APIs to web content should carefully test WebView functionality:

• Default hardening preserves JavaScript bridge functionality
• Aggressive hardening (iOS) completely disables JavaScript, breaking all bridge communication

Recommendation: Only use aggressive hardening on WebViews that do not require JavaScript bridge functionality.

Custom WebView Creation Patterns

Android Limitations:

The control discovers WebViews through activity lifecycle monitoring. It may not harden:

• WebViews created in Dialog or PopupWindow instances
• WebViews in background services or worker threads
• WebViews not yet attached to the activity's view hierarchy at resume time

Recommendation: Ensure security-sensitive WebViews are attached to activities before they load content.

Support Matrix

Integration

WebView Hardening Prevention activates automatically when enabled in your MobileDefender tenant configuration. No code changes are required for default hardening.

For iOS applications requiring aggressive hardening on specific WebViews, import the MobileDefender header and call markConfigurationForHardening: on your WKWebViewConfiguration instances before creating WebViews.

Further Information

For tenant-specific integration guidance, contact AppTego support.