How to Block External Redirects in Flutter WebView

How Did We Discover the Flutter WebView Navigation Issue?

While working on a custom Video-on-Demand (VOD) platform for a client in the entertainment industry, we encountered a critical security and user experience challenge. The architecture required us to embed a third-party media player within the mobile application. To achieve this, we utilized a standard flutter webview integration to load a specific embedded video page.

During our QA cycles, we realized a significant flaw: while the primary video played correctly, the embedded page contained nested iframes and aggressive JavaScript. These scripts would frequently attempt to hijack the session, triggering popups or redirecting the user to unauthorized third-party domains and ad networks. In a production environment, this behavior is unacceptable as it compromises app security, frustrates users and violates strict App Store guidelines regarding hidden browser navigation.

Companies looking to hire flutter developers for mobile app development often face these edge cases when integrating third-party web content. This challenge inspired this article, detailing how we diagnosed the limitations of standard navigation delegates and engineered a robust solution so other teams can avoid the same pitfall.

Why Do Unwanted Redirects Happen in a Flutter WebView?

The core business use case was simple: load an embedded video player from an approved domain (e.g., media-provider.example.com) while preventing the webpage from navigating the WebView to external URLs. The architectural concern here is the boundary of trust. When you load external web content, you inherit its dependencies, including third-party analytics, ad scripts and nested iframes (e.g., loading resources from cdn.media-provider.example.com).

In a typical browser environment, popup blockers and cross-origin resource sharing (CORS) policies offer some protection. However, within a native mobile context, a flutter webview acts as a programmable browser window. If you do not explicitly lock down its routing, any script within the loaded DOM that executes window.location.href or window.open() can force the webview to render a completely different site, effectively trapping the user outside your intended application flow.

What Failed When Trying to Restrict External URLs in Flutter?

Our initial assumption was that the standard NavigationDelegate provided by the webview_flutter package would be sufficient to block unauthorized domains. We implemented a basic domain whitelist to restrict navigation.

The code looked roughly like this:

controller = WebViewController()
  ..setJavaScriptMode(JavaScriptMode.unrestricted)
  ..setNavigationDelegate(
    NavigationDelegate(
      onNavigationRequest: (request) {
        final uri = Uri.tryParse(request.url);
        if (uri == null) return NavigationDecision.prevent;
        
        const allowedHosts = {'media-provider.example.com', 'cdn.media-provider.example.com'};
        
        return allowedHosts.contains(uri.host)
            ? NavigationDecision.navigate
            : NavigationDecision.prevent;
      },
    ),
  )
  ..loadRequest(Uri.parse('https://media-provider.example.com/embed/video/12345'));

The symptoms of failure surfaced almost immediately. While this approach successfully blocked top-level navigation (e.g., if a user clicked a standard <a href="..."> tag), it failed completely against JavaScript-triggered popups and deeply nested iframe redirects. The NavigationDelegate in the standard plugin only reliably intercepts main-frame navigation requests. It does not monitor or prevent background scripts or iframes from opening new windows or loading unapproved external resources. This architectural oversight created a massive loophole for third-party scripts to exploit.

How Did We Approach Solving the Flutter WebView Routing Problem?

When you hire software developer teams to build resilient architectures, they must look beyond surface-level APIs and understand underlying platform behaviors. We evaluated several approaches to lock down the flutter webview.

Did a Standard Navigation Delegate Work for the Flutter WebView?

As established, the standard NavigationDelegate alone was insufficient. It is designed for top-level routing decisions, not deep DOM restriction or network request interception. We realized we could not rely on native Dart callbacks alone to secure the rendering engine against malicious or aggressive embedded scripts.

Could We Use JavaScript Injection to Block Scripts in the Webview?

Since the problem originated inside the DOM, we considered fighting JavaScript with JavaScript. By injecting a custom script immediately after the page loads, we could override native browser functions like window.open, disable target="_blank" on anchor tags and strip out known malicious iframes. This approach was lightweight and didn’t require switching libraries, though it carried the risk of race conditions if the malicious scripts executed before our injection.

Was Switching to Advanced Content Blockers Necessary for Mobile Apps?

We also evaluated migrating from the official webview_flutter to flutter_inappwebview, a community package that provides granular native control, including Android’s shouldInterceptRequest and iOS’s WKContentRuleList. This allows intercepting every single HTTP request (images, scripts, iframes) before they reach the network layer. Ultimately, we decided to implement a hybrid defense using the standard library with aggressive JavaScript injection for immediate mitigation, while proposing the architectural shift to native content blockers for the next major release.

How Did We Implement the Final Flutter WebView Security Fix?

To fix the issue using the standard webview_flutter package, we combined a strict NavigationDelegate with a robust JavaScript injection strategy. By executing JS that neutralizes popup mechanisms, we effectively sandboxed the embedded player.

Here is the sanitized implementation:

import 'package:flutter/material.dart';
import 'package:webview_flutter/webview_flutter.dart';
class SecureVideoPlayer extends StatefulWidget {
  final String videoUrl;
  const SecureVideoPlayer({Key? key, required this.videoUrl}) : super(key: key);
  @override
  State<SecureVideoPlayer> createState() => _SecureVideoPlayerState();
}
class _SecureVideoPlayerState extends State<SecureVideoPlayer> {
  late final WebViewController controller;
  // JavaScript to neutralize popups and strict iframe hijacking
  final String _securityScript = '''
    // Override window.open to do nothing
    window.open = function() { return null; };
    
    // Prevent target="_blank" clicks
    document.addEventListener('click', function(e) {
      var target = e.target.closest('a');
      if (target && target.getAttribute('target') === '_blank') {
        target.removeAttribute('target');
      }
    }, true);
    
    // Periodically remove known ad-overlay iframes if necessary
    setInterval(function() {
      var frames = document.getElementsByTagName('iframe');
      for (var i = 0; i < frames.length; i++) {
        var src = frames[i].src;
        if (src && src.indexOf('media-provider.example.com') === -1) {
          frames[i].style.display = 'none';
        }
      }
    }, 1000);
  ''';
  @override
  void initState() {
    super.initState();
    controller = WebViewController()
      ..setJavaScriptMode(JavaScriptMode.unrestricted)
      ..setNavigationDelegate(
        NavigationDelegate(
          onNavigationRequest: (request) {
            final uri = Uri.tryParse(request.url);
            if (uri == null) return NavigationDecision.prevent;
            const allowedHosts = {
              'media-provider.example.com',
              'cdn.media-provider.example.com'
            };
            if (allowedHosts.contains(uri.host)) {
              return NavigationDecision.navigate;
            }
            return NavigationDecision.prevent;
          },
          onPageFinished: (String url) {
            // Inject security script once the page is ready
            controller.runJavaScript(_securityScript);
          },
        ),
      )
      ..loadRequest(Uri.parse(widget.videoUrl));
  }
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: const Text('Secure Player')),
      body: WebViewWidget(controller: controller),
    );
  }
}

Validation Steps: We tested this implementation against scenarios where embedded scripts attempted to force a redirect via window.open and simulated clicks on hidden anchor tags. The JavaScript override successfully intercepted these attempts, while the NavigationDelegate caught any standard main-frame URL changes.

Performance and Security Considerations: Injecting JavaScript via onPageFinished has a small window where scripts can execute before the injection takes place. For environments demanding zero-trust isolation, utilizing network-level request interception is necessary. It is one of the reasons many organizations hire remote developers for media platforms to ensure complex edge cases like DRM and network-level security are handled natively.

What Are the Key Security Lessons for Mobile App Developers?

Securing a flutter webview requires more than just calling native APIs. Here are the actionable insights our team extracted from this integration:

• Never Trust External DOMs: Treat any third-party webpage loaded in your app as untrusted. They can introduce unapproved trackers, crypto-miners or redirect loops.
• Navigation Delegates Have Limits: Understand that native navigation callbacks usually only apply to top-level frame changes. They do not automatically block XHR requests, fetch calls or nested iframe rendering.
• Defense in Depth: Combine native routing constraints with DOM manipulation (JavaScript injection) to create a multi-layered defense against unwanted behavior.
• Understand Platform Differences: iOS (WKWebView) and Android (WebView) handle iframes and popups differently under the hood. Always test your webview lockdowns on physical devices for both platforms.
• Consider Native Overlays: Whenever possible, build native UI overlays and only use the webview for rendering the actual video stream, minimizing the surface area for malicious scripts to interact with user inputs.
• Plan for Advanced Interception: If you plan to hire app developer to create a mobile app that relies heavily on complex third-party web content, architect the system using libraries that support HTTP request interception from day one.

How Can You Secure Your Mobile Architecture?

Embedding third-party web content into a native mobile application presents unique security and user experience challenges. By recognizing the limitations of basic navigation delegates and implementing strategic DOM overrides, we successfully secured our client’s VOD platform. A flutter webview is a powerful tool, but it requires strict governance to prevent it from becoming a vulnerability. If your team is struggling with complex mobile architecture, native integrations or ensuring secure playback environments, contact us to explore how our dedicated engineering teams can help.

Social Hashtags

#Flutter #FlutterDev #FlutterDevelopment #FlutterWebView #WebView #MobileAppDevelopment #AppSecurity #MobileSecurity #Dart #AndroidDevelopment #iOSDevelopment #NavigationDelegate #JavaScript #WebSecurity #SoftwareDevelopment