Error Troubleshooting

This is a newly developing issue, and as such the information in this article may change over time.

Error message - CORS Errors caused by local network access permissions when using Chromium 142 and later

Overview

Starting in Chromium-based browsers v142+ (released Oct 28, 2025)—including Chrome, Edge, Brave, and Opera—Dynamsoft Web TWAIN Service may not work as expected due to new Local Network Access (LNA) restrictions that limit requests from public network locations to private and loopback network locations.

Symptoms

You may experience one or more of the following:

1) Browser repeatedly prompts to download the service

The browser asks the user to download/install the Dynamsoft Web TWAIN Service even though it is already installed.

2) Initialization succeeds, but scanning / loading returns blank

Initialization appears successful, but scanned or loaded images are blank.

The browser console (F12 → Console) may show a CORS denial similar to:

Access to fetch at 'https://127.0.0.1:18623/fa/VersionInfo?ts=1761893667670'
from origin 'https://your-domain.com' has been blocked by CORS policy:
Permission was denied for this request to access the `unknown` address space.

This error occurs because the web page is loaded from a public network origin (for example, https://your-domain.com) and is attempting to connect to a loopback network location (127.0.0.1), which Chrome now treats as a protected local network request.

Version-Specific Behavior

The observed behavior depends on Chromium browser version and Dynamic Web TWAIN (DWT) version:

(*) Chromium 145, which can also block websocket, has not been officially released.
Behavior is based on pre-release testing and may change once the final release becomes available. Edge 143 and Firefox Nightly will have local network permission control as well.

Root Cause

Chromium 142 introduces and enforces a new Local Network Access (LNA) security model that restricts requests from public network locations to private and loopback network locations, requiring explicit user permission.

For background and design rationale, see Chrome’s Developer Blog: New permission prompt for Local Network Access.

Under this model, requests originating from a public network location (such as a publicly hosted website) to private or loopback network locations (including localhost and 127.0.0.1) are blocked by default unless the user explicitly grants permission.

Dynamic Web TWAIN relies on a locally installed service that listens on a loopback address. When a web application hosted on a public domain attempts to communicate with this service, Chrome categorizes the request as a public-to-local network request, which now requires explicit user consent.

Resolution

1. To Manually Correct This in Chrome

• Navigate to your Dynamic Web TWAIN page.
• Click the lock/settings icon in the browser address bar.
• Ensure that Local Network Access is enabled.

If you’re unable to restore functionality after enabling ‘Local Network Access,’ please contact Dynamsoft.

2. (For Admins) To Apply This Setting Across an Enterprise

Enterprise administrators can deploy a Chrome and/or Edge policy to set the “Local Network Access” setting to “Allow” for your website.

Please refer to:

• Chrome Enterprise Policy List & Management Documentation
• Microsoft Edge Browser Policy Documentation

3. Developer Notes

a) If Running Inside an iframe

If Dynamic Web TWAIN is running inside an iframe from a different origin (cross-origin), you must explicitly grant local-network access in the iframe. If the iframe is same-origin, no additional configuration is required.

To enable access, specify the allow attribute. For security reasons, it is recommended to allow only the necessary origin rather than using a wildcard.

<!-- Recommended: restrict to specific origin -->
<iframe src="..." allow="local-network-access your-domain.com"></iframe>

<!-- Not recommended: wildcard -->
<!-- <iframe src="..." allow="local-network-access *"></iframe> -->

b) (Optional Enhancement) Permission Check for Improved UX

You can optionally query Local Network Access permission at runtime. This isn’t required, but implementing a check can help you proactively notify users and provide clearer guidance if permission is missing.

// Before initializing Dynamsoft WebTWAIN (DWT), you can remind users
// that Chrome may ask for Local Network Access permission.
(async () => {
  try {
    const result = await navigator.permissions.query({ name: "local-network-access" });
    console.log(`LNA permission state: ${result.state}`);
 
    const state = result.state; // 'denied', 'prompt', 'granted'
 
    if (state === "denied") {
      const currentSite = encodeURIComponent(window.location.origin);
      const settingsUrl = `chrome://settings/content/siteDetails?site=${currentSite}`;
      console.log(`Local network access is currently denied.\n\nPlease go to:\n${settingsUrl}\nand enable 'Local network access' permission for this site.`);
      // Optionally show a UI guide or help link here.
    } else if (state === "prompt") {
      alert("To connect with the local scanning service, Chrome will ask for 'Local network access' permission.\n\nPlease click 'Allow' when prompted.");
      // Proceed to init DWT after this message. 
      // e.g., Dynamsoft.DWT.Load() or CreateDWTObjectEx or your init DWT function
    } else if (state === "granted") {
      console.log("Local network access already granted.");
      // Initialize DWT or proceed directly.
      // e.g., Dynamsoft.DWT.Load() or CreateDWTObjectEx or your init DWT function
    } else {
      console.log("Unexpected LNA state:", state);
    }
 
  } catch (e) {
    console.log("This browser does not support Chromium LNA Permissions API yet.");
    // Fallback: directly initialize DWT
    // Dynamsoft.DWT.Load() or CreateDWTObjectEx or your init DWT function
  }
})();

If the permission is not granted, consider displaying a user-friendly message directing them to:

Chrome → Settings → Privacy and Security → Site Settings → Local network access

This approach provides a more polished user experience, especially during onboarding or troubleshooting.

Roadmap

Dynamsoft plans to add a feature that automatically detects local service connectivity and permission status. If the connection is blocked, users will be prompted with a message and directed to this FAQ page.

Here are the details:

• When local network access is blocked, prompt the user with the following dialog:

  

  Dialog 1

• Add a sentence about the permission in the service installation dialog, since we cannot determine whether the connection failure is due to the service not being installed or the access being blocked.

  

  Dialog 2

  Clicking “Guide” will open dialog 1, prompting the user to enable the permission.

This design will be integrated in v19.3. For old versions, we can include an extra js file, which can be retrieved by contacting support.

Other Causes of Failure to Connect to the Service

There are other causes of service not being connected. You can find them in another FAQ.

Original post creation date: Nov 04, 2025

Last modified date: Dec 12, 2025